ServerThread pool should be treated like a stack ------------------------------------------------ Key: JBREM-1293 URL: https://issues.jboss.org/browse/JBREM-1293 Project: JBoss Remoting Issue Type: Enhancement Security Level: Public (Everyone can see) Affects Versions: 2.2.4, 2.5.4.SP2 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.4.SP1, 2.5.4.SP3 Currently, org.jboss.remoting.transport.socket.SocketServerInvoker.threadPool, which holds instances of org.jboss.remoting.transport.socket.ServerThread which are not currently servicing a socket, is treated as a queue. In particular, when a ServerThread is taken from threadPool, the least recently used one is taken. As a result, more recently used ServerThreads sit in threadPool and may not be harvested by the IdleTimerTask. The following example by Justin Bertram illustrates: In the first minute of life, a remote application (the only application the server is serving) creates 10 simultaneous connections to the server. The server creates 10 threads to service these 10 connections. However, throughout the rest of the life of the application it only uses 1 connection at a time, but it does so frequently (i.e. less than the idle timeout for the server-side threads). Let's say, for example, that the idle timeout is 3 minutes and the application connects and then disconnects every 10 seconds. With the current design that would keep those 10 threads alive indefinitely because none of them would ever be idle for more than 3 minutes. However, with the suggested change [i.e., treating threadPool like a stack] the client would always be served by the same thread which would allow the other 9 threads to timeout. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira