Recently I reworked how the Python binding reconnect logic works - this was in support of a PR raised to improve the Proton.util.BlockingConnection class which previously could not specify more than a single connection url to try.
I have changed the reconnect/failover behaviour: Before, the reconnect logic would try the next connection url and at the same time move to the next reconnect delay. I believe this was an unintended behaviour and would not be what anyone was expecting - although it might not be obvious to spot. I've changed that behaviour so that the binding now tries every specified connection url before it moves to the next reconnect interval. This seems much more intuitive to me. I've also added a new way to specify the reconnect delays - the 'reconnect' keyword parameter to Container.connect can now accept any iterable which produces an iterator over floats to specify the delay - a good example of that would be a simple list! For example: [0, 1, 2, 5, 10] will tell the reconnect logic to retry immediately then after 1, 2, 5, and 10 seconds then give up. More complex examples are also possible. The previously available Backoff class is still available and has been enhanced with some new keyword parameters to improve its controllability and flexibility (initial=0.1, factor=2.0, max_delay=10.0, max_tries=None are the keywords and defaults). The PR iself (PR243) [1] is a very simple change (once all the above has been fixed!) but it clarifies one thing that has been true for a while but still brought to light an issue in the displatch router [2]. The Proton.Url class has been deprecated for a while for application use, and should not be used to specify connection urls. It also should not be returned by the API. Unfortunately the BlockingConnection.url property was previously undocumented (and hence really not part of the API) and erroneously returning an internal use of Proton.Url. The PR changed that and it now correctly returns a string representing the actual connected url - previously it merely returned exactly the url that the application gave it. This is not possible any more (even if we wanted) as there could be more than one supplied url and we need to tell which is the actual url connected to. I hope that helps anyone who is confused/surprised by these changes. Andrew [1] https://github.com/apache/qpid-proton/pull/243 [2] https://issues.apache.org/jira/browse/DISPATCH-1913 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
