[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
16 years, 8 months
- 1
- 5
[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
16 years, 8 months
- 1
- 5