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