[zeromq-dev] Thinking of...failure

[Conrad Steenberg]

Hi Mu Chi,

Attached is a simple patch that does the first 2 things on my list
further down in the thread:
- it removes the abort() entirely,
- reconnects if no error handler exists
- reconnects/shuts connection down if the error handler returns
true/false.

Still working on the rest, it's a little more convoluted than just
removing the queues/exchanges from the vectors in api_thread.

HTH,
Conrad

On Mon, 2009-08-10 at 07:40 +0800, Mu-Chi Sung (宋牧奇) wrote:
> Hi Conrad,
> 
> I accidentally ran into the same issue as yours when I started
> thinking about failure, which is something I can't ignore from the
> design perspective. 
> So could you post the patch to the list? Thanks a million!
> 
> Regards,
> Mu Chi
> 
> On Tue, Jul 28, 2009 at 12:51 AM, Conrad Steenberg
> <conrad.steenberg at gmail.com> wrote:
>         Hi Martin,
>         
>         On Mon, 2009-07-27 at 09:47 +0200, Martin Hurton wrote:
>         > Hi Conrad,
>         >
>         
>         > On Fri, Jul 24, 2009 at 11:56 PM, Conrad
>         > Steenberg<conrad.steenberg at gmail.com> wrote:
>         > > Hi Martin,
>         > >
>         > > Is there a way to delete the local exchanges/queues in
>         case of an error?
>         >
>         > I'm afraid there is no such mechanism available now.
>         
>         
>         OK, looking at the code, I think what I'll do is to create a
>         patch that
>         will, in the case where an error callback is registered:
>         - reconnect if the callback returns true,
>         - not reconnect (and not abort!) when the callback returns
>         false
>         - add a public method to api_thread to remove local
>         exchanges/queues to
>         prevent memory leaks.
>         
>         In that way the application can decide to stop reconnecting
>         after e.g. a
>         number of attempts or timeout, but preserve the automatic
>         reconnection
>         feature for the case where no callback is registered.
>         
>         I'll post the patch to the list if anyone else is interested.
>         
>         Cheers,
>         Conrad
>         
>         
>         >
>         > >
>         > > I'm thinking of something to allow removal from the
>         api_thread.queues
>         > > and api_thread.echanges vectors. And calling the shutdown
>         method of the
>         > > associated in/out_engine.
>         > >
>         > > Thanks,
>         > > Conrad
>         > >
>         > > On Thu, 2009-07-23 at 19:31 +0200, Martin Hurton wrote:
>         > >> Hi Conrad,
>         > >>
>         > >> You can set up a callback to handle connection errors.
>         For details,
>         > >> please see set_error_handler(3) man page.
>         > >>
>         > >> - Martin
>         > >>
>         > >> On Thu, Jul 23, 2009 at 6:17 PM, Conrad
>         > >> Steenberg<conrad.steenberg at gmail.com> wrote:
>         > >> > Hi all,
>         > >> >
>         > >> > In moving from a more low-level TCP client/server model
>         to 0MQ over TCP
>         > >> > it seems to me that some information gets lost in the
>         abstraction:
>         > >> > closed connections.
>         > >> >
>         > >> > E.g. in the Butterfly example, would it be possible to
>         detect if the
>         > >> > "intermediate" component crashes?
>         > >> >
>         > >> > Sorry if I missed this in the documentation :-)
>         > >> >
>         > >> > Conrad
>         > >> >
>         > >> >
>         
>         _______________________________________________
>         zeromq-dev mailing list
>         zeromq-dev at lists.zeromq.org
>         http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>         
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zmq-tcp_reconnect.diff
Type: text/x-patch
Size: 343 bytes
Desc: not available
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20090809/2f0bda0b/attachment.bin>