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

[Dimitris Andreadis (JIRA)]

     [ http://jira.jboss.com/jira/browse/JBAS-2213?page=all ]

Dimitris Andreadis updated JBAS-2213:
-------------------------------------

    Fix Version/s: JBossAS-4.0.6.CR1
                       (was: JBossAS-4.0.5.CR1)

No free cycles for this now.

> 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.0.6.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.

-- 
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