CompletableFuture/parallelStream dans le serveur d'application JavaEE

Question

Etant donné le nouveau Java8, nous obtenons de très bonnes fonctionnalités pour les tâches asynchrones, par ex. CompletableFuture et .paralellStream(). Si vous l'exécutez dans Java SE comme je l'ai compris, vous utiliserez le ForkJoinPool, mais que se passe-t-il si j'exécute les exemples suivants, par exemple. Wildfly ou 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()) 

Que se passe et où vais-je emprunter mes ressources si

1. Les exemples sont couru dans un haricot @Stateful
2. Les exemples sont couru dans un haricot @Stateless
3. Les exemples sont exécutés dans un bean CDI

Answer 1

Vous ne devez pas utiliser ForkJoinPool dans Java EE. Seul le serveur d'application est supposé fournir des constructions pour le parallélisme (comme le ManagedExecutorService dans Java EE 7), car threads have to be managed by the container. Curieusement, il y a un message dans la liste de diffusion mentionnée dans this answer qui prétend qu'un ForkJoinPool se dégradera en single-thread dans un conteneur EE. J'ai testé ceci avec glassfish 4.1 et les threads habituels sont créés. L'exécution de ce 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); 
    } 
} 

Je reçois la sortie suivante:

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 

Peut-être que la dégradation sera disponible sur Java EE 8, lorsque les spécifications les plus individuelles exploiteront SE 8 fonctions.

---

Modifier

J'ai vérifié GlassFish 4.1.1 code source, et il n'y a pas une seule utilisation de ForkJoinPool, ForkJoinWorkerThreadFactory ou ForkJoinWorkerThread. Ainsi, les ressources de parallélisme gérées par le serveur d'applications ne sont basées sur aucune de ces constructions. Malheureusement, il n'y a vraiment aucun mécanisme de dégradation disponible.