¿Cómo supervisan los procesos los procesos del supervisor? ¿Se puede hacer lo mismo en la JVM?

Question

La tolerancia a fallas de Erlang (según tengo entendido) incluye el uso de procesos de supervisor para vigilar los procesos de los trabajadores, por lo que si un trabajador muere, el supervisor puede poner en marcha uno nuevo.

¿Cómo hace Erlang este monitoreo, especialmente en un escenario distribuido? ¿Cómo puede estar seguro de que el proceso realmente ha muerto? ¿Hace latidos del corazón? ¿Hay algo incorporado en el entorno de tiempo de ejecución? ¿Qué sucede si un cable de red está desconectado? ¿Asume que los otros procesos han muerto si no se puede comunicar con ellos? etc.

Estaba pensando en cómo lograr la misma tolerancia a fallos, etc. reclamada por Erlang en la JVM (en Java o Scala, por ejemplo). Pero no estaba seguro si requería soporte integrado en la JVM para hacerlo tan bien como Erlang. Sin embargo, no había encontrado una definición de cómo lo hace Erlang como punto de comparación.

Answer 1

Erlang OTP La supervisión normalmente no se realiza entre procesos en nodos diferentes. Funcionaría, pero la mejor práctica es hacerlo de manera diferente.

El enfoque común es escribir toda la aplicación para que se ejecute en cada máquina, pero la aplicación sabe que no está sola. Y una parte de la aplicación tiene un monitor de nodos, por lo que es consciente de los nodos (esto se hace con ping de red simple). Estos nodos se pueden usar para cambiar las reglas de equilibrio de carga o para pasar a otro maestro, etc.

Este ping significa que hay latencia en la detección de nodos. Puede llevar unos segundos detectar un nodo par muerto (o un enlace muerto).

Si el supervisor y el proceso se ejecutan localmente, el bloqueo y la señal al supervisor son bastante instantáneos. Se basa en una característica de que un bloqueo anormal se propaga a los procesos vinculados que también se bloquean a menos que atrapen las salidas.

Answer 2

Parece que alguien ha implementado un similar strategy in Scala. Mi expectativa sería que un supervisor trataría una falla de red como un subproceso fallido, y la documentación en el proceso de Scala parece confirmar esto.

Answer 3

Creo que te refieres a Supervisor process the portmapper. Puede utilizar el mapeador de puertos/infraestructura de Erlang a través del JInterface - por lo que evita reinventar la rueda - en caso de que aún lo desee, obtendrá al menos todas las interfaces allí descritas.

Answer 4

Erlang es de código abierto, lo que significa que puede download the source y obtener la respuesta definitiva sobre cómo Erlang lo hace.

¿Cómo hace Erlang este monitoreo, especialmente en un escenario distribuido? ¿Cómo puede estar seguro de que el proceso realmente ha muerto? ¿Hace latidos del corazón? ¿Hay algo incorporado en el entorno de tiempo de ejecución?

Creo que se hace en el tiempo de ejecución de BEAM. Cuando un proceso muere, se envía una señal a todos los procesos vinculados a él. Vea el Capítulo 9 de Programming Erlang para una discusión completa.

¿Qué pasa si un cable de red se desenchufa? ¿Asume que los otros procesos han muerto si no se puede comunicar con ellos? etc.

En Erlang, se puede optar por controlar un nodo, y recibir {node_up, Node} y {node_down, Node} mensajes.Supongo que estos también se enviarán si ya no puedes hablar con un nodo. Cómo los manejas depende de ti.