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