[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