[wildfly-dev] Pooling EJB Session Beans per default

[Andrig Miller]

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 becomes.

Andy

----- Original Message -----
> From: "David M. Lloyd" <david.lloyd at redhat.com>
> To: wildfly-dev at lists.jboss.org
> 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
> 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
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>