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)
That allows you to modify any options you want, not just the URL - SASL/SSL
settings, modify reconnect intervals etc etc.
For your case it would look like:
myhandler::on_transport_error(transport& t) {
t.connection().reconnect_options(connection::options().reconnect().failover_urls(pick_my_urls());
}
> 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]
> > >
> > >
> >
>
