[jboss-jira] [JBoss JIRA] Updated: (JBREM-843) MicroSocketClientInvoker can miscount number of active sockets

MicroSocketClientInvoker can miscount number of active sockets -------------------------------------------------------------- Key: JBREM-843 URL: http://jira.jboss.com/jira/browse/JBREM-843 Project: JBoss Remoting Issue Type: Bug Security Level: Public(Everyone can see) Affects Versions: 2.2.2.GA_CP01, 2.2.2.SP2, 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 (1) a pool of available sockets, and (2) a counter, usedPooled, of the number of sockets currently in use. Because the sequence of (1) checking for a free socket in the pool, and (2) creating a new socket if the pool is empty, is not in a synchronized block, it is possible to create more sockets than the maximum pool size. In particular, the following sequence of events can produce "extra" sockets: 1. Thread 1 sees that the pool is empty, 2. Thread 2 returns a socket to the pool, and 3. Thread 1 creates a new socket. It would be possible to synchronize events 1 and 3, but it's probably undesirable since the process of getting a socket from the pool can be time consuming if the "socket.check_connection" flag is set to true. Therefore, MicroSocketClientInvoker tolerates the possibility of creating "extra" sockets. However, it never puts more than the configured maximum number of sockets in the pool. That is, if the pool is full (i.e., size == maxPoolSize), then, when an invocation completes, the socket used for that invocation will be discarded instead of being added to the pool. The problem is that the usedPooled counter is incremented every time a socket is created and decremented every time a socket is returned to the pool, but is is *not* decremented when a socket is discarded. Suppose maxPoolSize is 100, If 101 sockets are created, 100 sockets are returned to the pool, and 1 socket is discarded, then the resulting value of usedPooled will be 1 instead of 0. It appears, then, that there is 1 socket in use, so MicroSocketClientInvoker will create no more than 99 additional sockets (excluding the race described above). So, there is a leak, not of sockets, but of "slots" for sockets. Eventually, it could become impossible to create new sockets.