[JBoss JIRA] Created: (JBMESSAGING-1707) ConcurrentModificationException in ClientClusteredConnectionFactoryDelegate
by Pavel Slavicek (JIRA)
ConcurrentModificationException in ClientClusteredConnectionFactoryDelegate
---------------------------------------------------------------------------
Key: JBMESSAGING-1707
URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1707
Project: JBoss Messaging
Issue Type: Quality Risk
Components: JMS Client Manager
Affects Versions: 1.4.3.GA
Reporter: Pavel Slavicek
Assignee: Tim Fox
I have found ConcurrentModificationException in ClientClusteredConnectionFactoryDelegate.
Exception in thread "Thread-11" java.util.ConcurrentModificationException
at java.util.WeakHashMap$HashIterator.nextEntry(WeakHashMap.java:784)
at java.util.WeakHashMap$KeyIterator.next(WeakHashMap.java:817)
at org.jboss.jms.client.delegate.ClientClusteredConnectionFactoryDelegate$FinalizerShutdownHook.run(ClientClusteredConnectionFactoryDelegate.java:414)
Client:
client with multiple threads, every thread creates-sends-receives-closes.
Problem description:
Problem is in the ClientClusteredConnectionFactoryDelegate.java in the inner class FinalizerShutdownHook.
Shutdown hook implementation should to be written as thread safe (see javadoc for addShutdownHook() method).
Method run() in the FinalizerShutdownHook class iterates over all elements in the registered delegates
but this iteration should be synchronized on the delegates object.
Please see http://java.sun.com/javase/6/docs/api/java/util/Collections.html#synchron...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] Created: (JBMESSAGING-1754) Implement the JBossMQ behavior on JBM, when stopDelivery() is invoked via JMX console
by Tyronne Wickramarathne (JIRA)
Implement the JBossMQ behavior on JBM, when stopDelivery() is invoked via JMX console
-------------------------------------------------------------------------------------
Key: JBMESSAGING-1754
URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1754
Project: JBoss Messaging
Issue Type: Feature Request
Components: Messaging Core
Affects Versions: 1.4.0.SP3.CP08
Environment: JBoss-EAP-4.3_CP6, JBM-1.4.0-SP3_CP8P1
Reporter: Tyronne Wickramarathne
When stopDelivery() is invoked via JMX console for any given MDB, the in process messages are rolled back to their corresponding destination without completing the process. This is however *not* a bug, but the expected behavior in JBM, for this is how it has defined the behavior of stopDelivery().
However on JBossMQ, the in process messages are completed at first, before stopDelivery() is processed. Which means, the call made via stopDelivery() will be kept on hold, until all in process messages are successfully completed. The customers migrating from JBossMQ are seeing this as a compatibility issue, when porting their applications to work on JBM. Hence, would it be possible to accommodate the behavior seen in JBossMQ on JBM please ?
I have tested this on both JBoss-EAP-4.3_CP6 as well as on JBoss-EAP-4.2_CP7. Both have the same code base for EJB3,JCA but not the JMS provider. Therefore, I'm raising this feature request under JBM.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] Created: (JBMESSAGING-1747) ClassNotFoundException while consuming a message in a JMS Queue
by Stephan Lagraulet (JIRA)
ClassNotFoundException while consuming a message in a JMS Queue
---------------------------------------------------------------
Key: JBMESSAGING-1747
URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1747
Project: JBoss Messaging
Issue Type: Bug
Components: JMS Destination Manager
Affects Versions: 1.4.1.GA
Environment: Jboss version : 5.0.1 GA
Reporter: Stephan Lagraulet
We have several JMS queues setup on our jboss server.
We are using spring to handle the messages.
When several clients simultaneously post some messages in different queues, the consumer doesn't find the class for the task, ending with this stack trace:
2009-07-28 17:10:21,089 WARN [SimpleMessageListenerContainer] [] - Execution of JMS message listener failed
java.lang.RuntimeException: fr.billetel.interfaces.ws.allotement.business.etatventes.request.CodificationsTaskRequest
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:279)
at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1102)
at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:772)
at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:415)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
We debugged the class org.jboss.messaging.util.OrderedExecutorFactory, and it appears that the class doesn't have the right classloader as it reuses a thread previously setup with an other classloader (the application is packaged in different ears while the queues are defined in deploy), ending in this exception.
For the moment, we patched the code so that the classloader is reloaded for every call, but it does not seem like a good solution on a long term.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months