[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