users@glassfish.java.net

Re: Glassfish via AJP connector very slow

From: Oleksiy Stashok <oleksiy.stashok_at_oracle.com>
Date: Wed, 21 Mar 2012 14:43:56 +0100

On 03/21/2012 02:36 PM, Rainer Frey wrote:
> 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.
Yes, for GF < 3.1.2 to configure thread-pool one had to use external
config file.

> 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.
Correct.

> 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,
Yes

> or that jk and non-jk listeners can even share a threadpool?
Not really, even if network-listeners (ajp and non-ajp) share the same
thread-pool configuration element (refer the same thread-pool by name) -
they still create their own instances of the thread-pool based on the
provided thread-pool configuration.
It's something we may want to change in the future GF releases, so
network-listeners will share not just thread-pool configuration, but
actual thread-pool instances.

Thanks.

WBR,
Alexey.