You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Gordon Sim <gs...@redhat.com> on 2013/08/28 17:30:44 UTC
[c++] give application more direct control over reconnect & replay
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/
[2] 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++] give application more direct control over reconnect &
replay
Posted by NimbusParc <ni...@yahoo.in>.
+1
Gordon Sim wrote
> On 08/29/2013 04:11 PM, Gordon Sim wrote:
>> On 08/29/2013 03:00 PM, Jakub Scholz wrote:
>>> 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.
>>
>> Yes, that sounds like a good idea. I'll update the patch to do that.
>> Thanks!
>
> Fyi: I've updated the patch on reviewboard to add this method. Also
> changed the name of getCurrentUrl() to getUrl() as Alan suggested.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> users-unsubscribe@.apache
> For additional commands, e-mail:
> users-help@.apache
--
View this message in context: http://qpid.2158936.n2.nabble.com/c-give-application-more-direct-control-over-reconnect-replay-tp7597590p7598163.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++] give application more direct control over reconnect & replay
Posted by Jakub Scholz <ja...@scholz.cz>.
Thanks Gordon. I appreciate it.
Regards
Jakub
On Fri, Aug 30, 2013 at 6:01 PM, Gordon Sim <gs...@redhat.com> wrote:
> On 08/29/2013 04:11 PM, Gordon Sim wrote:
>
>> On 08/29/2013 03:00 PM, Jakub Scholz wrote:
>>
>>> 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.
>>>
>>
>> Yes, that sounds like a good idea. I'll update the patch to do that.
>> Thanks!
>>
>
> Fyi: I've updated the patch on reviewboard to add this method. Also
> changed the name of getCurrentUrl() to getUrl() as Alan suggested.
>
>
>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.**org<us...@qpid.apache.org>
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: [c++] give application more direct control over reconnect & replay
Posted by Gordon Sim <gs...@redhat.com>.
On 08/29/2013 04:11 PM, Gordon Sim wrote:
> On 08/29/2013 03:00 PM, Jakub Scholz wrote:
>> 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.
>
> Yes, that sounds like a good idea. I'll update the patch to do that.
> Thanks!
Fyi: I've updated the patch on reviewboard to add this method. Also
changed the name of getCurrentUrl() to getUrl() as Alan suggested.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++] give application more direct control over reconnect & replay
Posted by Gordon Sim <gs...@redhat.com>.
On 08/29/2013 03:00 PM, Jakub Scholz wrote:
> 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.
Yes, that sounds like a good idea. I'll update the patch to do that. Thanks!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: [c++] give application more direct control over reconnect & replay
Posted by Jakub Scholz <ja...@scholz.cz>.
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 <gs...@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<us...@qpid.apache.org>
> For additional commands, e-mail: users-help@qpid.apache.org
>
>