I have often thought that a possible solution would be an unbounded pool
that always keeps n instances around, but just creates new instances
instead of blocking if the pool is exhausted. In the majority of cases
new instance creation will be way more performant than blocking.
James Livingston wrote:
On Mon, 2014-08-04 at 20:22 -0400, Bill Burke wrote:
> I always liked the ThreadLocal pool. No synchronization, little to no
It also can cause massive memory leaks if invoked from threads which
aren't re-used, like timer threads, and precautions aren't taken. AS/EAP
5 suffered from that problem with the default ThreadLocalPool.
The major problem I've seen in support cases related to StrictMaxPool is
the very arbitrary default size. I believe it used to be 30, and almost
no-one knew that they might need to tune it to fit their applications'
usage patterns and workload. Having a rising wait-time metric for the
pool indicates that it may be too small, but I believe the statistics
are disabled by default for performance reasons.
InfinitePool obviously doesn't have that problem, but it would have been
nicer if it had an idle period with expiry, like the JCA pools.