[wildfly-dev] Pooling EJB Session Beans per default

[Jason Greene]

I think a thread local solution would be superior. Like strict max,  an unbounded pool has a lot of potential for misconfiguration.
 
On Aug 4, 2014, at 8:51 PM, Stuart Douglas <stuart.w.douglas at gmail.com> wrote:

> 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.
>> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

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