On Thu, Jul 26, 2001 at 04:35:59PM -0700, David Rees wrote:
>
> I found the problem, below is the simplest patch to fix it, although not
> 100% correct. I'll explain why in a few minutes.
Never mind, I should have looked at openThreads first. As far as I can
tell, the ThreadPool works as advertised, except in the following case
(which wouldn't cause any stack traces). A
Say maxThreads is 100, currentThreadsBusy is 95 and minSpareThreads is 10
and currentThreadCount is 96.
Wouldn't you expect ThreadPool to open up 5 new Threads to attempt to keep
10 threads open in the checkSpareControllers function?
Anyway, my last patch shouldn't make a difference in preventing that
exception unless something weird is going on synchronization wise.
Can you try this patch to get more information on what's going on when the
exception occurs?
-Dave
--- ThreadPool.java.orig Sun Apr 22 19:16:03 2001
+++ ThreadPool.java Thu Jul 26 17:01:41 2001
@@ -231,9 +231,18 @@
}
// If we are here it means that there is a free thred. Take
it.
- c = (ControlRunnable)pool.lastElement();
- pool.removeElement(c);
- currentThreadsBusy++;
+ try {
+ c = (ControlRunnable)pool.lastElement();
+ pool.removeElement(c);
+ currentThreadsBusy++;
+ } catch (Exception e) {
+ loghelper.log("Unexcpected Exception", e);
+ loghelper.log("maxThreads: " + maxThreads);
+ loghelper.log("currentThreadCount: " +
currentThreadCount);
+ loghelper.log("currentThreadsBusy: " +
currentThreadsBusy);
+ loghelper.log("minSpareThreads: " + minSpareThreads);
+ loghelper.log("Current Pool Size: " + pool.size());
+ }
}
c.runIt(r);
}