Details
Major Description
There is a deadlock condition in the Qpid JCA adapter. For inbound messaging,
endpoint activation is handled by the QpidActivation.SetupActivation class.
This class is a Work instance and is submitted to the JCA WorkManager, as such
it is run in a separate thread.
In the case where the initial activation call blocks (e.g. invalid durable
subscription names), the IOReceiver thread receives an exception prior to the
QpidActivation class every being property initialized. On an exception we
attempt to teardown and setup the activation again. However, at this point the
QpidActivation instance is locked by the JCA Work manager, as such, the
IOReceiver thread (or any other that received the exception first), can't make
forward progress because the QpidActivation class has been locked. Both the
setup() and teardown() methods are synchronized and prohibit forward progress
since the JCA Work Manager already has a lock on the instance.
Steps to Reproduce:
1. Deploy the Qpid JCA adapter
2. Create a Topic Destination via *-ds.xml file.
3. Deploy an MDB, using a durable subscription with a name that does not exist.
Actual results:
JBoss EAP (and Geronimo) locks up and as such, does not allow a graceful shutdown without
resorting to kill - <pid> or other extraordinary measures. Run jstack <pid> to
review the deadlock condition.
The QpidActivation class contains a a SetupActivation class that is only
responsible for setting up the initial connection/session etc. It shares the
same code with the QpidActivation as a whole most notably the onException(),
handleFailure() code. If the initial setup fails, or blocks, other threads
receive the onException() invocation and attempt to teardown() and setup() the
activation again. Since the instance is blocked, a deadlock occurs.