activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Bish (JIRA)" <>
Subject [jira] [Resolved] (AMQ-3319) A possible browsing concurrency issue in
Date Sat, 02 Jul 2011 16:40:21 GMT


Timothy Bish resolved AMQ-3319.

       Resolution: Fixed
    Fix Version/s: 5.6.0
         Assignee: Timothy Bish

Verified that the queue is not protected and the read lock around that code is not needed
once the code is switched to a ConcurrentLinkQueue.

Nice catch, thanks!

> A possible browsing concurrency issue in
> --------------------------------------------------------------------------------
>                 Key: AMQ-3319
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.4.2
>         Environment: OS X, Linux
>            Reporter: Przemek Bruski
>            Assignee: Timothy Bish
>             Fix For: 5.6.0
>         Attachments: patch.diff
> Some time ago clients of our ActiveMQ instance locked up while browsing. Analysis of
the log files showed a large amount of:
> {code}
>  java.util.NoSuchElementException
> 	at java.util.LinkedList.remove(
> 	at java.util.LinkedList.removeFirst(
> 	at
> 	at
> 	at org.apache.activemq.thread.PooledTaskRunner.runTask(
> 	at org.apache.activemq.thread.PooledTaskRunner$
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(
> 	at java.util.concurrent.ThreadPoolExecutor$
> 	at
> {code}
> Happening before lockup.
> It seems there is a problem in Queue class, which uses non thread safe LinkedList collection.
Additions and removals to/from this collection are wrapped by a shared readLock, which means
there is no guard against concurrent modification and there is also a possibility of a race
condition between isEmpty and removeFirst call during concurrent usages of getNextBrowserDispatch
(if they are possible).
> I think the easiest fix is to switch from LinkedList to ConcurrentLinkedQueue and make
use of Queue methods to access the collection (because they allow single step isEmpty/remove
call). I am attaching a patch that does it. I've left the readLocks in case they are used
to block writes someplace else, but they are not needed anymore for concurrency control over
the new collection.

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message