[Oops. I dropped core-libs-dev CC on reply. Resending...)

On 01/27/2015 10:43 AM, Lev Priima wrote:
Using TPE w/ custom BlockingQueue and if RuntimeException happens in blocking
BlockingQueue.take() method then this code

new ThreadPoolExecutor(1, 1, 0, TimeUnit.NANOSECONDS,
     new ArrayBlockingQueue<Runnable>(1) {
         public Runnable take() throws InterruptedException {
             throw new RuntimeException();
         }
     }
).prestartAllCoreThreads();

has an unbounded thread creation loop.

As a result there are many created unbounded threads in RUNNING state after
printing stack trace to stderr by default UncaughtExceptionHandler. And these
thread will be cleaned only when whole TPE finished.

Is this "Not an Issue"?


It is apparently an issue for someone! But I don't see any spec
violation: If a supplied BlockingQueue not only does not block but also
continuously throws exceptions, then threads using it will be
continuously replaced, given the other TPE construction arguments
here and the call to prestartAllCoreThreads.

Any attempt to change TPE to somehow guess that it should stop trying
to replace threads seems unlikely to solve any actual problem, since
the TPE remains unusable either way.

-Doug

Reply via email to