[wildfly-dev] Pooling EJB Session Beans per default

David M. Lloyd david.lloyd at redhat.com
Tue Aug 5 09:40:35 EDT 2014


I have always contended that the most appropriate place for throttling 
server usage is at the front end.  If the number of incoming web and EJB 
requests can be limited, then everything else probably should just be 
unbounded (else you enter a configuration nightmare because *everything* 
has knobs).  This way you can limit configuration to total incoming 
requests, and specific resources that have to be limited (like DB 
connections), and be assured of reasonable performance instead of having 
to read the encyclopedia to figure out all the tuning parameters you 
have to futz with.

On 08/05/2014 08:07 AM, Andrig Miller wrote:
> Your idea is something that I like as well.  You have a min, but no max, and no blocking for an instance if there isn't one immediately available.  The downside is its unbounded (I have also had customers tell me they needed a strict max option because they were delivering an application to their customers, and wanted to have strict control of the resources used), but it would be a nice compliment to what we have now.
>
> On the old InfinitePool, using ThreadLocal, it was actually faster than the old StrictMaxPool, and it actually wasn't unbounded, because it would be bound by the thread pool size of the calling thread to the EJB instance.  While it was faster than the old StrictMaxPool, it was probably because of the serialized nature of the old implementation.
>
> There is definitely room for additional implementations here.
>
> Andy
>
> ----- Original Message -----
>> From: "Stuart Douglas" <stuart.w.douglas at gmail.com>
>> To: "James Livingston" <jlivings at redhat.com>
>> Cc: wildfly-dev at lists.jboss.org
>> Sent: Monday, August 4, 2014 7:51:15 PM
>> Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default
>>
>> 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
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

-- 
- DML


More information about the wildfly-dev mailing list