Fwd: Pooling EJB Session Beans per default

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

Fwd: Pooling EJB Session Beans per default

Radoslaw Rodak

Anfang der weitergeleiteten Nachricht:

Von: Radoslaw Rodak <[hidden email]>
Betreff: Aw: [wildfly-dev] Pooling EJB Session Beans per default
Datum: 6. August 2014 19:20:07 MESZ
An: Bill Burke <[hidden email]>

Am 06.08.2014 um 17:30 schrieb Bill Burke <[hidden email]>:

On 8/6/2014 10:50 AM, Andrig Miller wrote:

----- Original Message -----
From: "Radoslaw Rodak" <[hidden email]>
To: [hidden email]
Sent: Tuesday, August 5, 2014 6:51:03 PM
Subject: Re: [wildfly-dev] Pooling EJB Session Beans per default

Am 06.08.2014 um 00:36 schrieb Bill Burke <[hidden email]>:

On 8/5/2014 3:54 PM, Andrig Miller wrote:
Its a horrible theory. :)  How many EJB instances of a give type
created per request?  Generally only 1.  1 instance of one object
type!  My $5 bet is that if you went into EJB code and started
how many object allocations were made per request, you'd lose
quickly.   Better yet, run a single remote EJB request through a
tool and let it count the number of allocations for you.  It will
greater than 1.  :)

Maybe the StrictMaxPool has an effect on performance because it
a global synchronization bottleneck.  Throughput is less and you
having less concurrent per-request objects being allocated and

The number per request, while relevant is only part of the story.
The number of concurrent requests happening in the server
dictates the object allocation rate.  Given enough concurrency,
even a very small number of object allocations per request can
create an object allocation rate that can no longer be sustained.

I'm saying that the number of concurrent requests might not dictate
object allocation rate.  There are probably a number of allocations
happen after the EJB instance is obtained.  i.e. interception
contexts, etc.   If StrictMaxPool blocks until a new instance is
available, then there would be less allocations per request as
threads would be serialized.

Scenarion 1 )
Let say we have a pool of 100 Stateless EJBs and a constant Load of
50 Requests per second  proceeded by 50 EJBs from the pool in one
After 1000 seconds how many new EJB Instances will be created having
a pool? answer 0 new EJBs  worst case 100 EJB’s in pool… of course
object allocation is much higher as of course 1 EJB call leads to
many Object from one EJB  but…let see situation without pool.

50 Request/s * 1000 seconds = worst case 50’ 000 EJB Instances on
Java heap where 1 EJB might have many objects…   as long as Garbage
Collection was not triggered… which sounds to me like faster filling
JVM heap and having ofter GC probable depending on GC Strategy.

Scenarion 2)
Same as before,  Load is still 50 Requests  per second BUT EJB Method
call takes 10s.
after 10s we have 500 EJB Instances without pool, after 11s  550 - 10
= 540EJB Instances , after 12s  580 EJBs … after some time very bad
perf…full GC …and mabe OutOfMemory..

So… performance advantage could also turn in to disadvantage :-)

Whoever is investigating StrictMaxPool, or EJB pooling in general
stop.  Its pointless.

Agree, pools are outdated…. but something like WorkManager for min,
max Threads or even better always not less the X idle Threads would
be useful :-)


The scenarios above are what is outddated.  Fifty requests per second isn't any load at all!  We have 100's of thousands of clients that we have to scale to, and lots more than 50 requests per second.

What you mean to say is that you need to scale to 100's of thousands of
clients on meaningless no-op benchmarks. :)  I do know that that old
SpecJ Java EE benchmarks artifically made EJB pooling important as
process intensive calculation results were cached in these instances.
But real-world apps don't use this feature/anti-pattern.

Also however crappy it was, I did implement an EJB container at one time
in my career.  :)  I know for a fact that there are a number of
per-request internal support objects that need to be allocated.  Let's

* The argument array (for reflection)
* Each argument of the method call
* The response object
* Interceptor context object
* The interceptor context attribute map
* EJBContext
* Subject, Principal, role mappings
* Transaction context
* The message object(s) specific to the remote EJB protocol

Starts to add up huh?   I'm probably missing a bunch more.  Throw in
interaction with JPA and you end up with even more per-request objects
being allocated.  You still believe pooling one EJB instance matters?

Bill Burke
JBoss, a division of Red Hat
wildfly-dev mailing list
[hidden email]

Totally agree!
The point is, pool has not only pool but also throttling function.
If you remove pool you still need throttling and you might have better performance over time with throttling as without and run out of resources...

wildfly-dev mailing list
[hidden email]