[zeromq-dev] Stuck REQ after REP crash

[Pieter Hintjens]

On Sat, Aug 7, 2010 at 6:56 PM, Victor Nakoryakov <nail.xx at gmail.com> wrote:

> I'm using REQ/REP sockets and in doubt about one scenario.
>
> What if a service that produces replies will peek a subsequent request
> and somewhere before replying will crash? In this case requester will
> continue to wait for the reply, and will do this forever. Consider
> there is a mechanism that allows to re-process the request by replier
> and to form the reply. However I can't do rep_socket.send before
> rep_socket.recv. So in any case looks like the REQ socket is stuck
> forever.

Yes, this is how it works today.  REQ has no timeout or retry
mechanism.  It is a lack.

I'm thinking there are a few ways to fix this or work around:

* We could add timeout/retry to REQ with corresponding resend to REP.
This would give us a simple form of reliable messaging.  Requires work
in 0MQ but seems the ideal model.
* You can use XREQ/XREP and do the timeout/retry yourself.  This would
be a good way to prove the concept but it's obviously painful that
apps have to do this themselves.
* You could do this with a customized queue device in between the two nodes.

It's not trivial work in any scenario. The service side (or device)
will need to store not a single but a history of requests and
responses, one per identity.

-Pieter