Back to bug 1312912

Who When What Removed Added
Red Hat Bugzilla Rules Engine 2016-02-29 14:03:29 UTC Target Release --- 8.0
Flavio Percoco 2016-03-01 18:57:35 UTC Status NEW POST
Flavio Percoco 2016-03-01 18:59:22 UTC Blocks 1313522
Victor Stinner 2016-03-17 14:10:11 UTC Status POST MODIFIED
CC vstinner
Fixed In Version python-oslo-messaging-2.5.0-5.el7ost
errata-xmlrpc 2016-03-17 19:57:03 UTC Status MODIFIED ON_QA
Udi Shkalim 2016-03-20 16:30:20 UTC QA Contact ushkalim lnatapov
Jon Schlueter 2016-03-21 12:07:24 UTC CC jschluet
Target Milestone --- ga
Tom Barron 2016-03-23 13:16:57 UTC CC tbarron
Doc Text Cause:

When the RabbitMQ service fails to deliver an AMQP message from one OpenStack service to another, it will re-connect and retry delivery. The 'rabbit_retry_backoff' option, whose default is 2 seconds, is supposed to control the pace of retries but instead retries were being done every second irrespective of the configured value of this option.

Consequence:

Excessive retries when e.g. an endpoint is not available.


Fix:

Simple code fix.

Result:

The 'rabbit_retry_backoff' value, as explicitly configured or at the default two second value, is now used properly to pace message retries.
errata-xmlrpc 2016-03-24 13:59:37 UTC Status ON_QA VERIFIED
Radek Bíba 2016-04-06 09:23:16 UTC Doc Text Cause:

When the RabbitMQ service fails to deliver an AMQP message from one OpenStack service to another, it will re-connect and retry delivery. The 'rabbit_retry_backoff' option, whose default is 2 seconds, is supposed to control the pace of retries but instead retries were being done every second irrespective of the configured value of this option.

Consequence:

Excessive retries when e.g. an endpoint is not available.


Fix:

Simple code fix.

Result:

The 'rabbit_retry_backoff' value, as explicitly configured or at the default two second value, is now used properly to pace message retries.
When the RabbitMQ service fails to deliver an AMQP message from one OpenStack service to another, it reconnects and retries delivery. The "rabbit_retry_backoff" option, whose default is 2 seconds, is supposed to control the pace of retries; however, retries were previously done every second irrespective of the configured value of this option. The consequence of this problem was excessive retries, for example, when an endpoint was not available. This problem has now been fixed, and the "rabbit_retry_backoff" option, as explicitly configured or with the default value of two seconds, properly controls message delivery retries.
errata-xmlrpc 2016-04-07 21:31:44 UTC Status VERIFIED CLOSED
Resolution --- ERRATA
Last Closed 2016-04-07 17:31:44 UTC

Back to bug 1312912