On Tuesday, August 5, 2014, Bill Burke &lt;<a href="mailto:bburke@redhat.com">bburke@redhat.com</a>&gt; wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Honestly though, I think this talk of EJB pooling is ridiculous.<br>

Component layers like CDI and JAX-RS don&#39;t have pooled architectures for<br>
their per-request objects. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><div><br></div><div>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.</div>
<div><br></div>As a result, various developers have implemented their beans with the assumption that there would be pooling. That code is now seeing (performance) issues.<div><br></div><div>I think it&#39;s reasonable to assume that in many cases pooling is unnecessary, but that occasionally it&#39;s needed. One solution to this could be an explicit @Pooled annotation for general usage with (CDI) managed beans.</div>
<div><br></div><div>Kind regards,</div><div>Arjan Tijms<br><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Also, in an average application, there are<br>
multiple orders of magnitude more non component classes that are being<br>
instantiated per request.  Just think of all the Strings created by a<br>
simple HTTP request.<br>
<br>
You want a better focus?  How about JSON/XML marshalling?  Which could<br>
make things much easier to maintain then the hand-coded parsers that<br>
Wildfly uses to parse config.  And much faster and less memory at<br>
runtime for SOAP and JAX-RS request that currently rely on java reflection.<br>
<br>
You could go research perfect hashing algorithms for URL matching with<br>
servlets and JAX-RS.<br>
<br>
You could go do some perf analysis of all of our frameworks to make<br>
memory reduction and speed recommendations or even Pull Requests.<br>
<br>
You could visit each major project and make sure our automated builds<br>
have and can run automated stress tests and are measured against<br>
previous versions.<br>
<br>
Or you could just focus on these silly benchmarks that test no-op HTTP<br>
and EJB requests.<br>
<br>
<br>
--<br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="javascript:;" onclick="_e(event, &#39;cvml&#39;, &#39;wildfly-dev@lists.jboss.org&#39;)">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</blockquote></div>