CompletableFuture/parallelStream in JavaEE app server

Question

Given the new Java8 we are getting really nice features for asynchronous tasks, e.g. CompletableFuture and .paralellStream(). If you run this in Java SE as I've understood it you will utilize the ForkJoinPool, but what happens if I run the following examples in e.g. Wildfly or TomcatEE?

//Here I start a comp.Future without giving an Executor
test = CompletableFuture.supplyAsync(() -> timeConsumingMethod());
//Here I start a parallel stream 
mList.paralell().filter(...).collect(Collectors.toList())

What happens and where will I borrow my resources from if

1. The examples are ran in a @Stateful bean
2. The examples are ran in a @Stateless bean
3. The examples are ran in a CDI bean

Answer 1

You should not use ForkJoinPool in Java EE. Only the app server is supposed to provide constructs for parallelism (like the ManagedExecutorService in Java EE 7), because threads have to be managed by the container.

Curiously, there's a message in the mailing list mentioned in this answer that claims that a ForkJoinPool will gracefully degrade to single-threaded in an EE container. I've tested this with glassfish 4.1 and the usual threads are created. Running this code:

@Singleton
public class SomeSingleton {
    public void fireStream() {
        IntStream.range(0, 32)
            .parallel()
            .mapToObj(i -> String.format("Task %d on thread %s", 
                i, Thread.currentThread().getName()))
            .forEach(System.out::println);
    }
}

I get the following output:

Info:   Task 20 on thread http-listener-1(4)
Info:   Task 10 on thread ForkJoinPool.commonPool-worker-3
Info:   Task 21 on thread http-listener-1(4)
Info:   Task 11 on thread ForkJoinPool.commonPool-worker-3
Info:   Task 22 on thread http-listener-1(4)
Info:   Task 8 on thread ForkJoinPool.commonPool-worker-3
Info:   Task 23 on thread http-listener-1(4)
Info:   Task 9 on thread ForkJoinPool.commonPool-worker-3
Info:   Task 18 on thread http-listener-1(4)
Info:   Task 14 on thread ForkJoinPool.commonPool-worker-3
Info:   Task 19 on thread http-listener-1(4)
Info:   Task 15 on thread ForkJoinPool.commonPool-worker-3
Info:   Task 16 on thread http-listener-1(4)
Info:   Task 17 on thread http-listener-1(4)
Info:   Task 4 on thread http-listener-1(4)
Info:   Task 5 on thread http-listener-1(4)
Info:   Task 6 on thread http-listener-1(4)
Info:   Task 7 on thread http-listener-1(4)
Info:   Task 2 on thread http-listener-1(4)
Info:   Task 3 on thread http-listener-1(4)
Info:   Task 0 on thread http-listener-1(4)
Info:   Task 1 on thread http-listener-1(4)
Info:   Task 26 on thread http-listener-1(4)
Info:   Task 27 on thread http-listener-1(4)
Info:   Task 24 on thread http-listener-1(4)
Info:   Task 25 on thread http-listener-1(4)
Info:   Task 12 on thread http-listener-1(4)
Info:   Task 13 on thread http-listener-1(4)
Info:   Task 30 on thread http-listener-1(4)
Info:   Task 31 on thread http-listener-1(4)
Info:   Task 28 on thread ForkJoinPool.commonPool-worker-0
Info:   Task 29 on thread ForkJoinPool.commonPool-worker-0

Perhaps the degradation will become available on Java EE 8, when most individual specifications will leverage SE 8 features.

---

Edit

I've checked glassfish 4.1.1 source code, and there isn't a single use of ForkJoinPool, ForkJoinWorkerThreadFactory or ForkJoinWorkerThread. So the app server managed parallelism resources are not based in any of those constructs. Unfortunately, there's really no degradation mechanism available.