[
https://issues.apache.org/jira/browse/AMQ-3276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Tully resolved AMQ-3276.
-----------------------------
Resolution: Fixed
Fix Version/s: 5.6.0
Assignee: Gary Tully
reverted the explicit copy/set of the MDC context on thread creation as the
underlying mdc impl used an inherited thread local for the context which makes
the copy unnecessary and can cause contention.
the changes in http://svn.apache.org/viewvc?view=revision&revision=1090320
should resolve the concurrent mod exception. I kicked off a new 5.6-SNAPSHOT
deploy so if you get a chance please validate.
> ConcurrentModificationException in embedded 5.5.0 broker
> --------------------------------------------------------
>
> Key: AMQ-3276
> URL: https://issues.apache.org/jira/browse/AMQ-3276
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.5.0
> Environment: jdk 1.6.0_24, Spring 3.0.5, ActiveMQ 5.5.0, Camel 2.7.0,
> slf4j 1.6.1
> Reporter: Dan Checkoway
> Assignee: Gary Tully
> Fix For: 5.6.0
>
>
> We just migrated from ActiveMQ 5.4.2 to ActiveMQ 5.5.0. So far so good, with
> one exception (pun not intended). In one case where we have an embedded
> broker, we're seeing this exception get logged on occasion:
> WARNING; 08-Apr-2011 11:11:41; tid:45931; TransportConnection stopAsync;
> cannot create async transport stopper thread.. not waiting for stop to
> complete, reason:
> java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
> at java.util.HashMap$EntryIterator.next(HashMap.java:834)
> at java.util.HashMap$EntryIterator.next(HashMap.java:832)
> at java.util.HashMap.putAllForCreate(HashMap.java:435)
> at java.util.HashMap.<init>(HashMap.java:225)
> at
> org.slf4j.helpers.BasicMDCAdapter.getCopyOfContextMap(BasicMDCAdapter.java:130)
> at org.slf4j.MDC.getCopyOfContextMap(MDC.java:182)
> at
> org.apache.activemq.util.MDCHelper.getCopyOfContextMap(MDCHelper.java:30)
> at
> org.apache.activemq.broker.TransportConnection.stopAsync(TransportConnection.java:946)
> at
> org.apache.activemq.broker.TransportConnection.processShutdown(TransportConnection.java:353)
> at
> org.apache.activemq.command.ShutdownInfo.visit(ShutdownInfo.java:35)
> at
> org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:306)
> at
> org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:179)
> at
> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:116)
> at
> org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:69)
> at
> org.apache.activemq.transport.vm.VMTransport.iterate(VMTransport.java:218)
> at
> org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:127)
> at
> org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:48)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Up until this morning, I had only seen that logged during shutdown of the app
> context. But just now, it popped out independently, out of the blue.
> For what it's worth, here's the app context config:
>
> <broker xmlns="http://activemq.apache.org/schema/core";
> id="embeddedActivemqBroker"
> useJmx="true"
> persistent="true"
> schedulerSupport="false"
> advisorySupport="false"
> enableStatistics="true">
> <destinationPolicy>
> <policyMap>
> <policyEntries>
> <policyEntry queue=">" producerFlowControl="false"
> memoryLimit="20mb"/>
> </policyEntries>
> </policyMap>
> </destinationPolicy>
> <persistenceAdapter>
> <kahaDB directory="${EmbeddedBroker.dataDirectory}"
> concurrentStoreAndDispatchQueues="false"/>
> </persistenceAdapter>
> </broker>
> Has anybody else seen this ConcurrentModificationException happening with
> 5.5.0 (or otherwise)? Any ideas?
> I suppose I should also mention that we're using slf4j 1.6.1. Not sure if
> that has anything to do with this, since the stack trace does show it
> happening in slf4j land...
> <dependency>
> <groupId>org.slf4j</groupId>
> <artifactId>slf4j-api</artifactId>
> <version>1.6.1</version>
> <scope>runtime</scope>
> </dependency>
> <dependency>
> <groupId>org.slf4j</groupId>
> <artifactId>slf4j-jdk14</artifactId>
> <version>1.6.1</version>
> <scope>runtime</scope>
> </dependency>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
