[ 
https://issues.apache.org/jira/browse/AMQ-5263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jiang Fuqiang updated AMQ-5263:
-------------------------------

    Description: 
If ActiveMQSession.close()  and  ActiveMQSession.dispose() run concurrently,  
the statements in close() method might throw NullPointerException。Just marked 
by the following code snippet.
-------------------------------
    public void ActiveMQSession.close() throws JMSException {
        if (!closed) {
            if (getTransactionContext().isInXATransaction()) { // it might 
throw NullPointerException
                        ...
-------------------------------
In my application, I call Session.close() when I detect JMSException, but 
Session.close() throws NullPointerException occasionally。I suspect that's 
because ActiveMQConnection called ActiveMQSession.dispose() in case of 
transport error, and  ActiveMQSession.dispose() nullified 
ActiveMQSession.transactionContext before ActiveMQSession.closed is assigned to 
false. Since this NullPointerException error just happened once and can not be 
reproduced, it's only a suspection. 

It seems that close() and dispose() should be synchronized, and then session 
can be closed safely.

I'm not good at English, but I hope this issue is demonstrated clearly enough.

  was:
If ActiveMQSession.close()  and  ActiveMQSession.dispose() run concurrently,  
the statements in close() method might throw NullPointerException。Just marked 
by the following code snippet.
-------------------------------
    public void ActiveMQSession.close() throws JMSException {
        if (!closed) {
            if (getTransactionContext().isInXATransaction()) { // it might 
throw NullPointerException
                        ...
-------------------------------
In my application, I call Session.close() when I detect JMSException, but 
Session.close() throws NullPointerException at one time。
I suspect that's because ActiveMQConnection called ActiveMQSession.dispose() in 
case of transport error, and  ActiveMQSession.dispose() nullified 
ActiveMQSession.transactionContext before ActiveMQSession.closed is assigned to 
false.
Since this NullPointerException error just happened once and can not be 
reproduced, it's only a suspection. 

It seems that close() and dispose() should be synchronized, and then session 
can be closed safely.

I'm not good at English, but I hope this issue is demonstrated clearly enough.


> Method ActiveMQSession.close() is not thread safe as declared and required
> --------------------------------------------------------------------------
>
>                 Key: AMQ-5263
>                 URL: https://issues.apache.org/jira/browse/AMQ-5263
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: JMS client
>    Affects Versions: 5.9.1
>         Environment: any operationg system, and any platform
>            Reporter: Jiang Fuqiang
>
> If ActiveMQSession.close()  and  ActiveMQSession.dispose() run concurrently,  
> the statements in close() method might throw NullPointerException。Just marked 
> by the following code snippet.
> -------------------------------
>     public void ActiveMQSession.close() throws JMSException {
>         if (!closed) {
>             if (getTransactionContext().isInXATransaction()) { // it might 
> throw NullPointerException
>                       ...
> -------------------------------
> In my application, I call Session.close() when I detect JMSException, but 
> Session.close() throws NullPointerException occasionally。I suspect that's 
> because ActiveMQConnection called ActiveMQSession.dispose() in case of 
> transport error, and  ActiveMQSession.dispose() nullified 
> ActiveMQSession.transactionContext before ActiveMQSession.closed is assigned 
> to false. Since this NullPointerException error just happened once and can 
> not be reproduced, it's only a suspection. 
> It seems that close() and dispose() should be synchronized, and then session 
> can be closed safely.
> I'm not good at English, but I hope this issue is demonstrated clearly enough.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to