[zeromq-dev] publish/subscribe and the "fast producer" problem

Max Kozlovsky max at portworx.com
Tue Mar 7 20:51:38 CET 2017


Hi,

I wonder what is the practical application of this model? If for
correctness of the application it is enough to deliver every message to at
least one of the subscribers, why not always sent just one copy of a
message to just one of the subscribers? Sends to the rest of the
subscribers are overhead since they are not required for correctness?

Max

On Tue, Mar 7, 2017 at 11:26 AM, Francesco <francesco.montorsi at gmail.com>
wrote:

> Hi Justin,
>
> 2017-03-07 7:39 GMT+01:00 Justin Karneges <justin at karneges.com>:
> > On Mon, Mar 6, 2017, at 01:26 AM, Francesco wrote:
> >> Hi Justin,
> >>
> >> >> > My advice
> >> >> > is to publish at a fixed rate, for example by sleeping between
> publishes.
> >> >>
> >> >> Unfortunately this is not a solution in my case, as the events I
> >> >> publish are generated by other incoming events that I cannot control
> >> >> and in general I will not know at which rate they arrive.
> >> >
> >> > Ah, but even if your writes automatically slowed down to the fastest
> >> > subscriber, you'd still face this problem. What will you do with
> >> > incoming events while you're waiting for the fastest subscriber to
> >> > become writable again?
> >>
> >> In such a case I just need to drop input events.
> >
> >[...]
> >
> > It might be handy if there were an alternative to ZMQ_XPUB_NODROP (say
> > ZMQ_XPUB_ATLEASTONE) that required at least one subscriber to be
> > writable, but not all of them. Then you could send with ZMQ_DONTWAIT,
> > and an EAGAIN error would indicate that not even the fastest subscriber
> > was writable (you could then discard the message yourself and not retry
> > sending it).
>
> Yes, I think this would be really useful not just to me...
>
>
> > To solve your problem without changing ZeroMQ, you might make a
> > subscriber feedback system.
> > [...]
> I agree, and that's what I'm going to do for the short term. If
> someone points me to the right point in the code however I can try to
> generate a patch for ZeroMQ adding such a ZMQ_XPUB_ATLEASTONE flag...
>
> thanks,
> Francesco
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20170307/85ecbb63/attachment.htm>


More information about the zeromq-dev mailing list