[zeromq-dev] Using ØMQ just as in-memory queue

Anatoly tolitius at gmail.com
Mon Sep 12 16:21:29 CEST 2011


   In case we process these "different typed" messages in a single thread (
void *context = zmq_init (*1*); ), but still using a ZMQ.PUB / ZMQ.SUB
pattern, would we be able to create multiple subscribers from this same

       1.  If yes, would "subscriberA.recv( 0 )" block the
"subscriberB.recv( 0 )"?
       2.  In case a PUB/SUB is not a good match here ( which is a shame
since we would need to parse message types, and do the dispatch manually ),
what would the right pattern be?

   ( just to recap: "many messages that have different types, encoded as
first byte in each message, need to be processed sequentially" )

Thank you,

*P.S. CCing a mailing list *

On Sun, Sep 11, 2011 at 3:13 AM, Martin Sustrik <sustrik at 250bpm.com> wrote:

> Hi Anatoly,
>        1. Is that a good idea to do so? To use ØMQ just as an in memory
>> queue ( rather than a Queue data structures in various languages ).
> Yes. I believe so.
>        2. In case the answer to the question above is YES... We have
>> several different message types ( let's call these types 'A' , 'B', 'C'
>> .. 'Z' ). In case I use subscribers to these different types [ e.g.
>> subscriber.subscribe ( "A" ), subscriber.subscribe ( "B" ), etc.. ], is
>> there a way to ensure that all the messages will be processed in order?
>> In other words, if messages were sent as 'A', 'B', 'C', and we have 3
>> subscribers, is there a way to guarantee that when a subscriber 'C' gets
>> the message, messages 'A' and 'B' were already processed? In that case I
>> can rely on ØMQ to play a role of a queue as well as a
>> router/dispatcher, which would be helpful.
> To achieve that kind of behaviour you would have to synchronise the
> subscribers.
> If you opt to do so, it's not clear why not to do all the work in a single
> thread in the first place.
> Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110912/f4c716dc/attachment.htm>

More information about the zeromq-dev mailing list