Il pattern dell'attore con Akka e processi a lunga esecuzione

Question

Ultimamente ho studiato il fantastico framework Akka per cercare di farmi un'idea e decidere se sarebbe stato giusto per il mio progetto. Attualmente questa applicazione è una semplice vecchia applicazione java che esegue calcoli molto complessi effettuando chiamate a vari eseguibili esterni in C++ (a volte i calcoli possono richiedere ore per essere eseguiti). Nel codice sembrerebbe qualcosa di simile

public static class Worker extends UntypedActor { 
    // Run Very Long Process 
    public void onReceive(Object message) { 
    if (message instanceof Work) { 
     Work work = (Work) message; 
     double result = veryLongProcess(work.getStart(),work.getNrOfElements()); 
     getSender().tell(new Result(result), getSelf()); 
    } else { 
     unhandled(message); 
    } 
    } 
} 

La mia domanda è: Akka può gestire attori che prendono a volte ore per tornare dalla loro esecuzione?

Answer 1

Rispondere direttamente alla domanda; c'è un good article su questo argomento:

Anche in questo caso, se si è di lungo corso calcoli, averli eseguiti in un ExecutionContext separata per le attività della CPU-bound è una buona idea.

L'articolo ha il seguente esempio:

import java.util.concurrent.Executors 
import concurrent.ExecutionContext 

//I added 'private' for the rest of the example 
private val executorService = Executors.newFixedThreadPool(4) 
private val executionContext = ExecutionContext.fromExecutorService(executorService) 

Rispondendo indirettamente,

Futures Prima

Sono completamente d'accordo che attori Akka sono uno strumento molto utile per particolari tipi di lavoro. Per quanto riguarda la memorizzazione nella cache, lo Actors & Agents è il miglior gioco in città.

Tuttavia, in questo caso, suggerirei di utilizzare un Future anziché un attore. È possibile rendere moltoLongProcess una funzione private. La privacy permetterebbe il controllo completo sul numero di thread chiamando il metodo in una sola volta:

def longProcessFut(start : Int, noOfElements : Int) : Future[Result] = Future { 
    veryLongProcess(start, noOfElements) 
}(executionContext)//controls the executing pool of veryLongProcess 

Semplice, conciso, e asincrona.

Nessun omicidio di lettere, nessun metodo di ricezione sovraccarico che accetta nulla sotto il sole, né Puntelli, nemmeno un ActorRef era necessario per il futuro. Bloat, pancia di birra, dico!

Inoltre, l'utente sta per creare un futuro non importa che a causa della ?:

//Actor user code, too verbose 

val longProcessRef = actorSystem actorOf Props[Worker] 

val fut : Future[Result] = (longProcessRef ? Work(0,42)).mapTo[Result] 

rispetto all'utilizzo direttamente

//happy user code 

val fut : Future[Result] = longProcessFut(0, 42) 

stessa straordinaria Future Futures, ma la metà delle calorie!

È possibile controllare il dispatcher del futuro nello stesso modo (s) come suggerito nei commenti, che sono abbastanza buoni. È anche possibile utilizzare actorSystem.dispatcher come dispatcher Future per controllare il comportamento del dispatcher.

Answer 2

Se il lungo in esecuzione logica di business/algoritmo è incrementale, produce risultati intermedi e/o può essere eseguito per molto tempo molto quindi si consiglia di riutilizzare eccellenti frammenti progettuali da qui: Incremental processing in an akka actor