CompletableFuture.exceptionally with executor - asynchronous

Question

CompletableFuture.exceptionally() method takes a lambda, but there is no flavor of the method that takes a custom Executor, or even an "...Async" flavor of it.
Which executor does exceptionally lambda run on? Would it be the same executor which ran the original CompletableFuture which threw the exception? Or (I would be surprised if this is the case) is it the commonPool ?

Answer 1

Form JDK bug discussion CompletableFuture.exceptionally may execute on main thread :
CompletableFuture.exceptionally does not take an Executor argument
since it is not designed to execute the exceptionally task
asynchronously.
If the dependent task is not yet completed then the exceptionally task
will complete on the same thread that dependent tasks completes on.
If the dependent task is completed then the exceptionally task will
complete on the thread that executed the call to exceptionally.
This is the same behaviour that will occur for any non-asynchronous
execution, such as thenAccept.
To guarantee that the exceptionally task is executed on a thread
within the executor thread pool then it is necessary to use
whenCompleteAsync or handleAsync and passing in the executor.

Answer 2

Note that as of JDK 12, there is CompletionStage.exceptionallyAsync (and exceptionallyAsync which takes an Executor).

Answer 3

Looks like it runs in the same executor as its CompletionStage
public static void main(String[] args) throws Exception {
//ExecutorService executorService = Executors.newFixedThreadPool(3);
ExecutorService executorService = Executors.newWorkStealingPool();
while (true) {
int i = Instant.now().getNano();
CompletableFuture<?> completableFuture = CompletableFuture.supplyAsync(
()-> {
System.err.printf("async thread at %d -> %s\n", i, Thread.currentThread().getName());
try {
TimeUnit.SECONDS.sleep(2);
} catch (InterruptedException e) {
e.printStackTrace();
}
throw new RuntimeException();
}, executorService);
completableFuture.exceptionally(
(err)-> {
System.err.printf("error thread for %d -> %s\n", i, Thread.currentThread().getName());
return null;
});
TimeUnit.SECONDS.sleep(5);
}
}
For fixed size:
async thread at 418000000 -> pool-1-thread-1
error thread for 418000000 -> pool-1-thread-1
async thread at 646000000 -> pool-1-thread-2
error thread for 646000000 -> pool-1-thread-2
async thread at 646000000 -> pool-1-thread-3
error thread for 646000000 -> pool-1-thread-3
async thread at 646000000 -> pool-1-thread-1
error thread for 646000000 -> pool-1-thread-1
async thread at 647000000 -> pool-1-thread-2
error thread for 647000000 -> pool-1-thread-2
For stealing pool(4 cores):
async thread at 96000000 -> ForkJoinPool-1-worker-1
error thread for 96000000 -> ForkJoinPool-1-worker-1
async thread at 196000000 -> ForkJoinPool-1-worker-1
error thread for 196000000 -> ForkJoinPool-1-worker-1
async thread at 197000000 -> ForkJoinPool-1-worker-1
error thread for 197000000 -> ForkJoinPool-1-worker-1
async thread at 197000000 -> ForkJoinPool-1-worker-1
error thread for 197000000 -> ForkJoinPool-1-worker-1
async thread at 197000000 -> ForkJoinPool-1-worker-1
error thread for 197000000 -> ForkJoinPool-1-worker-1
async thread at 197000000 -> ForkJoinPool-1-worker-1
with no executor:
async thread at 848000000 -> ForkJoinPool.commonPool-worker-1
error thread for 848000000 -> ForkJoinPool.commonPool-worker-1
async thread at 944000000 -> ForkJoinPool.commonPool-worker-1
error thread for 944000000 -> ForkJoinPool.commonPool-worker-1
async thread at 944000000 -> ForkJoinPool.commonPool-worker-1
error thread for 944000000 -> ForkJoinPool.commonPool-worker-1
async thread at 944000000 -> ForkJoinPool.commonPool-worker-1
error thread for 944000000 -> ForkJoinPool.commonPool-worker-1
async thread at 944000000 -> ForkJoinPool.commonPool-worker-1
error thread for 944000000 -> ForkJoinPool.commonPool-worker-1

Answer 4

I did some experiments. Looks like the executor for the exceptionally handler is not chosen deterministically.
If I do not place any breakpoints, the exceptionally handler is occasionally executed in the same executor as the CompletableFuture that has the exceptionally handler. Furthermore, I could notice that it ran in the same ForkJoinTask. Once in two or three runs, it was executed on the main thread.
If I placed breakpoint at runtime prior to attaching the exceptionally handler and waited there for a moment, the exceptionally lambda was consistently executed on the main (calling) thread!
Here is the experiment code:
ForkJoinPool ex = new ForkJoinPool(2,
ForkJoinPool.defaultForkJoinWorkerThreadFactory, null, false);
// AsyncThreadLocal.requestId.set((int)(Math.random()*1000));
CompletableFuture<Integer> f1 = CompletableFuture.supplyAsync(() -> {
System.out.println(Thread.currentThread().getName());
throw new RuntimeException();
// return 3;
}, ex);
CompletableFuture<Integer> f8 = f1.exceptionally(t -> {
System.out.println(Thread.currentThread().getName());
return 5;
});
Thread.sleep(10000);
Output of program: Sometimes it is
ForkJoinPool-1-worker-1
main
Other times it is
ForkJoinPool-1-worker-1
ForkJoinPool-1-worker-1