Hi Gordon, That definitely looks like a very nice feature. There are many situations when you want to trigger the reconnect manually and not leave it fully on the client library.
Right now, it seems that the reconnect(...) method always requires the URL of the broker to reconnect to. Maybe it would be useful to also add a reconnect() method without the URL parameter, to trigger the reconnect based on the URL which was specified when creating the connection. Thanks & Regards Jakub On Wed, Aug 28, 2013 at 5:30 PM, Gordon Sim <g...@redhat.com> wrote: > I have a proposal[1] for a small addition to the qpid::messaging API that > makes the reconnect feature less of an 'all or nothing' affair[2]. For > background context, this limitation was brought up most recently on the dev > list back in June[3]. > > Basically it exposes a new reconnect() method allowing the application to > catch the TransportFailure and decide if and when and where to reconnect. > Invoking that method then re-establishes all the sessions/senders/receivers > and replays indoubt messages. > > Any feedback welcome as usual, either here or on reviewboard. > > --Gordon. > > [1] https://reviews.apache.org/r/**13885/<https://reviews.apache.org/r/13885/> > [2] > https://issues.apache.org/**jira/browse/QPID-4932<https://issues.apache.org/jira/browse/QPID-4932> > [3] http://qpid.2158936.n2.nabble.**com/Qpid-post-mortem-and-** > request-for-suggestions-for-**my-next-release-challenge-10M-** > msgs-sec-on-Windows-**tp7594096p7594258.html<http://qpid.2158936.n2.nabble.com/Qpid-post-mortem-and-request-for-suggestions-for-my-next-release-challenge-10M-msgs-sec-on-Windows-tp7594096p7594258.html> > > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > users-unsubscribe@qpid.apache.**org<users-unsubscr...@qpid.apache.org> > For additional commands, e-mail: users-h...@qpid.apache.org > >
