[wildfly-dev] Pooling EJB Session Beans per default

[Jaikiran Pai]

I think it's important to remember that the application developers use 
the @PostConstruct and @PreDestroy on stateless EJBs for initialization 
and destroying certain application specific resources. In a non-pooled 
case this is going to affect the performance and as has been noted, it's 
ultimately something that each application needs to review. So this 
isn't exactly the same as per-request objects, as far as I see it and 
isn't just a case of Java object instantiation.

-Jaikiran
On Tuesday 05 August 2014 07:02 PM, Bill Burke wrote:
>
> On 8/4/2014 8:44 PM, 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.
>>
> Which is also something that could be mitigated by a common thread
> facility.  Something AS/EAP 5 didn't have.
>
> Honestly though, I think this talk of EJB pooling is ridiculous.
> Component layers like CDI and JAX-RS don't have pooled architectures for
> their per-request objects.  Also, in an average application, there are
> multiple orders of magnitude more non component classes that are being
> instantiated per request.  Just think of all the Strings created by a
> simple HTTP request.
>
> You want a better focus?  How about JSON/XML marshalling?  Which could
> make things much easier to maintain then the hand-coded parsers that
> Wildfly uses to parse config.  And much faster and less memory at
> runtime for SOAP and JAX-RS request that currently rely on java reflection.
>
> You could go research perfect hashing algorithms for URL matching with
> servlets and JAX-RS.
>
> You could go do some perf analysis of all of our frameworks to make
> memory reduction and speed recommendations or even Pull Requests.
>
> You could visit each major project and make sure our automated builds
> have and can run automated stress tests and are measured against
> previous versions.
>
> Or you could just focus on these silly benchmarks that test no-op HTTP
> and EJB requests.
>
>