he
> 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.
-
Thanks Gordon. I appreciate it.
Regards
Jakub
On Fri, Aug 30, 2013 at 6:01 PM, 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
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 reco
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
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 wou
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 allow
