[zeromq-dev] Stuck REQ after REP crash

Виктор Накоряков nail.xx at gmail.com
Sat Aug 7 20:11:09 CEST 2010


I see. Thanks for quick reply. I'll look toward XREQ/XREP


07.08.2010, в 21:32, Pieter Hintjens <ph at imatix.com> написал(а):

> 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
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev



More information about the zeromq-dev mailing list