Develop Reference

Why executor is not running out of available threads when its threads ends up with exceptions?

In the following scenario my task throws an exception. I was excepting that after one request my pool would not be able to process any further requests but it is not happening. How does thread pool behaves in this scenario? How communication of exception happens from Pool thread to main application thread?
public class CallableClass implements Callable<String> {
#Override
public String call() throws Exception {
throw new RuntimeException();
}
}
class Test {
ExecutorService executor = Executors.newFixedThreadPool(1);
public void execute(){
try {
System.out.println(executor);
Future<String> future = executor.submit(new Task());
System.out.println(executor);
future.get();
}catch(Exception e) {
System.out.println(executor);
e.printStackTrace();
}
}
}

You could check it out by printing the name of the currently executing thread:
#Override
public String call() throws Exception {
System.out.println(Thread.currentThread().getName());
...
}
How does thread pool behaves in this scenario?
The worker notifies the executor service about the exception occurred when it was working. But there is no reason to remove that worker from the ThreadPoolExecutor#workers set. It will continue its work if there is a need.
You shouldn't see any failures of the executor service. It's going to replace an invalid worker (or a thread) with a valid one if something wrong happens:
If any thread terminates due to a failure during execution prior to shutdown, a new one will take its place if needed to execute subsequent tasks.
ExecutorService.newFixedThreadPool(int) [JDK 9]
How communication of exception happens from Pool thread to main application thread?
Any exception thrown from a Callable#call is being wrapped by an ExecutionException and is popped up to the caller:
#throws ExecutionException if the computation threw an exception
Future.get() [JDK 9]
An example of cheching whether ExecutionException#getCause is a RuntimeException instance:
} catch (ExecutionException e) {
Throwable cause = e.getCause();
if (cause != null && cause instanceof RuntimeException) {
System.out.println("A RuntimeException was thrown.");
}
}

Why doesn't Java Thread receive interrupt flag?

I am trying to understand interrupting threads within an ExecutorService and I can't figure out why the following MyNeverEndingRunnable class doesn't get the interrupt signal. I have a class that implements Runnable and simply prints and waits in a loop until it is interrupted:
class MyNeverEndingRunnable
implements Runnable
{
int count = 0;
#Override
public void run()
{
while (true)
{
System.out.printf("[%d]:%d\n", Thread.currentThread().getId(), ++count);
try { Thread.sleep(5000L); } catch (Exception ignored) {}
if (Thread.interrupted())
{
break;
}
}
}
}
I spawn a few of these threads then call shutdownNow() on my ExecutorService which should call interrupt on each of the running threads but the below code continues to run forever:
int threadCount = 5;
ExecutorService executorService = Executors.newFixedThreadPool(threadCount);
Future[] threads = new Future[threadCount];
for (int k = 0; k < threadCount; ++k)
{
threads[k] = executorService.submit(new MyNeverEndingRunnable());
}
Thread.sleep(20000L);
executorService.shutdownNow();
while (!executorService.isShutdown()) Thread.sleep(1000L);
Does anyone know what I am doing wrong here?

From the Javadoc:
InterruptedException - if any thread has interrupted the current thread. The interrupted status of the current thread is cleared when this exception is thrown. [My emphasis]
NB There's nothing that actually guarantees that threads are interrupted by shutdownNow(). It just describes that as a 'typical implementation'.
Your code is a little strange. Try this:
try
{
Thread.sleep(5000L);
}
catch (InterruptedException exc)
{
break;
}
and remove the Thread.interrupted() test.

Read the Javadoc on Thread.sleep():
Throws:
...
InterruptedException - if any thread has interrupted the current thread. The interrupted status of the current thread is cleared when this exception is thrown.
As soon as the exception is thrown, it's no longer interrupted. In your case, you can immediately break out of the loop and let the thread die, as #EJP suggested. But if your code doesn't have ownership of the thread (e.g. a separate method), you'll want to make sure the interruption is propagated to the caller, either by propagating the exception, or by re-interrupting:
try {
while (true) {
System.out.printf("[%d]:%d\n", Thread.currentThread().getId(), ++count);
Thread.sleep(5000L);
}
} catch (InterruptedException notIgnored)
Thread.currentThread().interrupt();
}
Or similarly:
while (!Thread.currentThread().isInterrupted()) {
System.out.printf("[%d]:%d\n", Thread.currentThread().getId(), ++count);
try {
Thread.sleep(5000L);
} catch (InterruptedException notIgnored)
Thread.currentThread().interrupt();
}
}

java - How can I get a future's stack trace on TimeoutException

In java, I would like to determine the current stack of the thread which populates the result of the future when a TimeoutException occurs. It seems that the top entry in the stack trace provided by a TimeoutException only indicates where future.get() was invoked, not the state of the background thread. For example:
ExecutorService executor = Executors.newSingleThreadExecutor();
Future<String> future = executor.submit(new Callable<String>() {
#Override
public String call() throws Exception {
Thread.sleep(10000);
return "";
}
});
try {
future.get(1, TimeUnit.MILLISECONDS);
} catch (TimeoutException e) {
e.printStackTrace();
} catch (InterruptedException | ExecutionException e) {
e.printStackTrace();
}
In this example I've found that the top entry is the future.get(1, TimeUnit.MILLISECONDS) entry, not the Thread.sleep(10000). I would like the stack trace to indicate Thread.sleep(10000) since this is what is currently being executed. Is there an elegant way of doing this?
I've found that if there is an actual execution problem, then the ExecutionException.printStackTrace() will indicate where the problem occurred in the background thread.

If you had a reference, t, to the Thread was running the task, you could call t.getStackTrace(); but the standard library ExecutorService implementations aren't going to tell you what thread is running the task.
You could have the task itself record what thread is running it:
class MyTask implements Callable<String> {
private volatile Thread executorThread;
#Override
String call() {
executorThread = Thread.currentThread(); // not getCurrentThread()
Thread.sleep(10000);
return "";
}
Thread getExecutorThread() {
return executorThread;
}
}
That way, when your main thread times out, it could call myTask.getExecutorThread().getStackTrace();
...
MyTask myTask = new MyTask();
Future<String> future = executor.submit(myTask);
...
} catch (InterruptedException | ExecutionException e) {
StackTraceElement[] stack = myTask.getExecutorThread().getStackTrace();
for (StackTraceElement element : stack) {
...print it...
}
}

You cant get the trace of that exception.
Because In that exception doesnt have cause and suppressed exception.

InterruptedException thrown from futures

Suppose I have a method as follows:
public void poll(Callable<Boolean> callable) {
ScheduledExecutorService service = Executors.newSingleThreadedScheduledExecutor();
Future<Boolean> future = service.schedule(callable, 0L, TimeUnit.MILLISECONDS);
try {
while (!future.get()) {
future = service.schedule(callable, 5L, TimeUnit.MINUTES);
}
} catch (ExecutionException e) {
// ...
} catch (InterruptedException e) {
// ...
} finally {
service.shutdown();
}
}
How does an InterruptedException ever get thrown (and caught in poll())? Anything thrown by the callable (including InterruptedException, right?) would be an ExecutionException, we never cancel any futures, and the service's shutdownNow() is never called.
Aside: being what it is, is it possible to make this polling method more bulletproof against things like InterruptedException?

The InterruptedException would be thrown by get while waiting (blocking) for the callable to finish.
I'm not sure what you mean by bulletproof, you have to handle the possibility of the exception being thrown.

InterruptedException can be thrown by the thread which called get and is waiting for completion, not by the callable

setting interrupt bit does not make Future.get() throw TimeoutException

Why doesn't setting the interrupt bit in a Callable cause the Future that represents the Callable to throw a TimeoutException when Future.get() is called?
public class ExecutorServiceTest extends MockitoTestCase {
private static CountDownLatch latch1 = new CountDownLatch(1);
class TaskChecksForInterruptedExcAndDoesSetInterruptedBit implements Callable<String> {
#Override
public String call() {
latch1.countDown();
while (!Thread.currentThread().isInterrupted()) {
}
Thread.currentThread().interrupt();
return "blah";
}
}
void testInterrupt() throws Exception {
ExecutorService pool = Executors.newFixedThreadPool(numThreads);
Future<String> future = pool.submit(new TaskChecksForInterruptedExcAndDoesSetInterruptedBit());
latch1.await(); // Don't interrupt the Callable until it actually starts processing
pool.shutdownNow();
try {
future.get(100, TimeUnit.MILLISECONDS);
} catch (final TimeoutException e) {
// Why doesn't this get called!
return;
}
fail();
}
}

the shutdownNow() call attempts to interrupt all running tasks. In this case the interruption is detected in your busy loop, so the code continues and the Callable returns "blah" (and not an exception)
TimeoutException, according to the spec, is thrown only if the thread waits for the complete timeout period, but no result becomes available. Interruption doesn't fit into this scenario.
Your usage of CountDownLatch is incorrect. You decrement it, but I see no call to latch1.await()