On Fri, May 3, 2019 at 4:52 AM HADI Ali <[email protected]> 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 <[email protected]> > Sent: jeudi 2 mai 2019 21:29 > To: [email protected] > Subject: Re: [Proton-C] Discovery > > > > On Thu, May 2, 2019 at 7:13 AM HADI Ali <[email protected]<mailto: > [email protected]>> 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 <[email protected]<mailto:[email protected]>> > Sent: mardi 30 avril 2019 21:11 > To: [email protected]<mailto:[email protected]> > Subject: Re: [Proton-C] Discovery > > On Tue, Apr 30, 2019 at 8:25 AM HADI Ali <[email protected]<mailto: > [email protected]>> 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 <[email protected]<mailto:[email protected]>> > > Sent: jeudi 24 janvier 2019 23:24 > > To: [email protected]<mailto:[email protected]> > > Subject: Re: [Proton-C] Discovery > > > > On Thu, Jan 24, 2019 at 8:28 AM Rabih M <[email protected]<mailto: > [email protected]>> 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 > > > > > > > > > On Fri, Jan 18, 2019 at 4:58 PM Alan Conway <[email protected] > <mailto:[email protected]>> wrote: > > > > > > > On Fri, Jan 18, 2019 at 10:35 AM Alan Conway <[email protected] > <mailto:[email protected]>> > > wrote: > > > > > > > > > > > > > > > > > > > On Thu, Jan 17, 2019 at 6:56 AM Rabih M > > > > > <[email protected]<mailto:[email protected]>> > > > wrote: > > > > > > > > > >> Hello, > > > > >> > > > > >> What Olivier was proposing is more at the level of the C++ > > > > >> proton > > > > binding. > > > > >> What we would like to do is: > > > > >> Instead of taking a vector of fixed fail-over urls in the > > > > >> reconnect_options, we would like the reconnect_options to take > > > > >> an std::function that returns a URL. This function will be > > > > >> called by > > > proton > > > > >> to > > > > >> get the next URL when there is failure. This will allow the > > > > >> clients to write there own logic to fetch the new URLs > > dynamically... > > > > >> On the qpid-jms side we have already this possibility. > > > > >> > > > > > > > > > > That sounds reasonable but I'd suggest an alternative that is a > > > > > bit > > > more > > > > > flexible, add this to proton::connection: > > > > > > > > > > // Over-ride connection options to be used the next time the > > > > > connection re-connects. > > > > > // Takes effect only if/when the connection does re-connect. > > > > > // Typically called in on_transport_error() to influence > > > > > automatic re-connect. > > > > > connection::reconnect_options(connection::options& overrides) > > > > > > > > > > > > > > BROKEN sorry - that would *replace* all your connection options, > > > > not override the ones you want which is not what I meant. > > > > This is better: > > > > > > > > // Allow updates to the connection_options used by this connection. > > > > // These updates only take effect if/when the connection is > > re-connected. > > > > // Typically used in on_transport_error() to change the options > > > > used for automatic re-connect. > > > > connection_options& connection::options(); > > > > > > > > So now your case becomes: > > > > > > > > myhandler { > > > > connection_options::reconnect_opts_; // Save initial reconnect > > > > opts > > > > > > > > void on_transport_error(transport& t) { > > > > reconnect_opts_.failover_urls(pick_my_urls()); // Update the > URLs > > > > t .connection().options().reconnect(reconnect_opts_)); // > > > > Update > > > the > > > > connection's options > > > > } > > > > } > > > > > > > > > > > > > > > > > > >> We would like to know if it sounds reasonable to you before > > > > >> proposing > > > a > > > > >> patch. WDYT? > > > > >> > > > > >> Best regards, > > > > >> Rabih > > > > >> > > > > >> On Thu, Jan 3, 2019 at 9:15 PM Alan Conway <[email protected] > <mailto:[email protected]>> > > > wrote: > > > > >> > > > > >> > On Thu, Jan 3, 2019 at 7:12 AM Gordon Sim <[email protected] > <mailto:[email protected]>> > > wrote: > > > > >> > > > > > >> > > Are you talking specifically about something at the c level > > > > >> > > rather > > > > >> than > > > > >> > > e.g. c++? > > > > >> > > > > > > >> > > As far as I recall, the c layer has no built in support for > > > > >> > > reconnection, that is added by the c++ (or other) wrappers. > > > > >> > > > > > > >> > > In the c++ api, perhaps the reconnect options in use could > > > > >> > > be > > > > exposed > > > > >> > > (such that they can then be altered), or else there could > > > > >> > > be a way > > > > to > > > > >> > > provide a function that returns the next url to use rather > > > > >> > > than a > > > > >> static > > > > >> > > list (this is sort of what the python wrapper allows). That > > > > >> > > may be > > > > >> what > > > > >> > > you mean by the onReconnect callback? If so, it sounds > > > > >> > > reasonable > > > to > > > > >> me, > > > > >> > > though it would be better to get the thoughts of those more > > > involved > > > > >> > > with that component. (Alan, Cliff, Andrew?) > > > > >> > > > > > > >> > > > > > > >> > Just to add some detail to what Gordon said - in C there is > > > > >> > no > > > > reconnect > > > > >> > support out-of-the-box but you have the tools to implement > > > > >> > any > > > > strategy > > > > >> > you like. Use the PN_TRANSPORT_CLOSED event (with > > > pn_transport_error() > > > > >> set) > > > > >> > to react to an unexpected disconnect. You can modify the > > > > >> > parameters > > > > used > > > > >> > for re-connect any way you like. If you re-use the existing > > > > >> pn_connection_t > > > > >> > your sessions and links will be automatically re-opened. If > > > > >> > you > > > don't > > > > >> want > > > > >> > that, you can throw away the old pn_connection_t and > > > > >> > re-connect > > > with > > > > a > > > > >> new > > > > >> > one. > > > > >> > > > > > >> > The C++ binding provides automatic reconnect with some > > > > >> > built-in > > > > options, > > > > >> > including a list of URLs. You can be notified of a disconnect > > > > >> > by on_transport_error(), but I don't think the current API > > > > >> > allows you > > > to > > > > >> > change the reconnect URL list at that point. If the built-in > > > > >> > options don't do what you need, you can turn off the > > > > >> > built-in automatic > > > > >> reconnect > > > > >> > and implement your own custom reconnect strategy in > > > > >> on_transport_error(), > > > > >> > similar to what I described for C above. > > > > >> > > > > > >> > > > > > >> > > On 03/01/19 10:30, VERMEULEN Olivier wrote: > > > > >> > > > Hello, > > > > >> > > > > > > > >> > > > Any feedback on the below proposition? > > > > >> > > > > > > > >> > > > Thanks, > > > > >> > > > Olivier > > > > >> > > > > > > > >> > > > From: VERMEULEN Olivier > > > > >> > > > Sent: mardi 18 décembre 2018 15:01 > > > > >> > > > To: '[email protected]<mailto:[email protected]>' < > [email protected]<mailto:[email protected]>> > > > > >> > > > Subject: RE: [Proton-C] Discovery > > > > >> > > > > > > > >> > > > Hello, > > > > >> > > > > > > > >> > > > We looked into the proton-c implementation and didn't > > > > >> > > > find > > > > anything > > > > >> > that > > > > >> > > would allow us to implement a qpid-jms like discovery. > > > > >> > > > So I was wondering if we could add, directly in proton-c, > > > > >> > > > an > > > > >> > onReconnect > > > > >> > > callback (or something similar) that would allow us to > > > > >> > > modify the > > > > >> list of > > > > >> > > URLs the client tries to connect to. > > > > >> > > > We need this to answer the following use case: > > > > >> > > > the dispatch-router (host1:1234) on which the client was > > > connected > > > > >> goes > > > > >> > > down > > > > >> > > > the client enters the reconnect loop (on host1:1234) we > > > > >> > > > restart the dispatch-router but on another machine > > > (host2:5678) > > > > >> > > > the client reconnects -> this is currently not happening > > > > >> > > > Note that we can do the pull-request but I wanted to run > > > > >> > > > the > > > > >> > proposition > > > > >> > > by you first. > > > > >> > > > > > > > >> > > > Thanks, > > > > >> > > > Olivier > > > > >> > > > > > > > >> > > > From: VERMEULEN Olivier > > > > >> > > > Sent: mardi 11 décembre 2018 12:34 > > > > >> > > > To: [email protected]<mailto:[email protected] > ><mailto:[email protected]<mailto:[email protected]>> > > > > >> > > > Subject: [Proton-C] Discovery > > > > >> > > > > > > > >> > > > Hello, > > > > >> > > > > > > > >> > > > I was looking into the qpid-jms-discovery project which > > > > >> > > > seems > > > very > > > > >> nice > > > > >> > > for what I'm trying to do: update the list of > > > > >> > > dispatch-routers the > > > > >> client > > > > >> > > can connect to during failover (with a custom discovery > logic). > > > > >> > > > I wanted to know if there is something similar with > > > > >> > > > proton-c or > > > at > > > > >> > least > > > > >> > > a way for me to implement it? > > > > >> > > > > > > > >> > > > Thanks, > > > > >> > > > Olivier > > > > >> > > > > > > > >> > > > ******************************* This e-mail contains > > > > >> > > > information for the intended recipient > > > only. > > > > It > > > > >> > may > > > > >> > > contain proprietary material or confidential information. > > > > >> > > If you > > > are > > > > >> not > > > > >> > > the intended recipient you are not authorized to > > > > >> > > distribute, copy > > > or > > > > >> use > > > > >> > > this e-mail or any attachment to it. Murex cannot guarantee > > > > >> > > that > > > it > > > > is > > > > >> > > virus free and accepts no responsibility for any loss or > > > > >> > > damage > > > > >> arising > > > > >> > > from its use. If you have received this e-mail in error > > > > >> > > please > > > > notify > > > > >> > > immediately the sender and delete the original email > > > > >> > > received, any attachments and all copies from your system. > > > > >> > > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > ------------------------------------------------------------------ > > > > -- > > > > - > > > > >> > > To unsubscribe, e-mail: [email protected] > <mailto:[email protected]> > > > > >> > > For additional commands, e-mail: [email protected] > <mailto:[email protected]> > > > > >> > > > > > > >> > > > > > > >> > > > > > >> > > > > > > > > > > > > > > ******************************* > > This e-mail contains information for the intended recipient only. It > > may contain proprietary material or confidential information. If you > > are not the intended recipient you are not authorized to distribute, > > copy or use this e-mail or any attachment to it. Murex cannot > > guarantee that it is virus free and accepts no responsibility for any > > loss or damage arising from its use. If you have received this e-mail > > in error please notify immediately the sender and delete the original > > email received, any attachments and all copies from your system. > > > ******************************* > This e-mail contains information for the intended recipient only. It may > contain proprietary material or confidential information. If you are not > the intended recipient you are not authorized to distribute, copy or use > this e-mail or any attachment to it. Murex cannot guarantee that it is > virus free and accepts no responsibility for any loss or damage arising > from its use. If you have received this e-mail in error please notify > immediately the sender and delete the original email received, any > attachments and all copies from your system. > ******************************* > This e-mail contains information for the intended recipient only. It may > contain proprietary material or confidential information. If you are not > the intended recipient you are not authorized to distribute, copy or use > this e-mail or any attachment to it. Murex cannot guarantee that it is > virus free and accepts no responsibility for any loss or damage arising > from its use. If you have received this e-mail in error please notify > immediately the sender and delete the original email received, any > attachments and all copies from your system. >
