April 2010 - jboss-jira - Jboss List Archives

[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, 6 months

5
21
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1744) More documented warnings on the usage of JMS selectors

by Noel Rocher (JIRA)

More documented warnings on the usage of JMS selectors ------------------------------------------------------ Key: JBMESSAGING-1744 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1744 Project: JBoss Messaging Issue Type: Task Components: Documentation and Training Environment: EAP 4.3 CP06 / 1.4.0.SP3-CP08.patch01 Reporter: Noel Rocher I'm on-site with a customer who is soon going to production. They have designed their application using JMS Selectors on distributed queues. We all know this is a broken design but my point is that I think this should be explicitely written in the doc. Moreover, GSS is talking about an "unsupported configuration" see case # 348290 . -- 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, 6 months

4
20
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1739) Update to JGroup 2.8

by Howard Gao (JIRA)

Update to JGroup 2.8 -------------------- Key: JBMESSAGING-1739 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1739 Project: JBoss Messaging Issue Type: Feature Request Components: AS Integration Affects Versions: 1.4.4.GA Reporter: Howard Gao Assignee: Howard Gao Fix For: 1.4.6.GA Also this thread http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257080#4257080 -- 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, 6 months

3
13
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1735) Paging should be taken care in Transactions

by Howard Gao (JIRA)

Paging should be taken care in Transactions ------------------------------------------- Key: JBMESSAGING-1735 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1735 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.4.4.GA, 1.4.0.SP3.CP08 Reporter: Howard Gao Assignee: Howard Gao Fix For: 1.4.0.SP3.CP09, 1.4.5.GA JBM queues has paging feature to save memory, but in transaction case, messages are stored in the transaction callbacks before it committed to the queue for delivery. So if too many messages are included in one transaction, it may use up memory even paging is turned on. -- 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, 6 months

3
18
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1731) Expose the JBoss Messaging Cluster partition in JMX

by Brad Maxwell (JIRA)

Expose the JBoss Messaging Cluster partition in JMX --------------------------------------------------- Key: JBMESSAGING-1731 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1731 Project: JBoss Messaging Issue Type: Feature Request Components: Messaging Core Affects Versions: 1.4.3.GA, 1.4.0.SP3.CP08 Reporter: Brad Maxwell Background: I have a TAM customer wanting access to the members of the JBoss Messaging Cluster so that they can configure the Recovery plugin without having to hard code hosts in the configuration file. With the JBoss Messaging Cluster Partition in JMX they would be able to get an accurate list of the members in the Messaging cluster. -- 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, 6 months

5
22
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1758) Derby support

by Jesper Pedersen (JIRA)

Derby support ------------- Key: JBMESSAGING-1758 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1758 Project: JBoss Messaging Issue Type: Feature Request Components: Configuration and Management Affects Versions: 1.4.3.GA Reporter: Jesper Pedersen Assignee: Howard Gao In order for the application server to support Derby as the default database we need the necessary persistence-service.xml files. Please update Branch_5_x and trunk when released. -- 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, 6 months

4
13
0 / 0

[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, 6 months

4
18
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1750) Allow arbitrary SQL statements for JDBCPersistenceManagerService

by Justin Bertram (JIRA)

Allow arbitrary SQL statements for JDBCPersistenceManagerService ---------------------------------------------------------------- Key: JBMESSAGING-1750 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1750 Project: JBoss Messaging Issue Type: Feature Request Components: Configuration and Management Affects Versions: 1.4.0.SP3.CP08 Reporter: Justin Bertram Assignee: Howard Gao Allow arbitrary SQL statements in the SQLProperties field of org.jboss.messaging.core.jmx.JDBCPersistenceManagerService which will be executed just like all the others (e.g. if CreateTablesOnStartup = "true"). I imagine the statements will need to be named according to some pattern (e.g. "CREATE_*"). This functionality will allow greater flexibility for our RDBMS support (e.g. a user could configure support for Oracle TimesTen). -- 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, 6 months

4
18
0 / 0

[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, 6 months

4
24
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1763) Bisocket connection won't be closed if pulling out the ethernet cable between client and server. The failure detection code won't close the failure connection, as a result, the subsequent requests will hang after connection account exceeds the threshold

by mingjun jiang (JIRA)

Bisocket connection won't be closed if pulling out the ethernet cable between client and server. The failure detection code won't close the failure connection, as a result, the subsequent requests will hang after connection account exceeds the threshold ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBMESSAGING-1763 URL: https://jira.jboss.org/jira/browse/JBMESSAGING-1763 Project: JBoss Messaging Issue Type: Bug Components: JMS Remoting Affects Versions: 1.4.5.GA Environment: OS: Windows Server 2003. JBoss App Server 4.2.3.GA, JBoss Messaging 1.4.5 GA, JBoss Remoting 2.2.3 SP1 Reporter: mingjun jiang We are using JBoss App Server 4.2.3.GA, JBoss Messaging 1.4.5 GA and JBoss Remoting 2.2.3 SP1. In our application, there are a lot of Message listeners running on the client side, these message listeners will receive messages from queue/topic deployed in JBoss Messaging Configuration: We created our own JMS Connection factory which uses the default remoting connector. As you know, the default remoting connector is configured to use the bisocket transport. We didn't change the default value of the remoting connector During we run our application, we open the JBoss web console to monitor the value of currentClientPoolSize under "Jboss.remoting" JMX MBean. How to reproduce this issue: 1. Run 5 message listeners in the client side to receive messages from JBoss Messaging, then we observe the value of currentClientPoolSize is 10 2. After processing several messages, we manually pull out the ethernet cable. The value of currentClientPoolSize is still 10. 3. We run another 5 message listeners in client side, then the value of currentClientPoolSize will become 20 4. After we do the same operations above several times, the value of currentClientPoolSize will increase continuously. Once the value of currentClientPoolSize is equal to the MaxPoolSize, then the subsequent incoming client requests will hang, and we will encounter the following exception in server side 2009-10-20 18:08:09,655 ERROR [org.jboss.remoting.transport.socket.ServerThread] Worker thread initialization failure java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:168) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read(BufferedInputStream.java:235) at java.io.FilterInputStream.read(FilterInputStream.java:66) at org.jboss.remoting.transport.socket.ServerThread.readVersion(ServerThread.java:859) at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:545) at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:406) at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:173) Conclusion: JBoss Messaging won't close the failure connections if they are caused by manually pulling out ethernet cable. As a result, the value of currentClientPoolSize will increase continuously and finally the new client requests will hang Note: If we killed the process of message listener in client side, then the value of currentClientPoolSize will decrease to 0 immediately, it seems that the server could detect the failure connection and perform the corresponding resource releasing. -- 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, 6 months

4
43
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2010