org.apache.commons.lang.UnhandledException

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.

  • PermissiblePEX.calculateChildPerms
    via GitHub by JiRt
    ,
  • 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
    ,
  • 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,
    • org.apache.commons.lang.UnhandledException: Plugin Residence v4.4.1.1 generated an exception while executing task 60699 at org.bukkit.craftbukkit.v1_8_R3.scheduler.CraftAsyncTask.run(CraftAsyncTask.java:56) 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) Caused by: java.lang.RuntimeException: java.lang.reflect.InvocationTargetException at ru.tehkode.permissions.bukkit.regexperms.PermissiblePEX.calculateChildPerms(PermissiblePEX.java:195) at ru.tehkode.permissions.bukkit.regexperms.PermissiblePEX.recalculatePermissions(PermissiblePEX.java:178) at org.bukkit.craftbukkit.v1_8_R3.entity.CraftHumanEntity.recalculatePermissions(CraftHumanEntity.java:130) at org.bukkit.permissions.Permission.recalculatePermissibles(Permission.java:168) at org.bukkit.permissions.Permission.<init>(Permission.java:67) at org.bukkit.permissions.Permission.<init>(Permission.java:35) at com.bekvon.bukkit.residence.containers.PlayerGroup.getPermissionGroup(PlayerGroup.java:102) at com.bekvon.bukkit.residence.containers.PlayerGroup.updateGroup(PlayerGroup.java:69) at com.bekvon.bukkit.residence.permissions.PermissionManager.updateGroupNameForPlayer(PermissionManager.java:128) at com.bekvon.bukkit.residence.permissions.PermissionManager.updateGroupNameForPlayer(PermissionManager.java:118) at com.bekvon.bukkit.residence.listeners.ResidencePlayerListener$3.run(ResidencePlayerListener.java:647) at org.bukkit.craftbukkit.v1_8_R3.scheduler.CraftTask.run(CraftTask.java:71) at org.bukkit.craftbukkit.v1_8_R3.scheduler.CraftAsyncTask.run(CraftAsyncTask.java:53) ... 3 more Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.GeneratedMethodAccessor152.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at ru.tehkode.permissions.bukkit.regexperms.PermissiblePEX.calculateChildPerms(PermissiblePEX.java:191) ... 15 more Caused by: java.util.ConcurrentModificationException at java.util.LinkedHashMap$LinkedHashIterator.nextNode(LinkedHashMap.java:711) at java.util.LinkedHashMap$LinkedKeyIterator.next(LinkedHashMap.java:734) at org.bukkit.permissions.PermissibleBase.calculateChildPermissions(PermissibleBase.java:181) at org.bukkit.permissions.PermissibleBase.calculateChildPermissions(PermissibleBase.java:190) ... 19 more

    Users with the same issue

    Unknown visitor
    Unknown visitor1 times, last one,
    aldrinlealaldrinleal
    2 times, last one,
    tvrmsmithtvrmsmith
    1 times, last one,
    Unknown visitor
    Unknown visitor1 times, last one,
    Unknown visitor
    Unknown visitor1 times, last one,