[zeromq-dev] identity bug

Martin Sustrik sustrik at 250bpm.com
Tue May 25 16:16:58 CEST 2010

Serge Aleynikov,

>>> How about this example - a REQ caller sends a message and issues a
>>> blocking recv() call.  The REP server dies between receiving a message
>>> and sending a reply.  The REP server comes back and client's 0MQ
>>> transport successfully reconnects.  However, the client will be blocked
>>> in the recv() call forever because the last transaction got lost.
>> As I said, it's not yet perfect.
>> The plan for REQ/REP is to have XREQ/XREP as an asynchronous
>> infrastructure for requests and replies.
>> REQ/REP would then be wrappers on top of XREQ/XREP adding synchronicity.
>> In addition, REQ would wait a specific timeout and if reply doesn't
>> arrive it'll re-emit the request. Also, it would have to drop duplicate
>> replies.
> Since there are very limited details on what XREQ/XREP are supposed to 
> achieve, could you tell if in the example above when using XREQ/XREP 
> there would be any resource leaks (due to pending transaction) or any 
> other types of blocking?

There would be no leaks and no blocking.

> Does XREQ preserve ordering semantics (i.e. if 
> requests are sent in order 1 and 2, is it possible to receive and 
> process replies in order 2 and 1 without blocking if reply to request 1 
> is lost forever)?

Yes. This can happen if the request are routed to two different service 
instances. Processing the first request may take longer than processing 
the second one and thus you'll get replies out of order.


More information about the zeromq-dev mailing list