diff options
| author | Bogdan Dobrelya <bdobrelia@mirantis.com> | 2014-05-26 13:28:40 +0300 |
|---|---|---|
| committer | Bogdan Dobrelya <bdobrelia@mirantis.com> | 2014-05-28 10:26:25 +0300 |
| commit | 06eb8bc53225c2b58cd2ffeedad17b7428b5f1de (patch) | |
| tree | 9a294c088063253211ae28ed72d93ddc4f20d015 | |
| parent | 94c12fd76c8b92a4d25f952fc760466c22213fe2 (diff) | |
| download | ceilometer-06eb8bc53225c2b58cd2ffeedad17b7428b5f1de.tar.gz | |
Sync kombu_reconnect_delay from Oslo
When reconnecting to a RabbitMQ cluster
with mirrored queues in use, the attempt to release the
connection can hang "indefinitely" somewhere deep down
in Kombu. Blocking the thread for a bit prior to
release seems to kludge around the problem where it is
otherwise reproduceable.
The value 5.0 fits for low perfomance environments as well.
Cherry-picked from Oslo.messaging:
fcd51a67d18a9e947ae5f57eafa43ac756d1a5a8
Related-bug: #856764
Change-Id: Ifadda4dd9122df9ccb4ecf560ce3db3e38adf2b9
Signed-off-by: Bogdan Dobrelya <bdobrelia@mirantis.com>
| -rw-r--r-- | ceilometer/openstack/common/rpc/impl_kombu.py | 15 |
1 files changed, 15 insertions, 0 deletions
diff --git a/ceilometer/openstack/common/rpc/impl_kombu.py b/ceilometer/openstack/common/rpc/impl_kombu.py index c8a6de0e..99e4e999 100644 --- a/ceilometer/openstack/common/rpc/impl_kombu.py +++ b/ceilometer/openstack/common/rpc/impl_kombu.py @@ -52,6 +52,10 @@ kombu_opts = [ default='', help=('SSL certification authority file ' '(valid only if SSL enabled)')), + cfg.FloatOpt('kombu_reconnect_delay', + default=1.0, + help='How long to wait before reconnecting in response to an ' + 'AMQP consumer cancel notification.'), cfg.StrOpt('rabbit_host', default='localhost', help='The RabbitMQ broker address where a single node is used'), @@ -495,6 +499,17 @@ class Connection(object): LOG.info(_("Reconnecting to AMQP server on " "%(hostname)s:%(port)d") % params) try: + # NOTE(bogdando): when reconnecting to a RabbitMQ cluster + # with mirrored queues in use, the attempt to release the + # connection can hang "indefinitely" somewhere deep down + # in Kombu. Blocking the thread for a bit prior to + # release seems to kludge around the problem where it is + # otherwise reproduceable. + if self.conf.kombu_reconnect_delay > 0: + LOG.info(_("Delaying reconnect for %1.1f seconds...") % + self.conf.kombu_reconnect_delay) + time.sleep(self.conf.kombu_reconnect_delay) + self.connection.release() except self.connection_errors: pass |