On Tue, Apr 30, 2019 at 8:25 AM HADI Ali <[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]> > Sent: jeudi 24 janvier 2019 23:24 > To: [email protected] > Subject: Re: [Proton-C] Discovery > > On Thu, Jan 24, 2019 at 8:28 AM Rabih M <[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]> wrote: > > > > > On Fri, Jan 18, 2019 at 10:35 AM Alan Conway <[email protected]> > wrote: > > > > > > > > > > > > > > > On Thu, Jan 17, 2019 at 6:56 AM Rabih M <[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]> > > wrote: > > > >> > > > >> > On Thu, Jan 3, 2019 at 7:12 AM Gordon Sim <[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]' <[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]> > > > >> > > > 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] For > > > >> > > additional commands, e-mail: [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. >
