river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <p...@acm.org>
Subject Re: TaskManager thread limit
Date Mon, 02 Aug 2010 02:00:18 GMT
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.

Incidentally, do you know why the default load level is 3, not 1?

Patricia

Mime
View raw message