8:07 a.m.
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