[wildfly-dev] Pooling EJB Session Beans per default

[David M. Lloyd]

Yeah I think we don't necessarily want the takeaway here to be that 
pooling is, in general, bad.  It's just that our implementations needed 
(and still need) some more thought.  I believe there are still a few 
stones yet unturned in this area.

On 08/04/2014 05:59 PM, Andrig Miller wrote:
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> Andy
>
> ------------------------------------------------------------------------
>
>     *From: *"Wolf-Dieter Fink" <wfink at redhat.com>
>     *To: *"Ralph Soika" <ralph.soika at imixs.com>, wildfly-dev at lists.jboss.org
>     *Sent: *Monday, July 21, 2014 11:39:12 AM
>     *Subject: *Re: [wildfly-dev] Pooling EJB Session Beans per default
>
>     Hi Ralph,
>
>     as I said in your community thread
>     (https://community.jboss.org/thread/242999) it is not only the
>     problem to add a pool for it.
>     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.
>     So that means adding the pool is a performance issue, which can make
>     the situation better or worse depend on the application.
>     So you need to adjust it depend on your needs.
>
>     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.
>     For the moment it is makes no difference or is faster (in most
>     cases) without pooling.
>
>     - Wolf
>
>     On 21/07/14 18:16, Ralph Soika wrote:
>
>         Hi,
>
>         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.
>         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.
>         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.
>         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.
>
>         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.
>         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.
>         And this will effect their decision. That is the argument to
>         activate the pool per default.
>
>         best regards
>         Ralph
>
>
>
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

-- 
- DML