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 Mon, 09 Feb 2009 10:42:14 GMT
> 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 <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
>>
>>
>
> --
> 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

Mime
View raw message