From 8c03a6db6c0396099e7425834998da5478a1df7c Mon Sep 17 00:00:00 2001
From: Mehdi Abaakouk <sileht@redhat.com>
Date: Wed, 2 Dec 2015 09:39:37 +0100
Subject: [PATCH] default of kombu_missing_consumer_retry_timeout
This change the default of kombu_missing_consumer_retry_timeout
The initial value of 60 seconds, have been chosen because the default
rpc_response_timeout is 60. That means, the client doesn't wait for
its reply after rpc_response_timeout is reach, so we don't need
to retry it send it its reply more than rpc_response_timeout.
But the real intent of kombu_missing_consumer_retry_timeout is
to mitigate the side effect when the rabbitmq server(s) died/failover/restart.
So the question is more how long we expect the server(s) to come back
and all the oslo.messaging applications to reconnect.
In that case 60 seconds looks a bit high.
Also this 60 seconds have a sad side effect when we can't send the reply
when the rpc client is really gone (like nova-compute restart).
The rabbitmq connection to send the reply is hold during 60 seconds.
I propose 5 seconds because,i n case of failover or restart I expect
everything because normal in less that 5 seconds.
Change-Id: I2ec174e440eb91e950d9453a9de8b97ed5888968
---
oslo_messaging/_drivers/impl_rabbit.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/oslo_messaging/_drivers/impl_rabbit.py b/oslo_messaging/_drivers/impl_rabbit.py
index 72dd62af3..b9ff36353 100644
--- a/oslo_messaging/_drivers/impl_rabbit.py
+++ b/oslo_messaging/_drivers/impl_rabbit.py
@@ -75,7 +75,7 @@ rabbit_opts = [
'AMQP consumer cancel notification.'),
cfg.IntOpt('kombu_missing_consumer_retry_timeout',
deprecated_name="kombu_reconnect_timeout",
- default=60,
+ default=5,
help='How long to wait a missing client beforce abandoning to '
'send it its replies. This value should not be longer '
'than rpc_response_timeout.'),