> I'm not quite able to cause this to happen in a simple test case. Perhaps > this is to do with some > thread timing/scheduling issues in the simple test case vs our application. > Yea, that is fairly typical.
> However, are you in a > position to explain what the deliveredMessage collection is used for? Is it > not used in all connection/ > ack modes? > Sure, the deliveredMessage list is used to generate acks in the Auto ack mode. In addition, with the consumer optimizeAcknowledge option, there is more likely to be some outstanding delivered messages that require acks. On close, any outstanding acks will require delivery so you may run into contention with concurrent delivery and close execution as you suggest. May I suggest using AUTO_ACK and additionally using optimizeAcknowledge if needed. > Perhaps if I knew what the behaviour should be like, I'd be able > to construct a test > case that simulate our environment. > Hopefully :-) Gary. > Cheers, > > Bonny > > > Gary Tully wrote: >> >> 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 >> >> > > -- > View this message in context: > http://www.nabble.com/ConcurrentModificationException-while-closing-consumer-tp21867250p21907669.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. > > -- http://blog.garytully.com Open Source SOA http://FUSESource.com
