[jboss-jira] [JBoss JIRA] Updated: (JBAS-2213) Replace PooledExector usage in BasicThreadPool

Replace PooledExector usage in BasicThreadPool ---------------------------------------------- Key: JBAS-2213 URL: http://jira.jboss.com/jira/browse/JBAS-2213 Project: JBoss Application Server Issue Type: Task Security Level: Public(Everyone can see) Components: Other Reporter: Scott M Stark Fix For: JBossAS-4.2.1.CR1 We need to replace the use of the PooledExecutor due to its inefficient idle thread handling. From dev list messages. Elias Ross wrote: What I've noticed is a large number of mostly idle threads, some of the for the sorts of things that don't require timely processing, e.g. transaction and JMS message timeouts, etc. From what I hear from Adrian, the minimum pool size has been kept very large to deal with a design flaw in the concurrent.PooledExecutor that favors queueing over creating new threads to handle the work. Adrian Brock wrote: > > > I don't see why you need to change it anyway?. > > Probably not, but allocating 100 minimum idle threads is not a really > appropriate default. I should have brought this up in the development > list. The JavaDoc was also wrong on Min versus Max so perhaps 100 was > chosen as a mistake? > There are lots of examples where "bad" defaults have been chosen, sometimes for a reason. e.g. in this case, if you don't set the minimum equal to the maximum, it never uses more than minimum unless there is a very large backlog forcing the queue to become full. Concurrent's PooledExector should really be called QueuedExecutorWithMaybeSomePooling :-) There is certainly zero control over idle thread management and it is inefficient at using idle threads in a stupid attempt to reduce contention. There is even a race condition in there, which is why we have a subclass to work around it. If I had more time, I would rewrite BasicThreadPool to NOT use PooledExecutor.