[JBoss JIRA] Created: (JBREM-775) MicroSocketClientInvoker.initPool() should omit pool from log message
by Ron Sigal (JIRA)
MicroSocketClientInvoker.initPool() should omit pool from log message
---------------------------------------------------------------------
Key: JBREM-775
URL: http://jira.jboss.com/jira/browse/JBREM-775
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.4.0.Beta1 (Pinto)
Reporter: Ron Sigal
Assigned To: Ron Sigal
Fix For: 2.4.0.Beta1 (Pinto)
Clebert Suconic reports a ConcurrentModificationException:
Producer:3 01:00:42,861 INFO [SeveralClientsStressTest$Producer] Sending Exception
java.util.ConcurrentModificationException
at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:617)
at java.util.LinkedList$ListItr.next(LinkedList.java:552)
at java.util.AbstractCollection.toString(AbstractCollection.java:453)
at java.lang.String.valueOf(String.java:2577)
at java.lang.StringBuffer.append(StringBuffer.java:220)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.initPool(MicroSocketClientInvoker.java:715)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.handleConnect(MicroSocketClientInvoker.java:450)
at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.handleConnect(BisocketClientInvoker.java:269)
at org.jboss.remoting.MicroRemoteClientInvoker.connect(MicroRemoteClientInvoker.java:242)
at org.jboss.remoting.ConnectionValidator.start(ConnectionValidator.java:301)
at org.jboss.remoting.ConnectionValidator.addConnectionListener(ConnectionValidator.java:228)
at org.jboss.remoting.Client.addConnectionListener(Client.java:367)
at org.jboss.remoting.Client.addConnectionListener(Client.java:339)
at org.jboss.jms.client.remoting.JMSRemotingConnection.addConnectionListener(JMSRemotingConnection.java:379)
at org.jboss.jms.client.container.StateCreationAspect.handleCreateConnectionDelegate(StateCreationAspect.java:103)
at org.jboss.aop.advice.org.jboss.jms.client.container.StateCreationAspect0.invoke(StateCreationAspect0.java)
at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.invokeNext(ClientConnectionFactoryDelegate$createConnectionDelegate_N3019492359065420858.java)
at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(ClientConnectionFactoryDelegate.java)
at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:205)
at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:87)
at org.jboss.jms.client.JBossConnectionFactory.createConnection(JBossConnectionFactory.java:82)
at org.jboss.test.messaging.jms.stress.SeveralClientsStressTest$Producer.run(SeveralClientsStressTest.java:324)
thrown in the line
log.debug(this + " using pool (" + pool + ") already defined for " + address);
in org.jboss.remoting.transport.socket.MicroSocketClientInvoker.initPool(). pool is a java.util.LinkedList, and LinkedList.toString() iterates through the list elements. These elements can be shared by multiple client invokers, and apparently another invoker modified the list while the log statement was running.
--
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
18 years, 3 months
[JBoss JIRA] Created: (JBREM-774) BisocketClientInvoker.replaceControlSocket() should close previous control socket
by Ron Sigal (JIRA)
BisocketClientInvoker.replaceControlSocket() should close previous control socket
---------------------------------------------------------------------------------
Key: JBREM-774
URL: http://jira.jboss.com/jira/browse/JBREM-774
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.4.0.Beta1 (Pinto)
Reporter: Ron Sigal
Assigned To: Ron Sigal
Fix For: 2.4.0.Beta1 (Pinto)
If cpu overload or network congestion causes a control connection PING to get delayed, the client side org.jboss.remoting.transport.bisocket.Bisocket.BisocketServerInvoker.ControlMonitorTimerTask will tell the server side BisocketServerInvoker.SecondaryServerSocketThread to replace the control socket.
If org.jboss.remoting.transport.bisocket.Bisocket.BisocketClientInvoker.replaceControlSocket() does not close the old control socket, and if the client is still alive, the client side BisocketServerInvoker.ControlConnectionThread will be blocked trying to read from an old control connection, which is no longer in use on the server side.
--
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
18 years, 3 months
[JBoss JIRA] Created: (JBREM-771) MicroSocketClientInvoker can experience socket leaks
by Ron Sigal (JIRA)
MicroSocketClientInvoker can experience socket leaks
----------------------------------------------------
Key: JBREM-771
URL: http://jira.jboss.com/jira/browse/JBREM-771
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.4.0.Beta1 (Pinto)
Reporter: Ron Sigal
Assigned To: Ron Sigal
Fix For: 2.4.0.Beta1 (Pinto)
org.jboss.remoting.transport.socket.MicroSocketClientInvoker maintains a static map which maps org.jboss.remoting.transport.socket.ServerAddress's to connection pools. When MicroSocketClientInvoker.handleDisconnect() is called, it clears all connection pools and removes the keys from the connectionPools map. Consequently, when another MicroSocketClientInvoker disconnects, it doesn't see the key to its own connection pool. However, it still has a connection pool, accessible through an instance variable. So each MicroSocketClientInvoker should be sure to clear its own connection pool.
.
Note that the maintenance of connection pools in a static map goes back to Remoting 1.x, when there could exist multiple client invokers with the same InvokerLocator. Now that InvokerRegistry uses reference counts, there can be only one client invoker per InvokerLocator, so the static connection pool map is probably obsolete. This conjecture should be verified.
--
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
18 years, 3 months
[JBoss JIRA] Created: (JBREM-766) Guard against "spurious wakeup" from Thread.sleep()
by Ron Sigal (JIRA)
Guard against "spurious wakeup" from Thread.sleep()
---------------------------------------------------
Key: JBREM-766
URL: http://jira.jboss.com/jira/browse/JBREM-766
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.4.0.Beta1 (Pinto)
Reporter: Ron Sigal
Assigned To: Ron Sigal
Fix For: 2.4.0.Beta1 (Pinto)
The jdk 1.5 javadoc for java.lang.Object (but not the jdk 1.4 javadoc) notes:
A thread can also wake up without being notified, interrupted, or timing out, a so-called spurious wakeup. While this will rarely occur in practice, applications must guard against it by testing for the condition that should have caused the thread to be awakened, and continuing to wait if the condition is not satisfied. In other words, waits should always occur in loops, like this one:
synchronized (obj) {
while (<condition does not hold>)
obj.wait(timeout);
... // Perform action appropriate to condition
}
(For more information on this topic, see Section 3.2.3 in Doug Lea's "Concurrent Programming in Java (Second Edition)" (Addison-Wesley, 2000), or Item 50 in Joshua Bloch's "Effective Java Programming Language Guide" (Addison-Wesley, 2001).
We should make sure all calls to Thread.wait() are handled appropriately.
--
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
18 years, 3 months