[JBoss JIRA] Created: (JBREM-577) Investigate failure of org.jboss.test.remoting.transport.multiplex.MultiplexInvokerTestCase, jdk 1.4, on cruisecontrol
by Ron Sigal (JIRA)
Investigate failure of org.jboss.test.remoting.transport.multiplex.MultiplexInvokerTestCase, jdk 1.4, on cruisecontrol
----------------------------------------------------------------------------------------------------------------------
Key: JBREM-577
URL: http://jira.jboss.com/jira/browse/JBREM-577
Project: JBoss Remoting
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: 2.0.0.GA (Boon)
Reporter: Ron Sigal
Assigned To: Ron Sigal
Fix For: 2.0.0.GA (Boon)
This test is failing rather consistently in testRule4ServerFirst() on cruisecontrol, even though this particular failure can't be reproduced on any other environment. In case the problem is more than environmental, i.e., a real problem in Multiplex, some additional log statements will be added to MultiplexServerInvoker and OutputMultiplexor.
What is happening is that in runPushCallbackTests(), the message "stopped callback Connector" appears, but then the test dies before the callback Connector completes its shut down. It would be nice to believe that there is a deadlock, but none is evident, unless it's due to a problem with Collections.synchronizedMap in jdk 1.4. Note that this problem never occurs in the jdk 1.5 cruisecontrol tests.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 12 months
[JBoss JIRA] Created: (JBREM-549) remove dependancy on concurrent.jar within remoting client
by Tom Elrod (JIRA)
remove dependancy on concurrent.jar within remoting client
----------------------------------------------------------
Key: JBREM-549
URL: http://jira.jboss.com/jira/browse/JBREM-549
Project: JBoss Remoting
Issue Type: Task
Security Level: Public (Everyone can see)
Components: general
Affects Versions: 2.0.0.Beta2 (Boon)
Reporter: Tom Elrod
Assigned To: Tom Elrod
Fix For: 2.0.0.CR1 (Boon)
Currently, the remoting clients will require concurrent.jar to be on the classpath because org.jboss.util.id.GUID is used to create the client session id. Problem is that org.jboss.util.id.GUID is what requires concurrent.jar. So will either need to modify the code within jboss common repository or find another class to use for generating the client session id.
java.lang.NoClassDefFoundError: EDU/oswego/cs/dl/util/concurrent/SynchronizedLong
at org.jboss.util.id.UID.<clinit>(UID.java:56)
at org.jboss.util.id.VMID.create(VMID.java:259)
at org.jboss.util.id.VMID.getInstance(VMID.java:223)
at org.jboss.util.id.GUID.<init>(GUID.java:65)
at org.jboss.remoting.Client.<init>(Client.java:133)
at org.jboss.remoting.Client.<init>(Client.java:210)
at org.jboss.remoting.Client.<init>(Client.java:191)
at org.jboss.test.remoting.transport.InvokerClientTest.init(InvokerClientTest.java:80)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 12 months
[JBoss JIRA] Created: (JBAS-3511) JMS ASF integration and JMS Session Pools need resource management improvements
by Weston Price (JIRA)
JMS ASF integration and JMS Session Pools need resource management improvements
-------------------------------------------------------------------------------
Key: JBAS-3511
URL: http://jira.jboss.com/jira/browse/JBAS-3511
Project: JBoss Application Server
Issue Type: Support Patch
Security Level: Public (Everyone can see)
Components: JCA service
Affects Versions: JBossAS-4.0.3 SP1
Reporter: Weston Price
Assigned To: Weston Price
Priority: Minor
A client has requested that the JMS applications server integration facilities for resource management and JMS session pooling be improved primarily in two areas:
1) The ability to not create all JMS sessions on container startup.
2) The ability to recycle/release JMS sessions based on a configurable timeout.
Both these features would need to be added to the existing JMSContainerInvoker as well as carried forward to the JBossJCA adapter prior to production release.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 1 month