2016-03-31 44 views
8

Dato il nuovo Java8 stiamo ottenendo funzionalità davvero interessanti per attività asincrone, ad es. CompletableFuture e .paralellStream(). Se lo usi in Java SE, come ho capito, utilizzerai ForkJoinPool, ma cosa succede se eseguo i seguenti esempi, ad es. Wildfly o TomcatEE?CompletableFuture/parallelStream in server app JavaEE

//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()) 

cosa succede e dove potrò prendere in prestito le mie risorse da se

  1. Gli esempi sono corse in un fagiolo @Stateful
  2. Gli esempi sono corse in un fagiolo @Stateless
  3. Gli esempi vengono eseguiti in un bean CDI
+0

L'ultimo che ho sentito (ed è passato un po 'di tempo) è qui: http://coopsoft.com/ar/Calamity2Article.html#EE – edharned

risposta

8

Non utilizzare ForkJoinPool in Java EE. Solo il server delle applicazioni deve fornire costrutti per il parallelismo (come lo ManagedExecutorService in Java EE 7), perché threads have to be managed by the container.

Stranamente, c'è un messaggio nella mailing list menzionata in this answer che afferma che un ForkJoinPool si degraderà con grazia a thread singolo in un contenitore EE. L'ho provato con glassfish 4.1 e sono stati creati i soliti thread. L'esecuzione di questo codice:

@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); 
    } 
} 

ottengo il seguente 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 

Forse il degrado sarà disponibile su Java EE 8, quando la maggior parte le singole specifiche faranno leva SE 8 caratteristiche.


Modifica

Ho controllato GlassFish 4.1.1 del codice sorgente, e non c'è un singolo uso di ForkJoinPool, ForkJoinWorkerThreadFactory o ForkJoinWorkerThread. Pertanto, le risorse di parallelismo gestite dal server delle app non sono basate su nessuno di questi costrutti. Sfortunatamente, non c'è davvero nessun meccanismo di degrado disponibile.

+0

Sì, ho letto anche "downgrade", ma ha due anni e ogni volta che ho eseguito degli esempi, vedo il parallelismo come al solito :) La mia teoria di lavoro è che utilizzerà ManagedExecutorService per ottenere un pool di thread gestito da appserver. A quale mailing list ti riferisci? – stevietheTV

+1

[questo] (http://mail.openjdk.java.net/pipermail/lambda-dev/2013-April/009335.html). Le cose si muovono lentamente nel JCP, più lentamente se si tratta di Java EE. Non sarei sorpreso se fosse nello stesso stato di quando è uscito, specialmente perché è successo prima di SE 8, il che significa che probabilmente non fa parte delle specifiche. Credo che anche se funzionasse, diciamo, glassfish, non ci sarebbe alcuna garanzia di portabilità. Cercherò comunque di trovare qualcosa di più definito. – andrepnh

+1

La degradazione è stata menzionata quando è stato rilasciato JDK8, tuttavia, la specifica Java EE 7 è basata su JDK 7 e non tratta alcuna funzionalità specifica JDK8 in alcun modo speciale. Si spera che il degrado venga standardizzato in EE 8, ma finora non ho visto nulla al riguardo. – OndrejM