In an HA deployment, a 60 seconds delay between reconnects can be quite
problematic. This patch changes the delay calculation by setting the max
delay to 5s and by changing the way it is increased.
Unfortunately, this is one of the places where both our main drivers are
not consistent. Rabbit's driver uses configuration parameters for this
whereas qpid's driver has never had one. However, I would prefer not
adding configuration paremeters to qpid's driver for the following
reasons:
1. Most of OpenStack services depend on the messaging layer, hence
they need it to be available. A 5s delay seems to be reasonable and
I could argue the need of tune it further. Although so frequent
reconnects can add load to the network, that wouldn't be the main
issue if one of the brokers go down.
2. We're trying to move away from configuration options towards using
transport URL. This path is still not clear and I would
prefer avoiding adding new options until we clear it out.
Closes-bug: #1281148
Change-Id: I537015f452eb770acba41fdedfe221628f52a920
(cherry picked from commit 8b628d1e024f787dbb93d508117d9148388c0590)
Reviewed: https:/ /review. openstack. org/83686 /git.openstack. org/cgit/ openstack/ cinder/ commit/ ?id=c5cdf8261d9 f7fb42ca59a1255 4d1c0ed9cb0a7e
Committed: https:/
Submitter: Jenkins
Branch: stable/havana
commit c5cdf8261d9f7fb 42ca59a12554d1c 0ed9cb0a7e
Author: Flavio Percoco <email address hidden>
Date: Tue Feb 18 10:56:21 2014 +0100
User a more accurate max_delay for reconnects
In an HA deployment, a 60 seconds delay between reconnects can be quite
problematic. This patch changes the delay calculation by setting the max
delay to 5s and by changing the way it is increased.
Unfortunately, this is one of the places where both our main drivers are
not consistent. Rabbit's driver uses configuration parameters for this
whereas qpid's driver has never had one. However, I would prefer not
adding configuration paremeters to qpid's driver for the following
reasons:
1. Most of OpenStack services depend on the messaging layer, hence
they need it to be available. A 5s delay seems to be reasonable and
I could argue the need of tune it further. Although so frequent
reconnects can add load to the network, that wouldn't be the main
issue if one of the brokers go down.
2. We're trying to move away from configuration options towards using
transport URL. This path is still not clear and I would
prefer avoiding adding new options until we clear it out.
Closes-bug: #1281148
Change-Id: I537015f452eb77 0acba41fdedfe22 1628f52a920 dbb93d508117d91 48388c0590)
(cherry picked from commit 8b628d1e024f787