Supervisori con backoff

Question

Ho un supervisore con due processi di lavoro: un client TCP che gestisce la connessione a un server remoto e un FSM che gestisce il protocollo di connessione.

La gestione degli errori TCP nel processo figlio complica notevolmente il codice. Quindi preferirei "lasciarlo andare in crash", ma questo ha un problema diverso: quando il server non è raggiungibile, il numero massimo di riavvii sarà rapidamente raggiunto e il supervisore si romperà con la mia intera applicazione, il che è abbastanza indesiderabile per questo caso.

Quello che mi piacerebbe è avere una strategia di riavvio con back-off; in caso contrario, sarebbe sufficiente se il supervisore fosse a conoscenza del riavvio a causa di un arresto anomalo (ad esempio, se fosse passato come parametro alla funzione init). Ho trovato this mailing list thread, ma c'è una soluzione più ufficiale/meglio testata?

Answer 1

È possibile trovare il nostro supervisor cushion come un buon punto di partenza. Io lo uso rallentare il riavvio su cose che devono essere in esecuzione, ma non riescono rapidamente all'avvio (come le porte che incontrano un problema di risorse).

Answer 2

Ho avuto questo problema molte volte lavorando con erlang e provato molte soluzioni. Penso che il meglio che ho trovato sia quello di avere un processo in più che viene avviato dal supervisore e avvia quello che potrebbe bloccarsi.

Avvia il bambino all'avvio, attende le uscite figlio e riavvia il bambino (con un ritardo) o esce a seconda dei casi. Penso che questo sia più semplice del server back-off (al quale si collega) in quanto è sufficiente mantenere lo stato di un singolo figlio.

Un'altra soluzione che ho utilizzato è quella di dover avviare i processi figlio come transitori e disporre di un processo separato che esegue il polling e il riavvio di eventuali processi in caso di arresto anomalo.

Answer 3

Quindi, per prima cosa, si desidera rilevare una chiusura anticipata del bambino utilizzando un process_flag(trap_exit, true) nel proprio init.

allora avete bisogno di decidere quanto tempo si desidera ritardare un riavvio, per esempio 10 sec., Farlo nel

handle_info({'EXIT', _Pid, Reason}, State) -> 
    erlang:send_after(10000, self(), {die, Reason}), 
    {noreply, State}; 

Infine, lasciare che il processo di morire con

handle_info({die, Reason}, State) -> 
    {stop, Reason, State};