On Tuesday, August 5, 2014, Bill Burke <bburke@redhat.com> wrote:
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. 

True, but the problem with EJB is that it has always been implied that stateless beans are pooled. And indeed, many servers have done so.

As a result, various developers have implemented their beans with the assumption that there would be pooling. That code is now seeing (performance) issues.

I think it's reasonable to assume that in many cases pooling is unnecessary, but that occasionally it's needed. One solution to this could be an explicit @Pooled annotation for general usage with (CDI) managed beans.

Kind regards,
Arjan Tijms
 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.

Bill Burke
JBoss, a division of Red Hat
wildfly-dev mailing list