Re: [wildfly-dev] Pooling EJB Session Beans per default

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&gt; > To: "James Livingston" <jlivings(a)redhat.com&gt; > 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