users@glassfish.java.net

Re: Glassfish via AJP connector very slow

From: Rainer Frey <rainer.frey_at_inxmail.de>
Date: Wed, 21 Mar 2012 14:36:58 +0100

On 21.03.2012, at 14:17, Oleksiy Stashok wrote:
>>> GlassFish 3.1.2 will be using Grizzly for ajp implementation.
> In Glassfish 3.1.2 we started to use Grizzly based AJP provider to make features like Comet and Servlet 3.x Async work behind Apache server (didn't work w/ the former AJP provider implementation).
>
>> Esp. does this mean the threadpool size should be reduced to the size of the regular HTTP threadpools?
> There is no need to reduce anything. You can assign custom thread-pool to an AJP network-listener using standard asadmin commands or web admingui.
> Starting from GF 3.1.2 there is no need to provide external jk-config file in order to configure thread-pool.

As far as I understood, the old non-grizzly AJP implementation uses a thread-per-connection model (similar to e.g. default Tomcat connector). That means one needs a threadpool eith a size that equals the number of parallel connections one needs to support, which also means one has to configure a separate threadpool for a jk-enabled listener.

The default threadpool that the (Grizzly) HTTP listeners in a default installation use, is much smaller (IIRC 5 threads). AFAICS this is because Grizzly uses select-based socket IO, where one thread can handle many connections.

Does the switch of AJP to Grizzly in 3.1.2 mean, that one can use a threadpool that is similarly configured to the one used by the non-jk HTTP listeners, or that jk and non-jk listeners can even share a threadpool? Or did I misunderstand s.th.?

Thanks
Rainer