IoReceiver thread can "dead lock" itself for 60 seconds after receiving execution exception from broker and sending session controls to close other connection sessions. This issue can occur in the following scenario:
- broker sends execution exception
- client receives execution exception and populates field org.apache.qpid.client.AMQSession_0_10#_currentException as part of org.apache.qpid.client.AMQSession_0_10#setCurrentException. The field is set using synchronization lock org.apache.qpid.client.AMQSession_0_10#_currentExceptionLock. However, the field is referenced later in org.apache.qpid.client.AMQSession_0_10#setCurrentException without the synchronization lock. It could be reset (set to null) from the application main thread as part of call org.apache.qpid.client.AMQSession#checkNotClosed whilst the execution of org.apache.qpid.client.AMQSession_0_10#setCurrentException is still in progress. As result, org.apache.qpid.client.AMQSession_0_10#_currentException can have null value when method org.apache.qpid.client.AMQConnection#exceptionReceived is invoked from org.apache.qpid.client.AMQSession_0_10#setCurrentException. "null cause" is interpreted as "hard error" causing to close other sessions and connection from IoReceiver thread. Whilst closing session or connection, the client waits for the broker responses, however, it cannot get them as IoReceiver thread is blocked. Wen should not wait for any broker responses in IoReceiver thread.
Thus, we have 2 issues here:
- org.apache.qpid.client.AMQSession_0_10#_currentException should not be referenced without a synchronization lock
- the client should not wait for broker responses in IoReceiver thread (i.e. session or connection close should not be performed in IoReceiver thread)