java.util.ConcurrentModificationException

There are no available Samebug tips for this exception. Do you have an idea how to solve this issue? A short tip would help users who saw this issue last week.

  • When a subscription in unregistered with remaining subscriptions in the cache, a ConcurrentModificationException is thrown by the DestinationCache class. {code} Exception in thread "clientInboundChannel-1" Exception in thread "clientInboundChannel-2" java.util.ConcurrentModificationException at java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:711) at java.util.LinkedHashMap$LinkedKeyIterator.next(LinkedHashMap.java:734) at org.springframework.messaging.simp.broker.DefaultSubscriptionRegistry$DestinationCache.updateAfterRemovedSubscription(DefaultSubscriptionRegistry.java:191) at org.springframework.messaging.simp.broker.DefaultSubscriptionRegistry.removeSubscriptionInternal(DefaultSubscriptionRegistry.java:100) at org.springframework.messaging.simp.broker.AbstractSubscriptionRegistry.unregisterSubscription(AbstractSubscriptionRegistry.java:91) at org.springframework.messaging.simp.broker.SimpleBrokerMessageHandler.handleMessageInternal(SimpleBrokerMessageHandler.java:129) at org.springframework.messaging.simp.broker.AbstractBrokerMessageHandler.handleMessage(AbstractBrokerMessageHandler.java:171) at org.springframework.messaging.support.ExecutorSubscribableChannel$1.run(ExecutorSubscribableChannel.java:70) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) java.util.ConcurrentModificationException at java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:711) at java.util.LinkedHashMap$LinkedKeyIterator.next(LinkedHashMap.java:734) at org.springframework.messaging.simp.broker.DefaultSubscriptionRegistry$DestinationCache.updateAfterRemovedSubscription(DefaultSubscriptionRegistry.java:191) at org.springframework.messaging.simp.broker.DefaultSubscriptionRegistry.removeSubscriptionInternal(DefaultSubscriptionRegistry.java:100) at org.springframework.messaging.simp.broker.AbstractSubscriptionRegistry.unregisterSubscription(AbstractSubscriptionRegistry.java:91) at org.springframework.messaging.simp.broker.SimpleBrokerMessageHandler.handleMessageInternal(SimpleBrokerMessageHandler.java:129) at org.springframework.messaging.simp.broker.AbstractBrokerMessageHandler.handleMessage(AbstractBrokerMessageHandler.java:171) at org.springframework.messaging.support.ExecutorSubscribableChannel$1.run(ExecutorSubscribableChannel.java:70) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) }} {code} The cause seems to be updateCache modification during iterating over its elements rather that concurrent access by 2 threads (updateCache modification are already synchronized). It can be fixed in DestinationCache by : - Moving the cached destinations removal outside the for loop. - Using updateCache.entrySet() instead of updateCache.keySet() + updateCache.get() in order to avoid updateCache modification during iteration. The tricky point here is we are using a LinkedHashMap with accessOrder=true. A simple updateCache.get() modify the map. By using updateCache.entrySet() we avoid this update.
    via by Sébastien Deleuze,
  • When a subscription in unregistered with remaining subscriptions in the cache, a ConcurrentModificationException is thrown by the DestinationCache class. {code} Exception in thread "clientInboundChannel-1" Exception in thread "clientInboundChannel-2" java.util.ConcurrentModificationException at java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:711) at java.util.LinkedHashMap$LinkedKeyIterator.next(LinkedHashMap.java:734) at org.springframework.messaging.simp.broker.DefaultSubscriptionRegistry$DestinationCache.updateAfterRemovedSubscription(DefaultSubscriptionRegistry.java:191) at org.springframework.messaging.simp.broker.DefaultSubscriptionRegistry.removeSubscriptionInternal(DefaultSubscriptionRegistry.java:100) at org.springframework.messaging.simp.broker.AbstractSubscriptionRegistry.unregisterSubscription(AbstractSubscriptionRegistry.java:91) at org.springframework.messaging.simp.broker.SimpleBrokerMessageHandler.handleMessageInternal(SimpleBrokerMessageHandler.java:129) at org.springframework.messaging.simp.broker.AbstractBrokerMessageHandler.handleMessage(AbstractBrokerMessageHandler.java:171) at org.springframework.messaging.support.ExecutorSubscribableChannel$1.run(ExecutorSubscribableChannel.java:70) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) java.util.ConcurrentModificationException at java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:711) at java.util.LinkedHashMap$LinkedKeyIterator.next(LinkedHashMap.java:734) at org.springframework.messaging.simp.broker.DefaultSubscriptionRegistry$DestinationCache.updateAfterRemovedSubscription(DefaultSubscriptionRegistry.java:191) at org.springframework.messaging.simp.broker.DefaultSubscriptionRegistry.removeSubscriptionInternal(DefaultSubscriptionRegistry.java:100) at org.springframework.messaging.simp.broker.AbstractSubscriptionRegistry.unregisterSubscription(AbstractSubscriptionRegistry.java:91) at org.springframework.messaging.simp.broker.SimpleBrokerMessageHandler.handleMessageInternal(SimpleBrokerMessageHandler.java:129) at org.springframework.messaging.simp.broker.AbstractBrokerMessageHandler.handleMessage(AbstractBrokerMessageHandler.java:171) at org.springframework.messaging.support.ExecutorSubscribableChannel$1.run(ExecutorSubscribableChannel.java:70) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744) }} {code} The cause seems to be updateCache modification during iterating over its elements rather that concurrent access by 2 threads (updateCache modification are already synchronized). It can be fixed in DestinationCache by : - Moving the cached destinations removal outside the for loop. - Using updateCache.entrySet() instead of updateCache.keySet() + updateCache.get() in order to avoid updateCache modification during iteration. The tricky point here is we are using a LinkedHashMap with accessOrder=true. A simple updateCache.get() modify the map. By using updateCache.entrySet() we avoid this update.
    via by Sébastien Deleuze,
  • The {{SingleConnectionFactory$AggregatedExceptionListener}} objects contains a list of delegates in a {{LinkedHashSet}}, protected by the {{SingleConnectionFactory.connectionMonitor}} lock object. If you configure a {{SingleConnectionFactory}} with {{reconnectOnException = true}}, and use it in a {{SimpleMessageListenerContainer}}, the following will happen on a {{JMSException}}: # {{SingleConnectionFactory$AggregatedExceptionListener.onException()}} is called, and starts looping over the {{delegates Set}} # At a certain point in time, it will call {{SimpleMessageListenerContainer.onException()}}, which calls {{refreshSharedConnection()}}, {{createSharedConnection()}}, {{prepareSharedConnection()}}, {{connection.setExceptionListener()}} # This modifies the {{delegates}} list (from the same thread, so the locking does not help) # A {{ConcurrentModificationException}} will be thrown in {{SingleConnectionFactory$AggregatedExceptionListener.onException()}} Full exception message: {code} Exception in thread "ActiveMQ Connection Executor: tcp://localhost/127.0.0.1:61616@52892" java.util.ConcurrentModificationException at java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:711) at java.util.LinkedHashMap$LinkedKeyIterator.next(LinkedHashMap.java:734) at org.springframework.jms.connection.SingleConnectionFactory$AggregatedExceptionListener.onException(SingleConnectionFactory.java:670) at org.apache.activemq.ActiveMQConnection$5.run(ActiveMQConnection.java:2004) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) {code} The list of delegates should probably be copied before iteration, or the {{SimpleMessageListenerContainer}} should not re-add itself as listener.
    via by Mike Noordermeer,
  • GitHub comment 6#220563410
    via GitHub by EvilOlaf
    ,
  • PermissiblePEX.calculateChildPerms
    via GitHub by JiRt
    ,
  • The {{SingleConnectionFactory$AggregatedExceptionListener}} objects contains a list of delegates in a {{LinkedHashSet}}, protected by the {{SingleConnectionFactory.connectionMonitor}} lock object. If you configure a {{SingleConnectionFactory}} with {{reconnectOnException = true}}, and use it in a {{SimpleMessageListenerContainer}}, the following will happen on a {{JMSException}}: # {{SingleConnectionFactory$AggregatedExceptionListener.onException()}} is called, and starts looping over the {{delegates Set}} # At a certain point in time, it will call {{SimpleMessageListenerContainer.onException()}}, which calls {{refreshSharedConnection()}}, {{createSharedConnection()}}, {{prepareSharedConnection()}}, {{connection.setExceptionListener()}} # This modifies the {{delegates}} list (from the same thread, so the locking does not help) # A {{ConcurrentModificationException}} will be thrown in {{SingleConnectionFactory$AggregatedExceptionListener.onException()}} Full exception message: {code} Exception in thread "ActiveMQ Connection Executor: tcp://localhost/127.0.0.1:61616@52892" java.util.ConcurrentModificationException at java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:711) at java.util.LinkedHashMap$LinkedKeyIterator.next(LinkedHashMap.java:734) at org.springframework.jms.connection.SingleConnectionFactory$AggregatedExceptionListener.onException(SingleConnectionFactory.java:670) at org.apache.activemq.ActiveMQConnection$5.run(ActiveMQConnection.java:2004) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) {code} The list of delegates should probably be copied before iteration, or the {{SimpleMessageListenerContainer}} should not re-add itself as listener.
    via by Mike Noordermeer,
    • java.util.ConcurrentModificationException at java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:711) at java.util.LinkedHashMap$LinkedKeyIterator.next(LinkedHashMap.java:734) at org.springframework.messaging.simp.broker.DefaultSubscriptionRegistry$DestinationCache.updateAfterRemovedSubscription(DefaultSubscriptionRegistry.java:191) at org.springframework.messaging.simp.broker.DefaultSubscriptionRegistry.removeSubscriptionInternal(DefaultSubscriptionRegistry.java:100) at org.springframework.messaging.simp.broker.AbstractSubscriptionRegistry.unregisterSubscription(AbstractSubscriptionRegistry.java:91) at org.springframework.messaging.simp.broker.SimpleBrokerMessageHandler.handleMessageInternal(SimpleBrokerMessageHandler.java:129) at org.springframework.messaging.simp.broker.AbstractBrokerMessageHandler.handleMessage(AbstractBrokerMessageHandler.java:171) at org.springframework.messaging.support.ExecutorSubscribableChannel$1.run(ExecutorSubscribableChannel.java:70) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:744)

    Users with the same issue

    Unknown visitor1 times, last one,
    aldrinleal
    aldrinleal2 times, last one,
    Unknown visitor1 times, last one,
    Unknown visitor1 times, last one,