Как супервайзер, который достиг_max_restart_intensity, может удалить только ребенка-нарушителя? - PullRequest
2 голосов
/ 30 марта 2011

У меня есть one_for_one супервизор, который обрабатывает аналогичные и полностью независимые дочерние элементы.

При возникновении проблемы с одним дочерним элементом, многократное аварийное завершение работы и запуск:

=SUPERVISOR REPORT==== 30-Mar-2011::13:10:42 ===
     Supervisor: {local,gateway_sup}
     Context:    shutdown
     Reason:     reached_max_restart_intensity
     Offender:   [{pid,<0.76.0>}, ...

, выключая себяа также уничтожение всех невинных детей, которые просто продолжали бы нормально работать, в противном случае.

Как я могу построить дерево наблюдения из стандартных контролеров Erlang, которое останавливает только для перезапуска одного ребенка-нарушителя и оставляет других в покое?

Я думал о том, чтобы у меня был дополнительный начальник с одним-единственным ребенком, но мне это кажется тяжелым.

Есть ли другие способы справиться с этим?

1 Ответ

5 голосов
/ 30 марта 2011

Я думаю, что лучшим решением было бы иметь два уровня контроля.

Один супервизор, который запускает пару супервизор + процесс для каждого gen_server, который вы хотите запустить.Этот супервизор сконфигурирован со стратегией one_for_one и temporary потомками.

Каждый супервизор, работающий под этим супервизором, правильно настроил бы значения MaxR и MaxT, что вызовет сбой этого супервизора, как толькоребенок ведет себя плохо.

Когда происходит сбой супервизора нижнего уровня, супервизор верхнего уровня "просто не заботится".

Супервизор потребляет 233 байта при запуске с одним дочерним элементом (общий размер кучи), поэтомупотребление памяти не должно быть проблемой.

Дерево наблюдения должно выглядеть так:

supervisor_top
    |
    |
    +------------------------+-----    ...
    |                        |
 supervisor_1               supervisor_2
 restart temporary          restart temporary
    |                         |
  gen_server_1              gen_server_2
  restart transient         restart transient
...