In che modo i processi di supervisione controllano i processi? Lo stesso può essere fatto sulla JVM?

Question

La tolleranza ai guasti di Erlang (a quanto ho capito) include l'uso dei processi di supervisione per tenere d'occhio i processi di lavoro, quindi se un lavoratore muore, il supervisore può avviarne uno nuovo.

In che modo Erlang esegue questo monitoraggio, soprattutto in uno scenario distribuito? Come può essere sicuro che il processo sia veramente morto? Fa battiti del cuore? C'è qualcosa di costruito nell'ambiente di runtime? Cosa succede se un cavo di rete è scollegato? Si presume che gli altri processi siano morti se non è in grado di comunicare con loro? ecc.

Stavo pensando a come ottenere la stessa tolleranza ai guasti ecc. rivendicata da Erlang nella JVM (in Java o Scala). Ma non ero sicuro di aver bisogno del supporto integrato nella JVM per farlo, così come Erlang. Non avevo ancora trovato una definizione di come Erlang lo fa ancora come un punto di confronto.

Answer 1

L'Erlang OTP Supervisione in genere non viene eseguita tra processi su nodi diversi. Funzionerebbe, ma la migliore pratica è di farlo in modo diverso.

L'approccio comune è scrivere l'intera applicazione in modo che venga eseguita su ciascuna macchina, ma l'applicazione è consapevole del fatto che non è sola. E una parte dell'applicazione ha un monitor di nodo, quindi è a conoscenza dei nodi-down (questo viene fatto con un semplice ping di rete). Questi nodi giù possono essere utilizzati per modificare le regole di bilanciamento del carico o ricadere su un altro master, ecc.

Questo ping indica che è presente una latenza nel rilevamento dei down del nodo. Possono essere necessari alcuni secondi per rilevare un nodo peer morto (o un collegamento morto ad esso).

Se il supervisore e il processo vengono eseguiti localmente, il crash e il segnale al supervisore sono praticamente istantanei. Si basa su una funzionalità che un crash anormale si propaga a processi collegati che si bloccano anche se non intercettano le uscite.

Answer 2

Sembra che qualcuno abbia implementato uno similar strategy in Scala. La mia aspettativa sarebbe che un supervisore trattasse un errore di rete come un sottoprocesso fallito, e la documentazione sul processo di Scala sembra confermarlo.

Answer 3

Penso che intendiate per processo di supervisione il portmapper. È possibile utilizzare il portmapper/infrastruttura Erlang tramite lo JInterface - in questo modo si evita di reinventare la rotella - nel caso in cui lo si voglia comunque si ottengono almeno tutte le interfacce descritte in quel punto.

Answer 4

Erlang è opensource, il che significa che è possibile download the source e ottenere la risposta definitiva su come Erlang lo fa.

In che modo Erlang esegue questo monitoraggio, in particolare in uno scenario distribuito? Come può essere sicuro che il processo sia veramente morto? Fa battiti del cuore? C'è qualcosa di costruito nell'ambiente di runtime?

Credo che sia stato eseguito nel runtime di BEAM. Quando un processo muore, un segnale viene inviato a tutti i processi ad esso collegati. Vedi il capitolo 9 di Programming Erlang per una discussione completa.

Cosa succede se un cavo di rete è scollegato? Si presume che gli altri processi siano morti se non può comunicare con loro? ecc

in Erlang, è possibile scegliere di monitorare un nodo, e ricevere {node_up, Node} e {node_down, Node} messaggi.Presumo che verranno inviati anche se non puoi più parlare con un nodo. Come li gestisci dipende da te.