[zeromq-dev] Apparent queuing on PUB/SUB fan-in despite HWM=1
ian.barber at gmail.com
Wed May 11 17:27:37 CEST 2011
On Wed, May 11, 2011 at 3:46 PM, Brian Rossa <rossabri at hotmail.com> wrote:
> My understanding of the HWM semantic is that, when the HWM is reached, new
> messages will not be queued. That means that the queued messages are not the
> newest messages. There are good reasons for why this has to be the case.
> Fine. Still, this growing lag for prolific senders doesn't make any sense to
> me. The message that I receive at the system endpoint should only be as old
> as the last zmq_recv from that node. Yet, I am experiencing situations in
> which one of the intermediate nodes will "take a break" -- eg, it won't send
> any messages for a while -- and the endpoint will continue to process old
> messages from it for a few more minutes. Shouldn't it process JUST ONE
> message from a node that's "taking a break" if HWM is 1 on both sides of
> that socket pair?
If the messages are reasonably small, this lag could be caused by TCP
buffers - your fast node messages are stuck in a big TCP buffer, and ZeroMQ
is fair queing from each of the sockets, so takes a little while to consume.
The HWM only applies to stuff that has been pulled out of the TCP buffer and
into zeromq, so for small messages your effective 'queue' could be a fair
bit bigger than 1.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the zeromq-dev