I tend to agree with you. It does get very complicated very quickly with all the resource
related configuration. The more complex the workload, the more complex the configuration
----- Original Message -----
From: "David M. Lloyd" <david.lloyd(a)redhat.com>
Sent: Tuesday, August 5, 2014 7:40:35 AM
Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default
I have always contended that the most appropriate place for
server usage is at the front end. If the number of incoming web and
requests can be limited, then everything else probably should just be
unbounded (else you enter a configuration nightmare because
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
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.
> ----- 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
>> that always keeps n instances around, but just creates new
>> instead of blocking if the pool is exhausted. In the majority of
>> new instance creation will be way more performant than blocking.
>> James Livingston wrote:
>>> On Mon, 2014-08-04 at 20:22 -0400, Bill Burke wrote:
>>>> I always liked the ThreadLocal pool. No synchronization,
>>>> to no
>>> It also can cause massive memory leaks if invoked from threads
>>> aren't re-used, like timer threads, and precautions aren't taken.
>>> 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
>>> no-one knew that they might need to tune it to fit their
>>> usage patterns and workload. Having a rising wait-time metric for
>>> pool indicates that it may be too small, but I believe the
>>> are disabled by default for performance reasons.
>>> InfinitePool obviously doesn't have that problem, but it would
>>> nicer if it had an idle period with expiry, like the JCA pools.
>> wildfly-dev mailing list
> wildfly-dev mailing list
wildfly-dev mailing list