<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 12pt; color: #000000'>Considering our benchmarking work through our performance team we have actually discovered that we actually need pooling of Stateless Session beans, because of memory allocation rates being too high.<br><br>Allocating objects is fast in the latest JVM's, that's for sure, but you can easily create a situation where the memory allocation rate becomes too high, and you start getting excessive GC overhead.<br><br>With that in mind, we have recently created (John O'Hara did the work from the middle-ware performance team), a new implementation of the StrictMaxPool. That implementation uses a ConcurrentLinkedQueue as the underlying data structure, as the original used a simple LinkedList with synchronization, so essentially all accesses to the pool were serialized. So, this didn't scale. The new implementation is upstream in Wildfly 9. There is no configuration change necessary, as it replaces the old implementation and is compatible.<br><br>Like everything, there are tradeoffs, and the mantra that has spread recently that pooling is bad, is simply not the case. In some cases, allocating an object everytime is the best approach, in others cases pooling will be the best approach.<br><br>Fortunately, you can do either in Wildfly (and EAP). Like always, you have to test your specific application, in the properly configured environment to know for sure.<br><br>Andy<br><br><hr id="zwchr"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Wolf-Dieter Fink" <wfink@redhat.com><br><b>To: </b>"Ralph Soika" <ralph.soika@imixs.com>, wildfly-dev@lists.jboss.org<br><b>Sent: </b>Monday, July 21, 2014 11:39:12 AM<br><b>Subject: </b>Re: [wildfly-dev] Pooling EJB Session Beans per default<br><br>
<div class="moz-cite-prefix">Hi Ralph,<br>
<br>
as I said in your community thread
(<a class="moz-txt-link-freetext" href="https://community.jboss.org/thread/242999" target="_blank">https://community.jboss.org/thread/242999</a>) it is not only the
problem to add a pool for it.<br>
At the moment there is only the strict-max-pool which limit the
total number of beans pooled - and also the total number of beans
which can be used in parallel.<br>
So that means adding the pool is a performance issue, which can
make the situation better or worse depend on the application.<br>
So you need to adjust it depend on your needs.<br>
<br>
If there is another implementation of a pool, i.e. which allow to
have x pooled instances and more if needed, the pool might be back
as default.<br>
For the moment it is makes no difference or is faster (in most
cases) without pooling.<br>
<br>
- Wolf<br>
<br>
On 21/07/14 18:16, Ralph Soika wrote:<br>
</div>
<blockquote cite="mid:53CD3CCE.2030902@imixs.com">
Hi,<br>
<br>
I want to discuss the topic of Session Bean Pooling in WildFly. I
know that there was a discussion in the past to disable pooling of
EJB Session Beans per default in WildFly.<br>
I understand when you argue that pooling a session bean is not
faster than creating the bean from scratch each time a method is
called. From the perspective of a application server developer
this is a clear and easy decision. But from the view of an
application developer this breaks one of the main concepts of
session beans - the pooling.<br>
As a application developer I suppose my bean is pooled and I can
use one of the life-cycle annotations to control my bean. This is
a basic concept for all kind of beans. First I thought it could be
a compromise to pool only these beans which have a life-cycle
annotation. But this isn't a solution.<br>
Knowing that my bean will be pooled allows me - as a component
developer - to use this as a caching mechanism. For example time
intensive routines can also cache results in a local variable to
be used next time a method is called. This isn't a bad practice
and can increase performance of my component depending on the pool
settings.<br>
<br>
So my suggestion is to pool also stateless session ejbs in the
future. I guess form the specification there is no duty to pool
beans. So there is nothing wrong when not pooling beans. And again
I don't want to criticize. But at the end not pooling will
decrease the performance of WildFly. Not the container itself but
the applications running in WildFly.<br>
It takes me a long time to figure out why my application was a
little bit slower in WildFly than in GlassFish until I recognized
the missing pooling. I can activate pooling and everything is
cool. But I guess some other application developers will only see
that there application is slower in WildFly than on other
application servers.<br>
And this will effect their decision. That is the argument to
activate the pool per default.<br>
<br>
best regards<br>
Ralph<br>
</blockquote>
<br>
<br>_______________________________________________<br>wildfly-dev mailing list<br>wildfly-dev@lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/wildfly-dev</blockquote><br></div></body></html>