[zeromq-dev] Order by which PUB/SUB requests are sent/processed

Joegen Baclor jbaclor at ezuce.com
Wed Jan 25 03:40:14 CET 2012


That is exactly my second option after I get confirmation.  I just don't 
want to jump the gun without confirming it can't be done by setting an 
option in 0mq.  Thanks for the input.

On 01/25/2012 10:30 AM, Michel Pelletier wrote:
> If I follow what you're asking, you want the numbers in your first
> email to have a more even distribution than what they have now, where
> no one subscriber gets the message "first", so to speak.  I'm not sure
> it makes sense for 0mq to try to make any guarantees on the time of
> arrival.  Messages could be going out same or different transports and
> interfaces.  Maybe a better solution for you would be for your workers
> to "roll the dice" to see who will pop first.
>
> -Michel
>
> On Tue, Jan 24, 2012 at 6:12 PM, Joegen Baclor<jbaclor at ezuce.com>  wrote:
>> I understand that Martin and we do require that all queue participants
>> gets the message.   However, there is one unique requirement in our
>> application that pops certain data from a common queue as soon as one
>> subscriber receives the message.  If there are three subscribers there
>> will be 3 pops happening.  Only one would succeed.   The two other which
>> fails follows a different logical task.  The fan out strategy for
>> pub-sub although virtually happening simultaneously is still single
>> threaded and thus would line up in the transport rendering the effect of
>> having a strict priority in terms of which subscriber gets the first
>> chance to pop the event from the other queue.  What we wanted to achieve
>> is that no single subscriber gets the chance.  Thanks in advance for
>> your time.
>>
>> On 01/25/2012 09:52 AM, Martin Sustrik wrote:
>>> Hi Joegen,
>>>
>>> PUB socket sends every message to *every* subscriber. Thus they should
>>> arrive at the destinations at approximately the same time.
>>>
>>> Exact time of course depends on network latency between publisher and
>>> individual subscribers.
>>>
>>> Martin
>>>
>>> On 01/25/2012 10:41 AM, Joegen Baclor wrote:
>>>> Just in case someone finds time to look into my issue, I am attaching
>>>> the publisher code. Perhaps there is something I am doing wrong or
>>>> options i need to set to achieve a fairly-queued sending of events.
>>>>
>>>> On 01/24/2012 06:27 PM, Joegen Baclor wrote:
>>>>> Hi,
>>>>>
>>>>> We have an application the uses PUP/SUB sockets. One requirement that
>>>>> ZeroMQ gracefully meets is being able to reliably send events to all
>>>>> subscribers. However, there is a requirement in our application that
>>>>> relies on which client gets the event first. We were under the
>>>>> assumption that ZeroMQ randomizes the sending of events to the mutiple
>>>>> subscribers so that no one subscriber always gets a first hit.
>>>>> Unfortunately, this seems to be not the case. ZeroMq seems to follow a
>>>>> specific fix order. We have created 3 clients each incrementing a
>>>>> counter if it was the first one to get the publication. Take the
>>>>> output below (each iteration is 1500 events):
>>>>>
>>>>> Iteration 0
>>>>> Client 1 processed 1496 events.
>>>>> Client 2 processed 0 events.
>>>>> Client 3 processed 4 events.
>>>>>
>>>>> Iteration 1
>>>>> Client 1 processed 2309 events.
>>>>> Client 2 processed 647 events.
>>>>> Client 3 processed 44 events.
>>>>>
>>>>> Iteration 2
>>>>> Client 1 processed 2992 events.
>>>>> Client 2 processed 1385 events.
>>>>> Client 3 processed 123 events.
>>>>>
>>>>> Iteration 3
>>>>> Client 1 processed 3623 events.
>>>>> Client 2 processed 1951 events.
>>>>> Client 3 processed 426 events.
>>>>>
>>>>> Iteration 4
>>>>> Client 1 processed 4207 events.
>>>>> Client 2 processed 2697 events.
>>>>> Client 3 processed 723 events.
>>>>> TestDriver::TestMultiplePop ... Ok
>>>>>
>>>>> Clearly, the order is predictable. client 1 gets the highest hit and
>>>>> client 3 gets the lowest hit. Is there a way so that we can spread
>>>>> this evenly across the subscribers?
>>>>>
>>>>> Joegen
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>




More information about the zeromq-dev mailing list