Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<blockquote> <p>What will happen if http thread pool receives a task which need to be executed synchronously and if there are no enough EJB bean instances in pool (maximum configured is 50), because all EJB instances are serving other http requests ? </p> </blockquote> <p>EJB pooling is not part of JEE specification, therefore, pooling behavior is vendor dependent. According to Glassfish <a href="http://docs.oracle.com/cd/E18930_01/html/821-2431/abeea.html#abeee" rel="noreferrer">documentation</a> (may be this can vary between versions) if the pool size is less than <code>steady-pool-size</code>, when a new request arrives the Container will create X new ejb instances where X is determined by the <code>pool-resize-quantity</code> value. Therefore, you shouldn't run out of pooled ejb. The <code>max-pool-size</code> is not a fixed limit.</p> <blockquote> <p>Does it make sense to increase the number of EJB instances (max) equal to http-threadpool value ?</p> </blockquote> <p>It could be right but notice that the Container will increase automaticly the pool size if more ejb are needed during a high-load period. I would change the <code>steady-pool-size</code> to a value grater than 0 instead.</p> <blockquote> <p>After doing some profiling it was noticed that the code which does lookup for the EJB instances take a long time to return. Does it mean that there was no EJB instances available and the request had to wait until an instance was release by the other running threads ?</p> </blockquote> <p>In case (may be a wrong configured pool) the server runs out of available ejb, has more sence that it creates a new instance instead of to serialize clients requests. This what the specification(ejb 3.1) says about:</p> <blockquote> <p>4.7 Stateless Session Beans ...The container creates another stateless session bean instance if one is needed to handle an increase in client work load...</p> </blockquote> <p>Create a new ejb instance shouldn't be too expensive unless your bean has to execute specific business logic at the moment of initialization (e.g. logic at @PostConstruct annotated method).</p> <p>Take in mind that under high load there are others more relevant issues than pool configuration that need to be monitored such as cpu and memory server usage.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload