Unhandled errors in the Qpid consuming thread could kill it silently and isolate the component from the rest of the system. To fix this, the consuming thread has been made more resilient to errors by ensuring it doesn't die on an unhandled error. Compute now logs the error and retries the consuming thread.
Created attachment 847344[details]
backport of fix for nova
The code for receiving and processing qpid messages runs in its own greenthread. Unfortunately, there is a code path that if it raises an exception, the greenthread will die silently, without any entry in the log file.
In particular, the code in question is:
https://git.openstack.org/cgit/openstack/nova/tree/nova/openstack/common/rpc/impl_qpid.py?h=stable/grizzly#n468
if self.session.next_receiver() raises an exception other than qpid's Empty or ConnectionError exceptions, the thread will die and no more messages will be received.
The fix is to backport the portion of the following change that applies to impl_qpid. That includes the new decorator in excutils and the change to impl_qpid.py.
Created attachment 847690[details]
reproducing failure mode
Just so I don't forget it, this is how I tested this bug (attached patch). I used the attached patch for force an exception to occur in the qpid reply thread roughly 30 seconds after the nova-compute service started. With the @excutils.forever_retry_uncaught_exceptions decorator applied, the exception is logged and operation continues normally. Without the decorator, the thread dies silently, and the only entries in the compute log are from where nova-compute no longer receives any responses. You see timeout errors waiting for responses from conductor.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
http://rhn.redhat.com/errata/RHSA-2014-0112.html