>> I was wondering about thread pools, actually. I see there are by
>> default 2 created: http-thread-pool with a limit on the number of
>> threads in the queue and a small max pool size, and thread-pool-1
>> with no limit on the queue threads and a large max pool size. The 3
>> default network listeners all use http-thread-pool. Under what
>> circumstances might a user specify the other one?
> One I can think of off hand is if you had an app that you knew would
> keep connections open for long time for something like feeding very
> large files/streams back to the client. In this case you might want a
> separate thread pool to handle that kind of load. But I'd profile
> first to make sure. The grizzly subsystem uses NIO to handle that
> processing so is fairly efficient at handling a large number of
> connections.
But the defaults are also different. Typically, the small thread pool is
the default threadpool used by HTTP requests. We have discussions about
this all the time, but the default HTTP threadpool (at least right now)
is sized for a developer machine (1-2 cpus/cores) that is running web
apps that don't block very often and is hence sized with a default
maximum of 5.
The large thread pool is the default threadpool for RMI/IIOP requests.
It is much bigger by default: those requests are longer running,
typically access a blocking back-end resources, and are more frequently
used by larger configurations. Also, in earlier versions of the
appserver, IIOP didn't use grizzly or NIO and hence needed a bigger
threadpool.
Both need to be tuned according to application needs and hardware.
-Scott