You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2017/12/06 13:47:00 UTC

[jira] [Commented] (QPID-8057) [JMS AMQP 0-x][AMQP 0-10] IoReceiver thread can block itself for 60 seconds after sending session close controls and waiting for broker responses

    [ https://issues.apache.org/jira/browse/QPID-8057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16280196#comment-16280196 ] 

ASF subversion and git services commented on QPID-8057:
-------------------------------------------------------

Commit 7fe48d96b4aa5e13b1b33abd6db573904f8aab00 in qpid-jms-amqp-0-x's branch refs/heads/master from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms-amqp-0-x.git;h=7fe48d9 ]

QPID-8057: [JMS AMQP 0-x][AMQP 0-10] Fix race on handling of execution exception


> [JMS AMQP 0-x][AMQP 0-10] IoReceiver thread can block itself for 60 seconds after sending session close controls and waiting for broker responses
> -------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: QPID-8057
>                 URL: https://issues.apache.org/jira/browse/QPID-8057
>             Project: Qpid
>          Issue Type: Bug
>          Components: JMS AMQP 0-x
>    Affects Versions: qpid-java-6.0.8, qpid-java-client-0-x-6.3.0, qpid-java-6.1.5
>            Reporter: Alex Rudyy
>         Attachments: TEST-org.apache.qpid.test.unit.transacted.TransactionTimeoutTest.testProducerOpenCommit.txt
>
>
> 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)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org