On Thursday 22 February 2001 13:39, Scott wrote: > > On Thu, Feb 22, 2001 at 09:21:20AM -0800, Mr.Bad wrote: > > >>>>> "KR" == Kirk Reiser <kirk at braille.uwo.ca> writes: > > > > KR> hmmm, I don't know if this is normal or not but I've noticed > > KR> that after the server is started I have 11 java > > KR> processes/threads. After I have done a number of look ups on > > KR> one box the number of processes go up to 23 currently. On > > KR> another box which got a bunch of request failed messages it is > > KR> currently up to 30. On both boxes these processes don't seem > > KR> to go away at any point I have seen so far. > > > > Hrm. Actually, that's perfectly normal. > > > > HOWEVER, would it make sense to start reaping unused threads? Like, > > have a parameter, something like maxIdleThreads, so that if a thread > > is reclaim()'d and there are already maxIdleThreads around, go ahead > > and kill it. > > > > There's like a resource-performance tradeoff, of course... > > We already do that. If its *not* trimming back down, then you have > connections stuck open or the thread trimming isn't working. > I'm pretty sure the thread trimming is working. I instrumented the code to make sure that none of the EThread are being leaked.
Every EThread created in ThreadPool.run() appears to come back in ThreadPool.reclaim(). I even went a step further to make sure that every java.lang.Thread created by a pooled EThread is coming back into ThreadPool.reclaim with reclaim returning false (i.e. so that EThread.run exits). That looks good too. As a final experiment I modified ThreadPool so that it causes any new java.lang.Threads created to be dumped into their own ThreadGroup. The activeCount() of the ThreadGroup is about twice runningThreads() + threads.size(). It never seems to get bigger by much more than this ratio. i.e. it doen't grow without bound. My interpretations of this are that: a) pooled threads are calling reclaim correctly in EThread.run() but EThreads.run() isn't exiting cleanly. and /or b) non-pooled threads are being created on pooled threads (and hence end up in the same ThreadGroup). Only threads for inbound connections come out of the ThreadPool right? What ratio do we expect of pooled to non-pooled threads? If b) were the case and the ratio of pooled to non-pooled connections ~= 1:1 then thread pooling is working fine. Too optimistic.... My gut feeling is that non-pooled threads are being leaked somewhere else. With 41 pooled threads allocated the ThreadPool ThreadGroup shows 78 threads in the activeCount(), but ps aux | grep -i java | wc Shows 115 processes (my node is the only java program running) Who is using the other 37 threads? diffs for my instrumentation to ThreadPool.java are attached. (This isn't a patch, I'm posting it in case someone else wants to try my experiments.) --gj -- Web page inside Freenet: freenet:MSK at SSK@enI8YFo3gj8UVh-Au0HpKMftf6QQAgE/homepage// -------------- next part -------------- A non-text attachment was scrubbed... Name: threadpool.instrument.deltas Type: text/english Size: 1686 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20010222/3821c4f5/attachment.bin>
