Hello Alan,
I am using Proton 0.27.0 and I am not finding a way to update the reconnect
options.
How can I use the connection.options().reconnect(reconnect_opts_)) you proposed
or something equivalent in order to update the reconnect options after the
connection is created ?
Regards,
Ali
-----Original Message-----
From: Alan Conway <acon...@redhat.com>
Sent: mardi 30 avril 2019 21:11
To: users@qpid.apache.org
Subject: Re: [Proton-C] Discovery
On Tue, Apr 30, 2019 at 8:25 AM HADI Ali <ali.h...@murex.com> wrote:
> Hello Alan,
>
> Do you have any updates concerning the proposition to update the
> reconnect options in Proton-C?
> Is it planned and if yes do you have an idea when?
>
The changes I describe below were released version 0.26, and are available in
the current release 0.27. You should be able to take advantage of them now.
> Regards,
> Ali
>
> -----Original Message-----
> From: Alan Conway <acon...@redhat.com>
> Sent: jeudi 24 janvier 2019 23:24
> To: users@qpid.apache.org
> Subject: Re: [Proton-C] Discovery
>
> On Thu, Jan 24, 2019 at 8:28 AM Rabih M <rabih.prom...@gmail.com> 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 <acon...@redhat.com> wrote:
> >
> > > On Fri, Jan 18, 2019 at 10:35 AM Alan Conway <acon...@redhat.com>
> wrote:
> > >
> > > >
> > > >
> > > > On Thu, Jan 17, 2019 at 6:56 AM Rabih M
> > > > <rabih.prom...@gmail.com>
> > 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 <acon...@redhat.com>
> > wrote:
> > > >>
> > > >> > On Thu, Jan 3, 2019 at 7:12 AM Gordon Sim <g...@redhat.com>
> 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: 'users@qpid.apache.org' <users@qpid.apache.org>
> > > >> > > > 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: users@qpid.apache.org<mailto:users@qpid.apache.org>
> > > >> > > > 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: users-unsubscr...@qpid.apache.org
> > > >> > > For additional commands, e-mail: users-h...@qpid.apache.org
> > > >> > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > >
> >
> *******************************
> 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.
>
*******************************
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.
