Tolérance de défaut Erlang (comme je le comprends) inclut l'utilisation de processus de superviseur pour garder un œil sur les processus de travailleurs, donc si un travailleur meurt que le superviseur peut entamer une nouvelle.
Comment Erlang fait-il cette surveillance, en particulier dans un scénario distribué? Comment peut-il être sûr que le processus est vraiment mort? Est-ce que ça fait des battements de coeur? Quelque chose est intégré à l'environnement d'exécution? Et si un câble réseau est débranché - suppose-t-il que les autres processus soient morts s'il ne peut pas communiquer avec eux? c.
Je pensais à la manière de réaliser la même tolérance de faute, etc. de l'erlang dans la JVM (à dire Java ou Scala). Mais je n'étais pas sûr si cela nécessitait un soutien intégré à la JVM pour le faire ainsi que Erlang. Je n'avais pas rencontré une définition de la façon dont Erlang le ferait encore comme un point de comparaison.
4 Réponses :
Il semble que quelqu'un a mis en œuvre un Stratégie similaire à Scala . J'attendrais que j'attendrait qu'un superviseur traiterait une défaillance de réseau en tant que sous-processus défaillant et la documentation sur le processus Scala semble supporter cela.
Merci - c'était un post intéressant. J'ai laissé un message là-bas essayant de travailler si elle a pris en charge les connexions réseau. J'ai eu le sentiment (éventuellement incorrect) que c'était regarder autre chose au sein de la JVM et ne gênait pas de problèmes de frontière transversale. Mais si tout fonctionne, ce serait génial!
Je pense que vous voulez dire par le processus superviseur, le Portmapper. Vous pouvez utiliser l'erlang Portmapper / Infrastructure via le Jinterface - Ainsi, vous évitez de réinventer La roue - Si vous le souhaitez toujours, vous obtenez au moins toutes les interfaces décrites là-bas.
Merci, mais j'espérais seulement avoir le Java VM autour (NO Erlang VM). Tree les choses plus simples (politiquement).
La supervision Erlang OTP n'est généralement pas faite entre les processus de différents nœuds. Cela fonctionnerait, mais la meilleure pratique est de le faire différemment.
L'approche commune consiste à écrire toute la demande afin qu'elle fonctionne sur chaque machine, mais l'application est consciente qu'il n'est pas seul. Et une partie de l'application a un moniteur de nœuds, il est donc au courant des nœuds (ceci se fait avec un réseau de réseau simple). Ces nœuds peuvent être utilisés pour changer de règles d'équilibrage de charge ou tomber à un autre maître, etc.
Ce ping signifie qu'il y a de la latence dans la détection des nœuds. Il peut prendre plusieurs secondes pour détecter un nœud pair mort (ou un maillon mort).
Si le superviseur et le processus fonctionne localement, le crash et le signal au superviseur sont à peu près instantané. Il repose sur une caractéristique qu'un accident anormal se propage à des processus liés qui se bloque également, à moins qu'ils ne sortent.
Merci, cela a beaucoup de sens. Il semble que l'envoi de messages entre les machines est différent de l'envoi entre les processus locaux (plus de frais généraux, plus de raisons pourraient échouer, etc.). Donc, code votre application à connaître à ce sujet (il n'y a pas de balle d'argent pour rendre les appels locaux / distants les mêmes, alors n'essayez pas). Cela signifie qu'un modèle similaire dans la JVM est certainement possible. Superviser uniquement les processus / fils / fibres / fibres / acteurs / quoi que ce soit, et ce code dans votre application pinging d'autres nœuds (et quoi faire si vous ne pouvez pas en atteindre un).
Erlang est OpenSource, ce qui signifie que vous pouvez Téléchargez la source et obtenez la réponse définitive sur Comment Erlang le fait.
Comment Erlang fait-il cette surveillance, en particulier dans un scénario distribué? Comment peut-il être sûr que le processus est vraiment mort? Est-ce que ça fait des battements de coeur? Quelque chose est intégré à l'environnement d'exécution?
Je crois que c'est fait dans le temps d'exécution du faisceau. Lorsqu'un processus meurt qu'un signal est envoyé à tous les processus liés à celui-ci. Voir le chapitre 9 de programmation erlang pour un complet Discussion.
Et si un câble réseau est débranché - suppose-t-il que les autres processus soient morts s'il ne peut pas communiquer avec eux? c.
in Erlang, vous pouvez choisir de surveiller un nœud et de recevoir
{node_up, noeud} et{node_down, noeud} messages. Je suppose que ceux-ci seront également envoyés si vous ne pouvez plus parler à un nœud. Comment vous les gérez est à vous.