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);
     }

Reply via email to