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

[A. Mark]

...Not sure that English is your first language but FYI saying "be quiet"
is quite rude since you do not really know my age, second you are the one
asking a question...I'm glad you figured it out :)

-Mark

On Fri, Mar 8, 2013 at 10:44 AM, Jean-François Smigielski <
jf.smigielski at gmail.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/e16ab6e2/attachment.htm>