Супервайзер против простого spawn_link - PullRequest
Новая
       43

Супервайзер против простого spawn_link

0 голосов
/ 17 мая 2011

У меня есть иерархия процессов, которая называется "monitor_node". Каждый из этих monitor_nodes контролируется одним супервизором.

Теперь каждый из этих узлов может иметь сложную внутреннюю структуру. Это означает, что он может (или не может) иметь некоторые подпроцессы, которые необходимы для его правильной работы. Пример: процесс отправки сообщений keep-alive. До сих пор я использовал обычный spawn_link для создания этих «внутренних» процессы.

Однако я понял, что порождение их в функции инициализации monitor_node (которая контролируется) иногда приводит к сбою этой функции (и, следовательно, к отказу всего дерева супервизора). Мой вопрос: было бы хорошим решением присоединить эти внутренние процессы к дереву супервизора? Я думаю об изменении monitor_node на супервизор, который контролирует его внутренние процессы.

Мои сомнения:

  1. Мне бы пришлось контролировать довольно значительное количество очень мелких процессов. Я не уверен, что это хорошая практика.

  2. Возможно, я заранее не знаю, что данный «внутренний» процесс является простым процессом или имеет некоторую внутреннюю структуру (также порождает другие процессы). Если последнее имеет место, тогда я, вероятно, должен присоединить эти «внутренние-внутренние» процессы к дереву супервизора.

Надеюсь, я вас не слишком смутил. Ждем ответа.

EDIT:

Очень похожая (если не та же) проблема обсуждается здесь (3-ий пост). Данное решение в значительной степени совпадает с тем, которое я дал ОТЛИЧНЫЕ ОТВЕТЫ.

1 Ответ

2 голосов
/ 17 мая 2011

Супервизоры:

Здесь есть хитрость, которая включает использование двух супервизоров.Ваше дерево выглядит так: 

main_sup -> worker
main_sup -> attached_pool_sup

attached_pool_sup -> workers

main sup равно one_for_all, поэтому, если работник или руководитель пула умирает, то дерево готово и уничтожено.Супервизор пула - это simple_one_for_one, который подходит для сотен или тысяч работников.

Init:

Не выполняйте слишком много работы в обратном вызове init.Супервизор будет ждать, пока инициализация не завершится, и вы можете установить тайм-аут (который вы можете увеличить в вашем случае), если он длится дольше, чем обычно.

Хитрость заключается в том, чтобы быстро истечь (время ожидания равно 0init), а затем обработать дополнительную настройку в обратном вызове handle_info.Таким образом, вы не остановите главного наблюдателя.Остерегайтесь гонок здесь!

...