[zeromq-dev] 0MQ 2.0 Model Question: Continued.

Martin Sustrik sustrik at fastmq.com
Fri Oct 23 08:59:22 CEST 2009


>>>    If you are able to propose a sane API for your scenario, that would be
>>>    the first step towards the solution. For example: How would you let the
>>>    system know that the response corresponds to a particular request? Etc.
>>> Consider the Tibco Rendezvous API call SendRequest it has the following
>>> synchronous operation:
>>> 1.  Create a unique inbox address and a handler that listens to that
>>> address.  Update message with a reply subject of the inbox address.
>>> 2.  Send outbound message.
>>> 3.  Block until the listener receives a reply or a set time limit expires.
>>> 4.  Return the reply message.
>> Yup. That's the standard way of doing the thing on client side. Now consider
>> the server side: You have to extract the inbox address from the message,
>> store it somewhere. Once the reply is ready, the address should  be attached
>> to it so that 0MQ knows which client to send the reply to. What kind of
>> changes to API are required here?
>> Actually, my feeling is that most users would appreciate simple load
>> balancing among N worker threads with no need for user to mess with reply
>> addresses etc.
> Oh.  Is that already possible?  Is the functionality to 'receive' from
> the queue in multiple threads (concurrently) already exist?

No. It does not exist yet. I was just suggesting that making 0MQ support 
this scenario would be sufficient in most cases. In concrete terms, that 
the message processing loop in each thread can look like this:

while (true) {
     message_t req, rep;
     s.recv (&req);
     ... process it ...
     s.send (rep);

without a need for something like this:

while (true) {
     message_t req, rep;
     s.recv (&req);
     ... process it ...
     rep.set_subject (req.get_subject ());
     s.send (rep);


> I do see zmq_init function with app_threads parameter but I am unable
> to figure out how that works (in 2.0).

App_threads is the max number of the threads you can use to access 0MQ 
at the same time. If you set app_threads to 2, then open socket from 
thread 1, open another socket from thread 2 and try to open yet another 
socket from thread 3, the least one will fail.

> The sample snippets indicate it is just one thread pulling messages
> and processing them in sequence.
> Either of these would satisfy the use cases I am thinking about.
>    -  Messages have some kind of 'sender address' embedded in them.
> Receiver can deque multiple messages and process them (in a thread
> queue presumably) and reply in leisure.
>   - Pull messages from multiple threads, process them and reply. The
> thread blocks if the application logic blocks.

Yes. I was suggesting that the latter would be a better solution. Thoughts?


More information about the zeromq-dev mailing list