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

1 files changed, 1 insertions, 1 deletions

diff --git a/oslo_messaging/_drivers/impl_rabbit.py b/oslo_messaging/_drivers/impl_rabbit.py
index 72dd62a..b9ff363 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.'),