Short answer: Negative values for maximumThreads are for troubleshooting only. All production nodes should have maximumThreads>=0. This is what is causing you to have so many unused threads.
Long answer: The maximumThreads config option determines both which ThreadFactory is used and the status of thread limiting. The two thread factories work quite differently. I'll try to sum up everything: maximumThreads>0 uses QThreadFactory maximumThreads<=0 uses FastThreadFactory maximumThreads!=0 activates thread limiting maximumThreads=0 disables thread limiting FastThreadFactory: FTF saves CPU when threads are used and released by not calculating several counters about thread usage. It also makes no provisions for shrinking the number of threads. This allows for faster dispatching and recovery of threads, but because support must be maintained for these counters, it has to calculate them upon request. Thread usage information has always been generated upon request and presented through the EnvironmentInfolet. QThreadFactory: QTF updates several counters each time a thread becomes active, and again when it is released. It also checks to see whether it needs to create more threads, or can reduce the number of threads, each time a thread is used. This creates greater overhead when threads are allocated, and can cause the node to create/delete tens of thousands of threads per day, but it saves ram and native threads where applicable. It also does not have to calculate these counters upon request. Thread usage information used to be generated each time a thread was allocated/released and presented through the ThreadFactoryInfolet. Nearly four months ago I switched this over to generating usage info upon request and presenting it through the EnvironmentInfolet (same as FTF). QTF generating usage information each time a thread was used/released, with FTF generating it only upon request, is what used to make FTF so much faster than QTF. On larger nodes thread usage can exceed 100,000 per hour (see http://127.0.0.1:8888/servlet/nodestatus/diagnostics/jobsExecuted/hour). Because people very rarely look at thread stats, generating this info upon request is much more efficient. I moved QTF over to the EnvironmentInfolet and retired ThreadFactoryInfolet nearly 4 months ago making this a non-issue. Thread limiting uses the activeThreads() method. You'll recall FTF calculates this upon request, while QTF keeps a counter. This makes QTF more efficient when thread limiting is active. FTF now has an advantage over QTF only when thread limiting is disabled. With thread limiting disabled none of the various counters QTF keeps are used externally to the ThreadFactories. Even with thread limiting active, it is only a recommendation. With either ThreadFactory actual threads used can exceed this setting. With QTF, the total threads will be reduced again once the node no longer needs them. With FTF, once a thread is created it never goes away. -Pascal On January 5, 2003 11:00 pm, Ed Tomlinson wrote: > Looks like this commit: > > Modified Files: > AutoBackoffNodeRequester.java > Log Message: > don't try to cancel running AutoRequester's... > > Made Saturday cures things. I have been up 26 hours and the node > continues to behave well. Spoke too soon. Looks like it help but there are still problems. This morning Java has 408 threads with 2 active. I have max threads set to maximumThreads=-80 I think, at the very least, it should get rid of threads over the limit (would 80 do that?). Also, since I limit at 80 it should not be _ever_ using 400+ threads... Ed Tomlinson _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
