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<[email protected]> 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 >>>> [email protected] >>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >>> >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
