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

PJ Durai pjdtech2000 at gmail.com
Thu Oct 22 00:18:11 CEST 2009

On Wed, Oct 21, 2009 at 1:09 AM, Martin Sustrik <sustrik at fastmq.com> wrote:
> Steven McCoy wrote:
>> 2009/10/21 Martin Sustrik <sustrik at fastmq.com <mailto:sustrik at fastmq.com>>
>>    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?

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

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.


More information about the zeromq-dev mailing list