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.