Patricia Shanahan wrote:
Gregg Wonderly wrote:
Peter Firmstone wrote:
Patricia Shanahan wrote:
In addition to a limit related to the number of runnable tasks, a
TaskManager has a hard limit on the number of threads it will create.
The parameterless constructor has limit 10, and most other uses have
compile time limits in the range of 10 to 15 threads.
com.sun.jini.reggie.RegisrarImpl has a compile time limit of 50
threads.
com.sun.jini.mahalo.TxnManagerImpl creates two pools, settlerpool
and taskpool. The settlerpool has limit 150 threads. The taskpool
has limit 50 threads.
Even 150 threads could be low in a large server, especially if the
threads are used to wait for anything, so that each thread does not
need a hardware thread for a significant fraction of its life.
As noted in the NIO vs. IO discussion that Peter pointed out, the
key to getting good performance simply is to take advantage of the
fact that an idle thread is a cheap, simple way to remember the
state of some activity.
There is one approach that would minimize the number of changes but
increase flexibility. We could redefine the maximum thread count as
being the maximum number of threads per X, where X is a measure of
system size with a minimum of 1, but increasing on large systems.
X could be based on the number of processors, the maximum heap
memory, or some combination.
I'm in favour of this suggestion.
Auto sizing is good, but we should also consider putting in logging
that announces when the limit is reached and waiting will occur. This
will help people diagnose the potential system pauses, if not deadlock
that will be outwardly visible.
Agreed. I would be interested both in the distribution of times that
tasks spend waiting for other tasks and in the distribution of times
that they spend as ready tasks, waiting for a thread.
On top of that, I'd be strongly in favor the introduction of JMX as an
external observation and management capability for these types of values.
I don't know much about JMX, but I strongly agree with external
observation and management.
Also, just FYI, the Flavio project, http://flavio.dev.java.net/, was about
creating a mechanism to provide the ability to "lookup" a JMX accessible entity.
I've used this, but there are things about it that I am not fond of. In
particular, it creates a rather large URL for jmx access because of encoding the
lookup information into the URL as a base-64 (I think) string representation of
the MarshalledObject.
This would be something to look at though, because it does provide a bridge of
sorts between JMX client software and Jini services.
Incidentally, do you know why the default load level is 3, not 1?
I am not sure which load level you are referring to.
Gregg
Patricia
