]
Ron Sigal commented on JBREM-1293:
----------------------------------
In last sequence of invocations, added time to allow the single ServerThread in use to
return itself to threadpool.
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: