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