On Wed, 2011-09-14 at 12:03 -0700, Scott Stark wrote:
The question of whether this is the right limit is one I have raised,
especially since the limit is being imposed via a pam_limits module
which actually limits the number of processes a user is allowed. A java
thread is mapping to a process in this model, which further blurs the
effectiveness/validity.
However, this is an issue that does commonly come up with system admins
as a way of gauging max requests and therefore some measure of the max
resource requirements.
Perhaps a global limit is really not an effective approach.
Similar to how we have a global view of ports in use, perhaps just
having a global view of the thread pools in the domain model stats would
be enough. If I can see of the server thread pools with the min/max
settings, and there is a base thread pool dsl for min/max settings in
every subsystem utilizing a thread pool, one can at least understand the
thread usage, and make some choices about how to limit it.
I think it is a good idea if all subsystems can be configured to use a
single thread pool for all their application threads. However, I think
this limit should mean user threads, not including the threads the
server and JVM already use.
If you say, for example, that there are 50 threads max, it should mean
that the user can have up to 50 threads running his servlets, not that
he can have 25 threads used by the server + JVM (that they will never
let go), and actually only up to 25 that can do something for him.
--
Remy Maucherat <rmaucher(a)redhat.com>
Red Hat Inc