You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Jiri Daněk <jd...@redhat.com> on 2019/09/26 08:03:46 UTC
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
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.