[zeromq-dev] PUSH/PULL lost messages (once again)

Jean-François Smigielski jf.smigielski at gmail.com
Fri Mar 8 19:44:46 CET 2013


Be quiet, the example I provided is not the definite program. I relied on
the internal queues to avoid spawning threads. This is the shortest example
illustrating the problem.

I was convinced that the only queue was associated with the 0MQ applicative
socket, and that messages were only dequeued when an underlying file
descriptor was ready for output.

Thank you both for the clear answers. I changed the connection principle
and it works really fine. This didn't change my really  good opinion about
this Intelligent Transport Layer.


--
Jean-François SMIGIELSKI
+33 (0) 625 135 563


2013/3/8 A. Mark <gougolith at gmail.com>

>
> Hi!
>
> In your code the argv[1] "link" must be independently "PUSHED/PULLED" for
> this example to give reliable results. Not sure what you do in the
> push()/pull() calls but in general your workers and the "collector" are
> separate processes. Here you are assuming that the first for loop will not
> block at some point which is not true in general, same for the second loop.
> The argv[2] link will not transmit any messages until it is connected, and
> yes ZMQ will queue messages so it may appear that you have sent messages
> even if the endpoint is not connected.
>
> -Mark
>
>
>
> On Fri, Mar 8, 2013 at 2:58 AM, Pieter Hintjens <ph at imatix.com> wrote:
>
>> On Fri, Mar 8, 2013 at 11:42 AM, Jean-François Smigielski
>> <jf.smigielski at gmail.com> wrote:
>>
>> > To check error cases, in the same test program (here below) I
>> voluntarily
>> > connected a PUSH'er to 2 tcp URL, one valid and one that never existed
>> (and
>> > won't ever).
>>
>> When you connect, you create a queue for outgoing messages, which will
>> be delivered when the connection succeeds.
>>
>> In your design this is guaranteed to lose 50% of messages.
>>
>> If you bind the PUSH and connect the PULL to it, you won't lose
>> messages. This is the normal design when you have N workers, where
>> some may disappear randomly.
>>
>> -Pieter
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20130308/c75fd03e/attachment.htm>


More information about the zeromq-dev mailing list