Re: [wildfly-dev] Pooling EJB Session Beans per default
On Aug 4, 2014, at 7:44 PM, James Livingston <jlivings(a)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