[
http://jira.jboss.com/jira/browse/JBREM-771?page=comments#action_12368501 ]
Ron Sigal commented on JBREM-771:
---------------------------------
The static connectionPools map still makes sense. The key, ServerAddress, defines
equals() based on four fields: address, port, enableTcpNoDelay, and timeout. Any two
client invokers with the same four values will share a connection pool.
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