[wildfly-dev] Pooling EJB Session Beans per default

[Jason Greene]

On Aug 4, 2014, at 7:44 PM, James Livingston <jlivings at redhat.com> 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.

Right this is the reason we didn’t preserve it, as it leads to both instance leaks and class loader leaks. However a thread local based pool with a controlled life-cycle attached to deployment is something we have always wanted to do, it’s just been lower priority..

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

Yes that was a bad default, although the big problem is that any value we pick is a bad default. Ideally you want an auto-tuned construct which is tied into our tuning with worker pools (e.g. like the thread local approach above). Absent that its better to just take the small hit of allocating a few temporary objects per request, and let the user setup the pool config that best fits their app.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat