[wildfly-dev] Pooling EJB Session Beans per default

Stuart Douglas stuart.w.douglas at gmail.com
Mon Aug 4 21:51:15 EDT 2014


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.

Stuart

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


More information about the wildfly-dev mailing list