[jboss-jira] [JBoss JIRA] Updated: (JBAS-4090) Race condition in Connection.close() can deadlock the JBossMQ's ping thread.

[Adrian Brock (JIRA)]

     [ http://jira.jboss.com/jira/browse/JBAS-4090?page=all ]

Adrian Brock updated JBAS-4090:
-------------------------------

    Fix Version/s: JBossAS-5.0.0.Beta2
                   JBossAS-4.2.0.CR1
      Description: 
There is a race condition between the JBossMQ ping thread and connection.close()
that can cause the ping thread to become deadlocked.
Besides meaning that the ping stops working so broken connections are not detected,
this can also evenutally lead to a memory leak.

The problem occurs when the connection.close()
requests to cancel the ping for that connection, and then aquires the semaphore
to make sure the ping has stopped working.

Just at that moment, the ping was scheduled to run and tries to aquire the semaphore
(with no timeout), but it never can because the connection.close() has permenantly
aquired it.

The obvious fix is to include a timeout in the ping task such that when it fails
to acquire the semaphore it can assume that the connection was closed and return
immediately.

Additionally, checking the "closing" flag should also avoid even trying to acquire
the semaphore when the connection is being closed (in most cases).

  was:
There is a race condition between the JBossMQ ping thread and connection.close()
that can cause the ping thread to become deadlocked.
Besides meaning that the ping stops working so broken connections are not detected,
this can also evenutally lead to a memory leak.

The problem occurs when the connection.close()
requests to cancel the ping for that connection, and then aquires the semaphore
to make sure the ping has stopped working.

Just at that moment, the ping was scheduled to run and tries to aquire the semaphore
(with no timeout), but it never can because the connection.close() has permenantly
aquired it.

The obvious fix is to include a timeout in the ping task's such that when it fails
to acquire the semaphore it can assume that the connection was closed and return
immediately.

Additionally, checking the "closing" flag should also avoid even trying to acquire
the semaphore when the connection is being closed (in most cases).


> Race condition in Connection.close() can deadlock the JBossMQ's ping thread.
> ----------------------------------------------------------------------------
>
>                 Key: JBAS-4090
>                 URL: http://jira.jboss.com/jira/browse/JBAS-4090
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JMS service
>    Affects Versions: JBossAS-5.0.0.Beta1, JBossAS-4.0.5.GA, JBossAS-3.2.8.SP1
>            Reporter: Adrian Brock
>         Assigned To: Adrian Brock
>             Fix For: JBossAS-4.0.5.SP1 , JBossAS-5.0.0.Beta2, JBossAS-4.2.0.CR1
>
>
> There is a race condition between the JBossMQ ping thread and connection.close()
> that can cause the ping thread to become deadlocked.
> Besides meaning that the ping stops working so broken connections are not detected,
> this can also evenutally lead to a memory leak.
> The problem occurs when the connection.close()
> requests to cancel the ping for that connection, and then aquires the semaphore
> to make sure the ping has stopped working.
> Just at that moment, the ping was scheduled to run and tries to aquire the semaphore
> (with no timeout), but it never can because the connection.close() has permenantly
> aquired it.
> The obvious fix is to include a timeout in the ping task such that when it fails
> to acquire the semaphore it can assume that the connection was closed and return
> immediately.
> Additionally, checking the "closing" flag should also avoid even trying to acquire
> the semaphore when the connection is being closed (in most cases).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira