Supervisor Bambino vs Plain Spagna_Link

Question

Ho una gerarchia di processi chiamati "monitor_node". Ognuno di questi monitor_nodes è supervisionato da un supervisore.

Ora, ognuno di questi nodi può avere una complessa struttura interna. Significato, può (o potrebbe non) avere alcune sottoprocessi che sono necessarie per il funzionamento correttamente. Esempio: processo invio di messaggi Tenere-Alive. Finora ho usato Plain Spagna_Link per creare questi "interni" Processi.

Tuttavia, mi sono reso conto che le dizionalità in funzione init del monitor_node (che viene supervisionato) a volte fa sì che questa funzione fallisca (e quindi l'intero albero del supervisore non riesce). La mia domanda è: sarebbe una buona soluzione per allegare questi processi interni all'albero del supervisore? Sto pensando di cambiare monitor_node a un supervisore che supervisiona i suoi processi interni.

I miei dubbi sono:

.

1. Dovrei supervisionare il numero piuttosto significativo di processi molto piccoli. Non sono sicuro se questa è una buona pratica.

2. Potrei non sapere in anticipo che è stato dato il processo "interno" è un processo semplice o ha una certa struttura interna (genera altri processi). Se quest'ultimo è il caso, probabilmente dovrei allegare questi processi "interni-interner" all'albero del supervisore.

   Spero di non averti confuso troppo. In attesa di una risposta.

   Modifica:

   Un problema molto simile (se non uguale) è discuta qui (3 ° post). La soluzione riportata è praticamente la stessa di quella che do risposte di schifo ha dato.

Answer 1

Supervisors:

There is a trick here, which includes the use of two supervisors. Your tree goes like:

main_sup -> worker
main_sup -> attached_pool_sup

attached_pool_sup -> workers

main sup is one_for_all, so if the worker or the pool supervisor dies, then the tree is done for and killed off. The pool supervisor is a simple_one_for_one which are suitable for having hundreds or thousands of workers.

Init:

Don't do too much work in your init callback. The supervisor will wait until the init completes and you can set a timeout (which you can increase in your case) if it takes longer than normal.

A trick is to quickly timeout (return with a timeout of 0 from init) and then handle additional setup in the handle_info timeout callback. That way you won't be stopping up the main supervisor. Beware of races here!