>>> 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).
>> 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 for the explanation! I understand now.
Rainer