Hello Alan,
Will your pull request "reconnect_update" be released in the next proton
release 0.29.0?
We are waiting for this dev to implement some features form our side.
We can help if needed...
Best regards,
Rabih
On Fri, May 3, 2019 at 5:29 PM Alan Conway wrote:
> On Fri, May 3, 2019 at 4:52 AM HADI Ali wrote:
>
> > Thanks a lot. This is exactly what we need for our custom discovery
> logic.
> > We are also thinking of updating the maxReconnectAttempts in the
> > messaging_handler::on_connection_open in order to have the equivalent of
> > the startupMaxReconnectAttempts in JMS. Do you think this will be
> feasible
> > with your dev?
> >
>
> I'd recommend setting the initial connection_options in
> container::connect() instead, and using reconnect_update() only for updates
> *during* a reconnect, i.e. in on_transport_error().
> It would probably work if you're careful but I'd be worried about potential
> for confusion with connection options over-writing each other in multiple
> different places.
>
>
>
> >
> > Thanks,
> > Ali
> >
> > From: Alan Conway
> > Sent: jeudi 2 mai 2019 21:29
> > To: users@qpid.apache.org
> > Subject: Re: [Proton-C] Discovery
> >
> >
> >
> > On Thu, May 2, 2019 at 7:13 AM HADI Ali > ali.h...@murex.com>> wrote:
> > Hello Alan,
> >
> > I am using Proton 0.27.0 and I am not finding a way to update the
> > reconnect options.
> > How can I use the connection.options().reconnect(reconnect_opts_)) you
> > proposed or something equivalent in order to update the reconnect options
> > after the connection is created ?
> >
> > I apologise - the ability to update the connection options was never
> > merged. I've submitted a pull request for review since I'm not working
> full
> > time on proton at the moment.
> > https://github.com/apache/qpid-proton/pull/181
> > With that change in place you will be able to do what you want, it should
> > be in the next release if there are no objections. See the attached
> > example. The relevant part of the example is:
> >
> > void on_transport_error(proton::transport & t) OVERRIDE {
> > std::cout << "disconnected by: " << t.error() << std::endl;
> > static int n = 0;
> > // Use the initial failover list the first 10 times, then switch
> > to a new one.
> > if (n++ == 10) {
> > std::cout << "switching failover-list" << std::endl;
> > proton::connection_options co;
> > proton::reconnect_options ro;
> > ro.failover_urls({"badX","badY"});
> > co.reconnect(ro);
> > t.connection().reconnect_update(co); // Apply new options to
> > connection
> > }
> > if (n > 20) { exit(0); } // Give up after 20 reconnects
> > }
> >
> >
> >
> >
> > Regards,
> > Ali
> >
> > -Original Message-
> > From: Alan Conway mailto:acon...@redhat.com>>
> > Sent: mardi 30 avril 2019 21:11
> > To: users@qpid.apache.org
> > Subject: Re: [Proton-C] Discovery
> >
> > On Tue, Apr 30, 2019 at 8:25 AM HADI Ali > ali.h...@murex.com>> wrote:
> >
> > > Hello Alan,
> > >
> > > Do you have any updates concerning the proposition to update the
> > > reconnect options in Proton-C?
> > > Is it planned and if yes do you have an idea when?
> > >
> >
> > The changes I describe below were released version 0.26, and are
> available
> > in the current release 0.27. You should be able to take advantage of them
> > now.
> >
> >
> > > Regards,
> > > Ali
> > >
> > > -Original Message-
> > > From: Alan Conway mailto:acon...@redhat.com>>
> > > Sent: jeudi 24 janvier 2019 23:24
> > > To: users@qpid.apache.org
> > > Subject: Re: [Proton-C] Discovery
> > >
> > > On Thu, Jan 24, 2019 at 8:28 AM Rabih M > rabih.prom...@gmail.com>> wrote:
> > >
> > > > Hello,
> > > >
> > > > Knowing that the on_transport_error will be called only when the
> > > > max_reconnect is reached, the user will have to manage one reattempt
> > > > at a time. It will become too flexible, the user will have to write
> > > > his own reconnect strategy with out reusing what was done already
> > > > the embedded reconnect code.
> > > >
> > >
> > > That used to be the case, but now on_transport_error() is now supposed
> > > to be called every time there is a transport error, exactly to support
> > > this kind of use case. I can't remember if that change made it into
> > > 0.26 or if it's just on master now.
> > >
> > > We would like to reuse the native reconnect way that is implemented in
> > > > proton and be flexible in the URLs like Qpid JMS and Qpid Python.
> > > >
> > >
> > > If on_transport_error() is called ever disconnect, then I think my
> > > proposal gives you that. There are syntactic differences - the
> > > callback is on_transport_error(), and instead of returning URLs you
> > > update the reconnect options - but the functionality is the same. Does
> > > that sound right?
> > >
> > >
> > > > Best regards,
> > > > Rabih
> > > >
