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] > > >> > > > > >> > > > > >> > > > >> > > > > > >
