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 <bon...@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
