[zeromq-dev] ROUTER and queue overflow
Yu Dongmin
miniway at gmail.com
Sat Apr 6 06:54:21 CEST 2013
Hi Joel,
What version of zmq are you using?
https://github.com/zeromq/libzmq/commit/a0cecc718d3d95279dcc7b0d9b6c1d09fb4cfd97
The patch let send method block when the pipe is full with the mandatory option.
Or if you send message with DONTWAIT, it will return -1 with EAGAIN.
Thanks
Min
On Apr 6, 2013, at 12:30 AM, Pieter Hintjens <ph at imatix.com> wrote:
> Hi Joel,
>
> It's indeed possible ROUTER doesn't reliably report HWM. To be
> checked; this would seem to be an error in the mandatory
> functionality.
>
> You might consider using credit based flow control. It isn't that
> complex and gives you more accurate control over the flow of messages.
> When a client isn't responding, the server knows up front, before
> messages get lost.
>
> There is a simple ROUTER-DEALER CBFC model explained in Chapter 7.
>
> -Pieter
>
>
>
> On Fri, Apr 5, 2013 at 10:13 AM, Joel Lauener <Joel.Lauener at cern.ch> wrote:
>> Currently I’m doing some testing with the DEALER-ROUTER combo. This test
>> involve a single ROUTER sending messages to a single DEALER. This emulate
>> one of our use case were the server is sending notifications to a client.
>> What I’m doing now is I’m slowing down the client so it is unable to process
>> all the received messages.
>>
>>
>>
>> Looking at the TCP buffers I see a correct behaviour, client rcv buffer
>> fills up, then server snd buffer fills up. However when the snd buffer is
>> full, the ROUTER still accepts my messages but seems to internally drop
>> them. I’m using non-blocking send with the mandatory option enabled, but
>> still I receive no error. Is this the expected behaviour?
>>
>>
>>
>> Is there some documentation (beside the code ;) about the internals of
>> ROUTER sockets? I guess there is one “main” queue that is dispatched to many
>> “client” queues. If so, this would explains why send doesn’t fail because
>> the “main” queue is not full and the message is dropped while dispatching.
>> That would also explains why HWM doesn’t work as I would expect (because it
>> only affects the “main” queue).
>>
>>
>>
>> Using a DEALER-DEALER pattern it works as expected. The send calls fail,
>> which allows the server to be aware of the lost message. This last point is
>> very important for us because if a notification is lost the server must, at
>> least, log it.
>>
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
More information about the zeromq-dev
mailing list