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(a)gmail.com>
> To: "James Livingston" <jlivings(a)redhat.com>
> Cc: wildfly-dev(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev