11

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
kolossus
  • 20,559
  • 3
  • 52
  • 104
stevietheTV
  • 502
  • 6
  • 14

1 Answers1

10

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.

Community
  • 1
  • 1
andrepnh
  • 933
  • 8
  • 21
  • Yes I've read that "downgrade" as well but it's two years old and whenever I've ran examples I do see the parallelism as usual :) My working theory is that it will used the ManagedExecutorService to get an appserver managed thread pool. What mailing list are you referring to? – stevietheTV Apr 01 '16 at 07:52
  • 1
    [This one](http://mail.openjdk.java.net/pipermail/lambda-dev/2013-April/009335.html). Things move slowly in the JCP, slower if it's Java EE related. I'd not be surprised if it was in the same state as when it came out, specially because it happened before SE 8, which means it's probably not part of the spec. I believe that even if it worked on, say, glassfish, there wouldn't be any guarantee of portability. I'll try to find something more definite, though. – andrepnh Apr 01 '16 at 12:56
  • 2
    The degradation was mentioned when JDK8 was released, however, Java EE 7 specification is based on JDK 7 and does not treat any JDK8 specific functionality in any special way. Hopefully degradation will get standardized in EE 8, but so far I've seen nothing about it. – OndroMih Apr 01 '16 at 20:12
  • 1
    Yes, I've checked the source code and there's really no usage of FJP. I've edited my answer and I'll also post another one in the SO question that says that there's degradation. – andrepnh Apr 02 '16 at 16:12