activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Tully <gary.tu...@gmail.com>
Subject Re: ConcurrentModificationException while closing consumer
Date Fri, 06 Feb 2009 11:38:14 GMT
Hi Bonny,
that looks like a bug indeed, should be easy to replicate in a Junit
tests case I think. Could you raise a jira issue for this and if you
have some tests code that demonstrates, please include it.

for more info see: http://activemq.apache.org/contributing.html

Thanks,
Gary.

2009/2/6 bonnyr <bonnyr@optusnet.com.au>:
>
> AMQ 5.1 (but problem exists in the sources of AMQ-5.2 as of today)
>
> My setup:
> * Broker is configured with a single queue, full with messages, on a host
> accessible via the network.
> * Application configured with a single consumer, connected to a single
> sesssion, running in its own thread.
> * ActiveMQ delivers lots of messages using one of the ActiveMQSessionTask
> threads.
> * Session configured as CLIENT_ACKNOLEDGE
>
>
> Since the queue is full of messages, delivery of these messages happen as
> fast as the network
> can deliver and the AMQ thread is invoking the onMessage with each new
> message. These messages
> are then processed by the consumer thread. The consumer thread then decides
> to close the connection
> and the following ensues:
> [code]
> java.util.ConcurrentModificationException
>        at
> java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:617)
>        at java.util.LinkedList$ListItr.next(LinkedList.java:552)
>        at
> org.apache.activemq.ActiveMQMessageConsumer.dispose(ActiveMQMessageConsumer.java:663)
>        at
> org.apache.activemq.ActiveMQMessageConsumer.close(ActiveMQMessageConsumer.java:583)
>        at
> com.xxx.app..AMsgQueueConsumer.doClose(AMsgQueueConsumer.java:351)
>        at com.xxx.app.AMsgQueueConsumer.suspend
>
>        ... snip ...
>
> [/code]
>
> This happens because AMQ is busy delivering messages and there is a
> collection [b]deliveredMessages[/b] that is
> not protected by synchronisation in exactly one place (everywhere else it
> is...) which is executing the
> following code (in the dispose method):
> [code]
>  ... snip ...
>            if (session.isClientAcknowledge()) {
>                if (!this.info.isBrowser()) {
>                    // rollback duplicates that aren't acknowledged
>                    for (MessageDispatch old : deliveredMessages) {
>                        session.connection.rollbackDuplicate(this,
> old.getMessage());
>                    }
>                }
>            }
>  ... snip ...
> [/code]
>
> Since the code iterates over the collection, and the iterator checks for
> modifications to the underlying collection, and since the AMQ message
> delivery thread has managed to sneak in a couple more messages
> while the consumer thread attempted to close the connection, the problem
> occurs (it could be that
> the for syntax hides the explicit iterator calls, but...)
>
>
> Is this an ommission or is there a reason for not synchronising access to
> this collection? If it's not a bug
> then how should the consumer be disconnected?
>
> Cheers,
>
> Bonny
> --
> View this message in context: http://www.nabble.com/ConcurrentModificationException-while-closing-consumer-tp21867250p21867250.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
>



-- 
http://blog.garytully.com

Open Source SOA
http://FUSESource.com

Mime
View raw message