Mon application doit être capable de créer une structure d'arborescence d'acteurs. Le moyen standard de faire cela que j'imagine, ce serait de mettre le code d'instanciation à l'intérieur des acteurs afin qu'ils puissent instancer leurs enfants. L'approche que je préférerais être capable d'instancier un acteur à un chemin donné. Tels que Créer un acteur A dans mon système, puis être capable de créer directement AKKA: // mysystem / A / B et d'autres acteurs. Cette fonctionnalité existe-t-elle? Cela simplifierait mon code grandement.
EDIT: Maintenant que je ne suis pas sur mon téléphone, laissez-moi élaborer. p>
dire que j'ai une classe p> et j'ai besoin de faire un arbre N-Way de ceux-ci. Au lieu d'avoir le code requis pour instancier leurs propres enfants dans la fonction de réception avec quelque chose comme p> Je cherche à simplifier le code de myacteur en n'incluant aucune de cela et en étant plutôt étant Capable de créer ma hiérarchie au début de mon code manuellement. Si idéalement quelque chose comme ça (en supposant une fonction statique hypothétique "Créer"): p> qui créerait l'arborescence de l'acteur: p> a
/ \
b c
3 Réponses :
Chaque acteur a un parent. Pour faire ce que vous voulez, vous auriez besoin d'une catégorie acteur pour servir de parent pour tous les autres acteurs (autres que l'acteur racinaire). Étant donné que les acteurs parents sont synonymes d'acteurs superviseurs, vous voudrez avoir des moyens de dicter la stratégie de surveillance à appliquer à ces acteurs parents.
Je suppose que vous pouvez définir un parent générique Comme seul un acteur peut créer ses enfants, les acteurs parents devraient répondre aux messages de création de leurs acteurs de leur enfant (d'autres acteurs parents ou acteurs de la feuille) à propos de choisir le moyen de sélectionner quel Mais pour répondre à votre question, il n'y a rien de construit pour le faire. Je ne pense pas que cela ait suffisamment d'utilité générale pour justifier l'ajouter à Akka elle-même. acteur pour placer dans les positions intérieures de la hiérarchie de l'acteur et écrire une méthode pour décomposer un nom de chemin de l'acteur et créer la hiérarchie dictée par un ou plusieurs de ces chemins. Vous voudrez probablement un moyen de spécifier la stratégie de supervision et, minimalement, la fonction recevoir à installer dans l'acteur de la feuille.
acteur Sous-classe pour instancier pour les acteurs de la feuille.
Créer un acteur racine, à partir de l'acteur racinaire Créez votre arbre avec acteur pour . Utilisez application.conf dans la configuration statique de la hiérarchie des noms ou créez une structure constante d'adresses. L'autre option est Parse chemins et crée des enfants dans la nervation PRESTART . Il existe différents régimes pour superviser le cycle de vie des enfants, redémarrer et acheminer des messages de manière transparente à travers un seul acteur.
Votre question commence par la postulation d'une solution, et cela n'inclut malheureusement pas une description du problème.
L'arbre de l'acteur est tout à fait compris comme la hiérarchie de supervision: le parent gère ses échecs pour enfants et le cycle de vie des lieux parent limites sur le cycle de vie de ses enfants. Un acteur devrait être ou non l'enfant d'un autre doit être déterminé en examinant ces implications.
Je dis que parce que votre question implique que vous modélisez l'arborescence de supervision selon un autre critère, probablement de l'abuser comme un registre avec Pour répondre à votre question maintenant: chaque parent doit créer ses propres enfants, ce qui signifie qu'il doit d'une manière ou d'une autre contenir le code pour le faire. Vous pouvez passer System.Actorfor comme mécanisme de recherche. Il peut y avoir de rares cas où cela fonctionne, mais a priori, je ne le recommanderais pas; Je préfère mettre une carte de hachage à l'intérieur d'un acteur de répartiteur et que cela gère la recherche. Si vous concluez à la mesure de la mesure - que cela ne fonctionne pas assez bien, vous pouvez l'accabler en utilisant un routeur .
accessoires vers le bas de la hiérarchie pour faire des parties de son configurables, mais vous ne devez pas travailler autour quelle supervision signifie ; Demandez-vous ce qui devrait arriver si l'une des feuilles échoue, puis vous demandez si vos feuilles présumées doivent être redémarrées et / ou tuées lorsqu'un acteur intermédiaire est redémarré.
Je vois que théoriquement c'est une bonne réponse, mais je ne peux pas m'empêcher de noter à quel point le code de spaghetti résulte des hiérarchies de systèmes de grandes acteurs. Une configuration centrale mentionnée dans la question pourrait fournir un mécanisme de compréhension claire de la hiérarchie globale à des fins logicielles pratiques. Voulez-vous recommander une autre méthode alternative pour clarifier des hiérarchies complexes? Ou est-ce juste comment il doit recevoir des relations d'acteur parent-enfant?
Il est difficile pour moi de répondre à cela parce que vous semblez impliquer un contexte que je n'ai pas. Les systèmes d'acteur sont structurés dans des sous-arbres fournissant certaines fonctionnalités, en ce sens qu'ils sont très modulaires. Le point d'entrée sur chacun de ces sous-modules est son acteur supérieur, ce qui est efficacement tout son sous-arbre. Je peux voir comment enfreindre ce modèle en essayant d'installer des acteurs au sein des sous-arbres de l'extérieur produirait un code spaghetti, car cela n'est tout simplement pas censé être fait. Chaque fois qu'un acteur doit créer un enfant, il peut par exemple regarder la configuration pour déterminer comment faire cela.