users@glassfish.java.net

[gf-users] Re: Behavior of EJB pool, for stateless session beans

From: <olivier.liechti_at_wasabi-tech.com>
Date: Fri, 26 Sep 2014 03:51:56 +0000 (UTC)

I was not clear enough in my question, and in the meantime I have made
further investigations and realized that the EJB pool is not guilty for
my problem.

The issue that I had was that if a client (i.e. a browser sending HTTP
requests with the same session cookie) was sending several requests in
parallel, then new instances would NOT be created in the pool. The
requests would be queued and processed in sequence.

I wrote a JMeter script that does not send the cookie and was thus able
to simulate different web users easily. I was then able to increase the
number of instances in the pool. One thing to be aware of and one
remaining question:

1) you have to take into account the thread pool used to process HTTP
requests. By default, 5 threads are allocated for handling concurrent
HTTP requests. If you generate many long-running requests in parallel,
the number of EJB instances will not go above 5.

2) I realized that it is already in the web tier (in the servlet) that
requests belonging to the same HTTP session are queued. In other words,
if I send 5 requests in parallel (with the same session cookie) and
that each takes 10 seconds to be processed, then the process will end
after 50 seconds (and only 1 EJB instance will be created).

Is that by design, is there a way to change this? I did not test it
yet, but I am worried that this could cause issues for AJAX clients (if
webworkers are used in the client, then it is possible to have an app
that tries to send several AJAX requests in parallel). Any idea?

Cheers,

Olivier