Publishing a message using the kombu connection autoretry method may
allow exceptions from the py-amqp library to be raised up to the
application. This does not conform to the documented oslo.messaging
API.
Enhance the try except block to capture any exception and translate it
into a MessageDeliveryFailure.
There are a few cases where exceptions will be raised during autoretry
publishing: recoverable connection or channel errors, and
non-recoverable connection or channel errors.
autoretry will only retry if the error is recoverable. Non recoverable
errors are re-raised immediately regardless of the retry count.
In the case of a recoverable error it seems unlikely that retrying
either the connection or the channel yet again is going to get us
anywhere, so in this case we simply clean up the channel state, log an
error and fail the operation.
In the case of non-recoverable error we are out of luck (think
authentication failure) - further retrying will not help. Best we can
do is clean up state and log the heck out of it.
Reviewed: https:/ /review. openstack. org/486706 /git.openstack. org/cgit/ openstack/ oslo.messaging/ commit/ ?id=f059bba6ae9 642675bc1c9004a 4a4adc5d1b19a6
Committed: https:/
Submitter: Jenkins
Branch: master
commit f059bba6ae96426 75bc1c9004a4a4a dc5d1b19a6
Author: Kenneth Giusti <email address hidden>
Date: Mon Jul 24 13:36:17 2017 -0400
Prevent rabbit from raising unexpected exceptions
Publishing a message using the kombu connection autoretry method may
allow exceptions from the py-amqp library to be raised up to the
application. This does not conform to the documented oslo.messaging
API.
Enhance the try except block to capture any exception and translate it Failure.
into a MessageDelivery
There are a few cases where exceptions will be raised during autoretry
publishing: recoverable connection or channel errors, and
non-recoverable connection or channel errors.
autoretry will only retry if the error is recoverable. Non recoverable
errors are re-raised immediately regardless of the retry count.
In the case of a recoverable error it seems unlikely that retrying
either the connection or the channel yet again is going to get us
anywhere, so in this case we simply clean up the channel state, log an
error and fail the operation.
In the case of non-recoverable error we are out of luck (think
authentication failure) - further retrying will not help. Best we can
do is clean up state and log the heck out of it.
Change-Id: I2f65d2ee19a8c3 e9a323b30404abb f0cbb45a216
Closes-Bug: #1705351
Closes-Bug: #1707160