You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by VERMEULEN Olivier <Ol...@murex.com> on 2018/12/11 11:33:53 UTC
[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.
RE: [Proton-C] Discovery
Posted by VERMEULEN Olivier <Ol...@murex.com>.
Hello Alan,
Is this the JIRA ticket you're talking about?
https://issues.apache.org/jira/browse/PROTON-1959
Olivier
-----Original Message-----
From: Alan Conway <ac...@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 <ra...@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 <ac...@redhat.com> wrote:
>
> > On Fri, Jan 18, 2019 at 10:35 AM Alan Conway <ac...@redhat.com> wrote:
> >
> > >
> > >
> > > On Thu, Jan 17, 2019 at 6:56 AM Rabih M <ra...@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 <ac...@redhat.com>
> wrote:
> > >>
> > >> > On Thu, Jan 3, 2019 at 7:12 AM Gordon Sim <gs...@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' <us...@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<ma...@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-unsubscribe@qpid.apache.org For
> > >> > > additional commands, e-mail: users-help@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.
RE: [Proton-C] Discovery
Posted by HADI Ali <Al...@murex.com>.
Hello,
- On our side delaying the creation of the connection until one URL is available implies reimplementing another retry strategy at startup. We understand that the use case doesn't fit the current connection model in the code so we will not handle it for the moment.
- In our case, when the connection fails, we are requesting from a discovery service the urls of the available Dispatch-Routers. The urls are returned as a vector which may contain one or many urls.
So we should be able to update both the reconnect_url and the failover_urls.
But as stated in the documentation, updating both is an undefined behavior.
For example, in case the vector contains only one new URL, we need to update the reconnect_url and reset the the failover_urls.
But in reality when doing that, a default URL (localhost:5672) is added as failover_urls because the variable "current_url_" is set as the first failover url ( https://github.com/apache/qpid-proton/blob/b9ea52d0229f69e70aa5543bd5a1521fca71796e/cpp/src/connection_options.cpp#L126).
How do you think we can handle our case?
Thanks,
Ali
-----Original Message-----
From: Andrew Stitcher <as...@apache.org>
Sent: vendredi 13 décembre 2019 17:12
To: users@qpid.apache.org
Subject: Re: [Proton-C] Discovery
On Fri, 2019-12-13 at 14:20 +0000, HADI Ali wrote:
> Hello,
>
> Sorry for the late reply. Thank you for the dev, it allows us to
> discover new endpoints when trying to reconnect.
>
> However there is one use case that we covered in Java with QPID-JMS
> that we couldn’t handle in C++.
> If at the creation of the connection, no messaging server is yet
> available, we want to trigger a retry on the DiscoveryAgent until new
> endpoints are found.
>
> Do you think it is possible to trigger the retry strategy already
> implemented without explicitly passing a URL at the creation of the
> connection?
As the code currently stands I don't think this is possible. I'm not sure if it ever will be, as what triggers the reconnect logic is actually failing to connect, so if you have no url to try you can't fail! We could perhaps get around this somehow, but the case doesn't fit the current connnection model - can you perhaps delay creating the connection until you know at least one of the urls?
>
> Another note : even if we can discover new endpoints and update the
> failover URLs, the primary URL cannot be updated even if it’s not
> available anymore.
You can change the original url by setting the reconnect_url option.
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For additional commands, e-mail: users-help@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.
RE: [Proton-C] Discovery
Posted by HADI Ali <Al...@murex.com>.
Hello,
On our side delaying the creation of the connection until one is created implies reimplementing another retry strategy at startup. However we understand that the use case doesn't fit the current connection model and we will drop it for the moment.
-----Original Message-----
From: Andrew Stitcher <as...@apache.org>
Sent: vendredi 13 décembre 2019 17:12
To: users@qpid.apache.org
Subject: Re: [Proton-C] Discovery
On Fri, 2019-12-13 at 14:20 +0000, HADI Ali wrote:
> Hello,
>
> Sorry for the late reply. Thank you for the dev, it allows us to
> discover new endpoints when trying to reconnect.
>
> However there is one use case that we covered in Java with QPID-JMS
> that we couldn’t handle in C++.
> If at the creation of the connection, no messaging server is yet
> available, we want to trigger a retry on the DiscoveryAgent until new
> endpoints are found.
>
> Do you think it is possible to trigger the retry strategy already
> implemented without explicitly passing a URL at the creation of the
> connection?
As the code currently stands I don't think this is possible. I'm not sure if it ever will be, as what triggers the reconnect logic is actually failing to connect, so if you have no url to try you can't fail! We could perhaps get around this somehow, but the case doesn't fit the current connnection model - can you perhaps delay creating the connection until you know at least one of the urls?
>
> Another note : even if we can discover new endpoints and update the
> failover URLs, the primary URL cannot be updated even if it’s not
> available anymore.
You can change the original url by setting the reconnect_url option.
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For additional commands, e-mail: users-help@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.
Re: [Proton-C] Discovery
Posted by Andrew Stitcher <as...@apache.org>.
On Fri, 2019-12-13 at 14:20 +0000, HADI Ali wrote:
> Hello,
>
> Sorry for the late reply. Thank you for the dev, it allows us to
> discover new endpoints when trying to reconnect.
>
> However there is one use case that we covered in Java with QPID-JMS
> that we couldn’t handle in C++.
> If at the creation of the connection, no messaging server is yet
> available, we want to trigger a retry on the DiscoveryAgent until new
> endpoints are found.
>
> Do you think it is possible to trigger the retry strategy already
> implemented without explicitly passing a URL at the creation of the
> connection?
As the code currently stands I don't think this is possible. I'm not
sure if it ever will be, as what triggers the reconnect logic is
actually failing to connect, so if you have no url to try you can't
fail! We could perhaps get around this somehow, but the case doesn't
fit the current connnection model - can you perhaps delay creating the
connection until you know at least one of the urls?
>
> Another note : even if we can discover new endpoints and update the
> failover URLs, the primary URL cannot be updated even if it’s not
> available anymore.
You can change the original url by setting the reconnect_url option.
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
RE: [Proton-C] Discovery
Posted by HADI Ali <Al...@murex.com>.
Hello,
Sorry for the late reply. Thank you for the dev, it allows us to discover new endpoints when trying to reconnect.
However there is one use case that we covered in Java with QPID-JMS that we couldn’t handle in C++.
If at the creation of the connection, no messaging server is yet available, we want to trigger a retry on the DiscoveryAgent until new endpoints are found.
Do you think it is possible to trigger the retry strategy already implemented without explicitly passing a URL at the creation of the connection?
Another note : even if we can discover new endpoints and update the failover URLs, the primary URL cannot be updated even if it’s not available anymore.
Regards,
Ali
-----Original Message-----
From: Jiri Daněk <jd...@redhat.com>
Sent: jeudi 26 septembre 2019 10:04
To: users <us...@qpid.apache.org>
Subject: Re: [Proton-C] Discovery
On Wed, Jun 5, 2019 at 12:13 PM Rabih M <ra...@gmail.com> wrote:
> Hello Alan,
>
> Will your pull request "reconnect_update" be released in the next
> proton release 0.29.0?
> We are waiting for this dev to implement some features form our side.
>
> We can help if needed...
>
Hi, the PRs on https://issues.apache.org/jira/browse/PROTON-2040 were merged in time for 0.29 release. Does the way it is implemented there suit your needs?
--
Mit freundlichen Grüßen / Kind regards
Jiri Daněk
*******************************
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.
Re: [Proton-C] Discovery
Posted by Jiri Daněk <jd...@redhat.com>.
On Wed, Jun 5, 2019 at 12:13 PM Rabih M <ra...@gmail.com> wrote:
> Hello Alan,
>
> Will your pull request "reconnect_update" be released in the next proton
> release 0.29.0?
> We are waiting for this dev to implement some features form our side.
>
> We can help if needed...
>
Hi, the PRs on https://issues.apache.org/jira/browse/PROTON-2040 were
merged in time for 0.29 release. Does the way it is implemented there suit
your needs?
--
Mit freundlichen Grüßen / Kind regards
Jiri Daněk
Re: [Proton-C] Discovery
Posted by Rabih M <ra...@gmail.com>.
Hello Alan,
Will your pull request "reconnect_update" be released in the next proton
release 0.29.0?
We are waiting for this dev to implement some features form our side.
We can help if needed...
Best regards,
Rabih
On Fri, May 3, 2019 at 5:29 PM Alan Conway <ac...@redhat.com> wrote:
> On Fri, May 3, 2019 at 4:52 AM HADI Ali <Al...@murex.com> wrote:
>
> > Thanks a lot. This is exactly what we need for our custom discovery
> logic.
> > We are also thinking of updating the maxReconnectAttempts in the
> > messaging_handler::on_connection_open in order to have the equivalent of
> > the startupMaxReconnectAttempts in JMS. Do you think this will be
> feasible
> > with your dev?
> >
>
> I'd recommend setting the initial connection_options in
> container::connect() instead, and using reconnect_update() only for updates
> *during* a reconnect, i.e. in on_transport_error().
> It would probably work if you're careful but I'd be worried about potential
> for confusion with connection options over-writing each other in multiple
> different places.
>
>
>
> >
> > Thanks,
> > Ali
> >
> > From: Alan Conway <ac...@redhat.com>
> > Sent: jeudi 2 mai 2019 21:29
> > To: users@qpid.apache.org
> > Subject: Re: [Proton-C] Discovery
> >
> >
> >
> > On Thu, May 2, 2019 at 7:13 AM HADI Ali <Ali.HADI@murex.com<mailto:
> > Ali.HADI@murex.com>> wrote:
> > 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 ?
> >
> > I apologise - the ability to update the connection options was never
> > merged. I've submitted a pull request for review since I'm not working
> full
> > time on proton at the moment.
> > https://github.com/apache/qpid-proton/pull/181
> > With that change in place you will be able to do what you want, it should
> > be in the next release if there are no objections. See the attached
> > example. The relevant part of the example is:
> >
> > void on_transport_error(proton::transport & t) OVERRIDE {
> > std::cout << "disconnected by: " << t.error() << std::endl;
> > static int n = 0;
> > // Use the initial failover list the first 10 times, then switch
> > to a new one.
> > if (n++ == 10) {
> > std::cout << "switching failover-list" << std::endl;
> > proton::connection_options co;
> > proton::reconnect_options ro;
> > ro.failover_urls({"badX","badY"});
> > co.reconnect(ro);
> > t.connection().reconnect_update(co); // Apply new options to
> > connection
> > }
> > if (n > 20) { exit(0); } // Give up after 20 reconnects
> > }
> >
> >
> >
> >
> > Regards,
> > Ali
> >
> > -----Original Message-----
> > From: Alan Conway <ac...@redhat.com>>
> > Sent: mardi 30 avril 2019 21:11
> > To: users@qpid.apache.org<ma...@qpid.apache.org>
> > Subject: Re: [Proton-C] Discovery
> >
> > On Tue, Apr 30, 2019 at 8:25 AM HADI Ali <Ali.HADI@murex.com<mailto:
> > Ali.HADI@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 <ac...@redhat.com>>
> > > Sent: jeudi 24 janvier 2019 23:24
> > > To: users@qpid.apache.org<ma...@qpid.apache.org>
> > > Subject: Re: [Proton-C] Discovery
> > >
> > > On Thu, Jan 24, 2019 at 8:28 AM Rabih M <rabih.promail@gmail.com
> <mailto:
> > rabih.promail@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 <aconway@redhat.com
> > <ma...@redhat.com>> wrote:
> > > >
> > > > > On Fri, Jan 18, 2019 at 10:35 AM Alan Conway <aconway@redhat.com
> > <ma...@redhat.com>>
> > > wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, Jan 17, 2019 at 6:56 AM Rabih M
> > > > > > <ra...@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 <aconway@redhat.com
> > <ma...@redhat.com>>
> > > > wrote:
> > > > > >>
> > > > > >> > On Thu, Jan 3, 2019 at 7:12 AM Gordon Sim <gsim@redhat.com
> > <ma...@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<ma...@qpid.apache.org>'
> <
> > users@qpid.apache.org<ma...@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
> > ><ma...@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-unsubscribe@qpid.apache.org
> > <ma...@qpid.apache.org>
> > > > > >> > > For additional commands, e-mail: users-help@qpid.apache.org
> > <ma...@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.
> > *******************************
> > 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.
> >
>
Re: [Proton-C] Discovery
Posted by Alan Conway <ac...@redhat.com>.
On Fri, May 3, 2019 at 4:52 AM HADI Ali <Al...@murex.com> wrote:
> Thanks a lot. This is exactly what we need for our custom discovery logic.
> We are also thinking of updating the maxReconnectAttempts in the
> messaging_handler::on_connection_open in order to have the equivalent of
> the startupMaxReconnectAttempts in JMS. Do you think this will be feasible
> with your dev?
>
I'd recommend setting the initial connection_options in
container::connect() instead, and using reconnect_update() only for updates
*during* a reconnect, i.e. in on_transport_error().
It would probably work if you're careful but I'd be worried about potential
for confusion with connection options over-writing each other in multiple
different places.
>
> Thanks,
> Ali
>
> From: Alan Conway <ac...@redhat.com>
> Sent: jeudi 2 mai 2019 21:29
> To: users@qpid.apache.org
> Subject: Re: [Proton-C] Discovery
>
>
>
> On Thu, May 2, 2019 at 7:13 AM HADI Ali <Ali.HADI@murex.com<mailto:
> Ali.HADI@murex.com>> wrote:
> 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 ?
>
> I apologise - the ability to update the connection options was never
> merged. I've submitted a pull request for review since I'm not working full
> time on proton at the moment.
> https://github.com/apache/qpid-proton/pull/181
> With that change in place you will be able to do what you want, it should
> be in the next release if there are no objections. See the attached
> example. The relevant part of the example is:
>
> void on_transport_error(proton::transport & t) OVERRIDE {
> std::cout << "disconnected by: " << t.error() << std::endl;
> static int n = 0;
> // Use the initial failover list the first 10 times, then switch
> to a new one.
> if (n++ == 10) {
> std::cout << "switching failover-list" << std::endl;
> proton::connection_options co;
> proton::reconnect_options ro;
> ro.failover_urls({"badX","badY"});
> co.reconnect(ro);
> t.connection().reconnect_update(co); // Apply new options to
> connection
> }
> if (n > 20) { exit(0); } // Give up after 20 reconnects
> }
>
>
>
>
> Regards,
> Ali
>
> -----Original Message-----
> From: Alan Conway <ac...@redhat.com>>
> Sent: mardi 30 avril 2019 21:11
> To: users@qpid.apache.org<ma...@qpid.apache.org>
> Subject: Re: [Proton-C] Discovery
>
> On Tue, Apr 30, 2019 at 8:25 AM HADI Ali <Ali.HADI@murex.com<mailto:
> Ali.HADI@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 <ac...@redhat.com>>
> > Sent: jeudi 24 janvier 2019 23:24
> > To: users@qpid.apache.org<ma...@qpid.apache.org>
> > Subject: Re: [Proton-C] Discovery
> >
> > On Thu, Jan 24, 2019 at 8:28 AM Rabih M <rabih.promail@gmail.com<mailto:
> rabih.promail@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 <aconway@redhat.com
> <ma...@redhat.com>> wrote:
> > >
> > > > On Fri, Jan 18, 2019 at 10:35 AM Alan Conway <aconway@redhat.com
> <ma...@redhat.com>>
> > wrote:
> > > >
> > > > >
> > > > >
> > > > > On Thu, Jan 17, 2019 at 6:56 AM Rabih M
> > > > > <ra...@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 <aconway@redhat.com
> <ma...@redhat.com>>
> > > wrote:
> > > > >>
> > > > >> > On Thu, Jan 3, 2019 at 7:12 AM Gordon Sim <gsim@redhat.com
> <ma...@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<ma...@qpid.apache.org>' <
> users@qpid.apache.org<ma...@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
> ><ma...@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-unsubscribe@qpid.apache.org
> <ma...@qpid.apache.org>
> > > > >> > > For additional commands, e-mail: users-help@qpid.apache.org
> <ma...@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.
> *******************************
> 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.
>
RE: [Proton-C] Discovery
Posted by HADI Ali <Al...@murex.com>.
Thanks a lot. This is exactly what we need for our custom discovery logic.
We are also thinking of updating the maxReconnectAttempts in the messaging_handler::on_connection_open in order to have the equivalent of the startupMaxReconnectAttempts in JMS. Do you think this will be feasible with your dev?
Thanks,
Ali
From: Alan Conway <ac...@redhat.com>
Sent: jeudi 2 mai 2019 21:29
To: users@qpid.apache.org
Subject: Re: [Proton-C] Discovery
On Thu, May 2, 2019 at 7:13 AM HADI Ali <Al...@murex.com>> wrote:
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 ?
I apologise - the ability to update the connection options was never merged. I've submitted a pull request for review since I'm not working full time on proton at the moment. https://github.com/apache/qpid-proton/pull/181
With that change in place you will be able to do what you want, it should be in the next release if there are no objections. See the attached example. The relevant part of the example is:
void on_transport_error(proton::transport & t) OVERRIDE {
std::cout << "disconnected by: " << t.error() << std::endl;
static int n = 0;
// Use the initial failover list the first 10 times, then switch to a new one.
if (n++ == 10) {
std::cout << "switching failover-list" << std::endl;
proton::connection_options co;
proton::reconnect_options ro;
ro.failover_urls({"badX","badY"});
co.reconnect(ro);
t.connection().reconnect_update(co); // Apply new options to connection
}
if (n > 20) { exit(0); } // Give up after 20 reconnects
}
Regards,
Ali
-----Original Message-----
From: Alan Conway <ac...@redhat.com>>
Sent: mardi 30 avril 2019 21:11
To: users@qpid.apache.org<ma...@qpid.apache.org>
Subject: Re: [Proton-C] Discovery
On Tue, Apr 30, 2019 at 8:25 AM HADI Ali <Al...@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 <ac...@redhat.com>>
> Sent: jeudi 24 janvier 2019 23:24
> To: users@qpid.apache.org<ma...@qpid.apache.org>
> Subject: Re: [Proton-C] Discovery
>
> On Thu, Jan 24, 2019 at 8:28 AM Rabih M <ra...@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 <ac...@redhat.com>> wrote:
> >
> > > On Fri, Jan 18, 2019 at 10:35 AM Alan Conway <ac...@redhat.com>>
> wrote:
> > >
> > > >
> > > >
> > > > On Thu, Jan 17, 2019 at 6:56 AM Rabih M
> > > > <ra...@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 <ac...@redhat.com>>
> > wrote:
> > > >>
> > > >> > On Thu, Jan 3, 2019 at 7:12 AM Gordon Sim <gs...@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<ma...@qpid.apache.org>' <us...@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<ma...@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-unsubscribe@qpid.apache.org<ma...@qpid.apache.org>
> > > >> > > For additional commands, e-mail: users-help@qpid.apache.org<ma...@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.
*******************************
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.
Re: [Proton-C] Discovery
Posted by Alan Conway <ac...@redhat.com>.
On Thu, May 2, 2019 at 7:13 AM HADI Ali <Al...@murex.com> wrote:
> 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 ?
>
>
I apologise - the ability to update the connection options was never
merged. I've submitted a pull request for review since I'm not working full
time on proton at the moment. https://github.com/apache/qpid-proton/pull/181
With that change in place you will be able to do what you want, it should
be in the next release if there are no objections. See the attached
example. The relevant part of the example is:
void on_transport_error(proton::transport & t) OVERRIDE {
std::cout << "disconnected by: " << t.error() << std::endl;
static int n = 0;
// Use the initial failover list the first 10 times, then switch to
a new one.
if (n++ == 10) {
std::cout << "switching failover-list" << std::endl;
proton::connection_options co;
proton::reconnect_options ro;
ro.failover_urls({"badX","badY"});
co.reconnect(ro);
t.connection().reconnect_update(co); // Apply new options to
connection
}
if (n > 20) { exit(0); } // Give up after 20 reconnects
}
> Regards,
> Ali
>
> -----Original Message-----
> From: Alan Conway <ac...@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 <Al...@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 <ac...@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 <ra...@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 <ac...@redhat.com>
> wrote:
> > >
> > > > On Fri, Jan 18, 2019 at 10:35 AM Alan Conway <ac...@redhat.com>
> > wrote:
> > > >
> > > > >
> > > > >
> > > > > On Thu, Jan 17, 2019 at 6:56 AM Rabih M
> > > > > <ra...@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 <ac...@redhat.com>
> > > wrote:
> > > > >>
> > > > >> > On Thu, Jan 3, 2019 at 7:12 AM Gordon Sim <gs...@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' <us...@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<ma...@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-unsubscribe@qpid.apache.org
> > > > >> > > For additional commands, e-mail: users-help@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.
>
RE: [Proton-C] Discovery
Posted by HADI Ali <Al...@murex.com>.
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 <ac...@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 <Al...@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 <ac...@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 <ra...@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 <ac...@redhat.com> wrote:
> >
> > > On Fri, Jan 18, 2019 at 10:35 AM Alan Conway <ac...@redhat.com>
> wrote:
> > >
> > > >
> > > >
> > > > On Thu, Jan 17, 2019 at 6:56 AM Rabih M
> > > > <ra...@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 <ac...@redhat.com>
> > wrote:
> > > >>
> > > >> > On Thu, Jan 3, 2019 at 7:12 AM Gordon Sim <gs...@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' <us...@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<ma...@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-unsubscribe@qpid.apache.org
> > > >> > > For additional commands, e-mail: users-help@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.
Re: [Proton-C] Discovery
Posted by Alan Conway <ac...@redhat.com>.
On Tue, Apr 30, 2019 at 8:25 AM HADI Ali <Al...@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 <ac...@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 <ra...@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 <ac...@redhat.com> wrote:
> >
> > > On Fri, Jan 18, 2019 at 10:35 AM Alan Conway <ac...@redhat.com>
> wrote:
> > >
> > > >
> > > >
> > > > On Thu, Jan 17, 2019 at 6:56 AM Rabih M <ra...@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 <ac...@redhat.com>
> > wrote:
> > > >>
> > > >> > On Thu, Jan 3, 2019 at 7:12 AM Gordon Sim <gs...@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' <us...@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<ma...@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-unsubscribe@qpid.apache.org For
> > > >> > > additional commands, e-mail: users-help@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.
>
RE: [Proton-C] Discovery
Posted by HADI Ali <Al...@murex.com>.
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?
Regards,
Ali
-----Original Message-----
From: Alan Conway <ac...@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 <ra...@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 <ac...@redhat.com> wrote:
>
> > On Fri, Jan 18, 2019 at 10:35 AM Alan Conway <ac...@redhat.com> wrote:
> >
> > >
> > >
> > > On Thu, Jan 17, 2019 at 6:56 AM Rabih M <ra...@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 <ac...@redhat.com>
> wrote:
> > >>
> > >> > On Thu, Jan 3, 2019 at 7:12 AM Gordon Sim <gs...@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' <us...@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<ma...@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-unsubscribe@qpid.apache.org For
> > >> > > additional commands, e-mail: users-help@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.
Re: [Proton-C] Discovery
Posted by Alan Conway <ac...@redhat.com>.
On Thu, Jan 24, 2019 at 8:28 AM Rabih M <ra...@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 <ac...@redhat.com> wrote:
>
> > On Fri, Jan 18, 2019 at 10:35 AM Alan Conway <ac...@redhat.com> wrote:
> >
> > >
> > >
> > > On Thu, Jan 17, 2019 at 6:56 AM Rabih M <ra...@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 <ac...@redhat.com>
> wrote:
> > >>
> > >> > On Thu, Jan 3, 2019 at 7:12 AM Gordon Sim <gs...@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' <us...@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<ma...@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-unsubscribe@qpid.apache.org
> > >> > > For additional commands, e-mail: users-help@qpid.apache.org
> > >> > >
> > >> > >
> > >> >
> > >>
> > >
> >
>
Re: [Proton-C] Discovery
Posted by Rabih M <ra...@gmail.com>.
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.
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.
Best regards,
Rabih
On Fri, Jan 18, 2019 at 4:58 PM Alan Conway <ac...@redhat.com> wrote:
> On Fri, Jan 18, 2019 at 10:35 AM Alan Conway <ac...@redhat.com> wrote:
>
> >
> >
> > On Thu, Jan 17, 2019 at 6:56 AM Rabih M <ra...@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 <ac...@redhat.com> wrote:
> >>
> >> > On Thu, Jan 3, 2019 at 7:12 AM Gordon Sim <gs...@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' <us...@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<ma...@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-unsubscribe@qpid.apache.org
> >> > > For additional commands, e-mail: users-help@qpid.apache.org
> >> > >
> >> > >
> >> >
> >>
> >
>
Re: [Proton-C] Discovery
Posted by Alan Conway <ac...@redhat.com>.
On Fri, Jan 18, 2019 at 10:35 AM Alan Conway <ac...@redhat.com> wrote:
>
>
> On Thu, Jan 17, 2019 at 6:56 AM Rabih M <ra...@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 <ac...@redhat.com> wrote:
>>
>> > On Thu, Jan 3, 2019 at 7:12 AM Gordon Sim <gs...@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' <us...@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<ma...@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-unsubscribe@qpid.apache.org
>> > > For additional commands, e-mail: users-help@qpid.apache.org
>> > >
>> > >
>> >
>>
>
Re: [Proton-C] Discovery
Posted by Alan Conway <ac...@redhat.com>.
On Thu, Jan 17, 2019 at 6:56 AM Rabih M <ra...@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)
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 <ac...@redhat.com> wrote:
>
> > On Thu, Jan 3, 2019 at 7:12 AM Gordon Sim <gs...@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' <us...@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<ma...@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-unsubscribe@qpid.apache.org
> > > For additional commands, e-mail: users-help@qpid.apache.org
> > >
> > >
> >
>
Re: [Proton-C] Discovery
Posted by Rabih M <ra...@gmail.com>.
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 <ac...@redhat.com> wrote:
> On Thu, Jan 3, 2019 at 7:12 AM Gordon Sim <gs...@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' <us...@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<ma...@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-unsubscribe@qpid.apache.org
> > For additional commands, e-mail: users-help@qpid.apache.org
> >
> >
>
Re: [Proton-C] Discovery
Posted by Alan Conway <ac...@redhat.com>.
On Thu, Jan 3, 2019 at 7:12 AM Gordon Sim <gs...@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' <us...@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<ma...@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-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
Re: [Proton-C] Discovery
Posted by Gordon Sim <gs...@redhat.com>.
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?)
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' <us...@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<ma...@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-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
RE: [Proton-C] Discovery
Posted by VERMEULEN Olivier <Ol...@murex.com>.
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' <us...@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<ma...@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.
RE: [Proton-C] Discovery
Posted by VERMEULEN Olivier <Ol...@murex.com>.
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
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.