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