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 <[email protected]> Sent: vendredi 13 décembre 2019 17:12 To: [email protected] 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: [email protected] For additional commands, e-mail: [email protected] ******************************* 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.
