2014-05-08 5 views
4

Je crois comprendre que l'onReceive ne peut être exécuté que par un thread à un moment donné.Akka Java - Créer des acteurs enfants récursifs à la volée?

Disons que j'ai un acteur non typé défini comme ceci:

import akka.actor.ActorRef; 
import akka.actor.Props; 
import akka.actor.UntypedActor; 


public class ExampleActor extends UntypedActor { 

    private ActorRef databaseActor; 


    @Override 
    public void preStart() { 
     ActorRef databaseActor = getContext().system().actorOf(Props.create(DatabaseActor.class)); 
    } 


    @Override 
    public void onReceive(Object message) throws Exception { 

     if (message.equals("start")) { 
      // spawn a child actor of myself! 
      ActorRef child = getContext().actorOf(Props.create(ExampleActor.class)); 
      databaseActor.tell("fetch", child); 
     } 

     if (message.equals("dbresponse")) { 
      // just log the repsonse here! 
     } 

     if (message.equals("something else")) { 
      // possibly mutate state 
     } 


    } 
} 

Je veux essentiellement utiliser Akka sans utiliser à terme. En même temps, je veux que mes acteurs ne bloquent PAS autant que possible. Est-il acceptable de générer des acteurs enfants récursifs dans mon onReceive, uniquement pour traiter des messages spécifiques d'autres acteurs? Essentiellement dans mon "if (message.equals (" dbresponse "))", je veux simplement enregistrer une réponse de DB et ne pas muter l'état dans mon ExampleActor.

Cette approche fonctionnera-t-elle? Quelles sont les conséquences de la création d'acteurs à la volée comme ça?

Répondre

4

Vous le faites parfaitement, c'est ainsi que le modèle d'acteur prévoit la gestion des interactions entre les acteurs. L'utilisation du modèle ask fait quelque chose qui est effectivement le même (mais une forme optimisée d'acteur à réponse unique est générée à la place), donc si vous ne voulez pas utiliser Futures c'est le moyen de vous désengager.

+0

Merci pour la réponse! Nous utilisons Futures dans notre projet Akka en utilisant la méthode Patterns.ask (acteur, message, timeout), mais nous voyons que notre logique se complique avec les futurs imbriqués (en utilisant Patterns.ask() dans un onComplete d'un futur) parce que nous voulons continuer seulement quand une extraction DB est terminée, etc. Quand est-il nécessaire d'utiliser Patterns.ask() pour les opérations liées à IO (lecture/écriture DB) sur le simple acteur.tell() avec les gestionnaires de réponse correspondants ? – HiChews123

+1

Le motif 'ask()' n'est jamais nécessaire, il peut dans certains cas être simplement plus pratique à utiliser. Dès que l'acteur que vous écrivez devient plus complexe, 'ask()' ne s'échelonne pas aussi bien au niveau du code. –