МБ
два дня гуглил это параметр, блин
backoff_type: :stop в настройках репо, в итоге все не будет падать, будет только в лог писатьSize: a a a
2019 March 07
МБ
YZ
нагуглил
насколько понимаю, этот парам прекращает попытки реконнекта и делегирует обработку ошибок на разработчика,
а при значении по-умолчанию происходит сколько-то заданных в супервизоре попыток подключения, а потом коллапс
а при значении по-умолчанию происходит сколько-то заданных в супервизоре попыток подключения, а потом коллапс
МБ
можно увеличить количество до
max_restarts и использовать нужную стратегию через backoff_typeML
можно увеличить количество до
max_restarts и использовать нужную стратегию через backoff_typeЭто не то.
Суть супервизора в том, что бы сделать системе выкл и вкл. Если в ней накопились внутренние устранимые баги, то они вылечатся.
Если проблема снаружи, то надо сдохнуть и позвать старшего дежурного администратора
Суть супервизора в том, что бы сделать системе выкл и вкл. Если в ней накопились внутренние устранимые баги, то они вылечатся.
Если проблема снаружи, то надо сдохнуть и позвать старшего дежурного администратора
ML
Играя параметрами рестарта супервизора ты настраиваешь частоту и настойчивость штуки, которая должна вылечить внутренние баги путем рестарта
ML
Считай что супервизор - это швабра, которой надо бить по телевизору что бы он перестал шипеть и начал показывать что-то. Если стучать надо не чаще 3 раз в минуту, то ок. Если ударил 10 раз подряд, а он все шипит - выключай и включай.
Если 7 раз выключил - выдерни из розетки и зови человека
Если 7 раз выключил - выдерни из розетки и зови человека
AB
А как разрулить проблему с тем что рестарт неатомарный? ну то есть если кто-то рестартует то остальные должны предполагать это при каждом call, ловить noproc например
ML
Alexander Bogosyan
А как разрулить проблему с тем что рестарт неатомарный? ну то есть если кто-то рестартует то остальные должны предполагать это при каждом call, ловить noproc например
Норма - свалиться. Если кто-то делает call к процессу, который рестартится, значит от этого процесса ответ будет недостоверный. Лучше упасть всем по цепочке и запросить заново
AB
а если этот call предполагает {ok, Result} | {error, Reason}, почему не вернуть {error, noproc} и ответить 503 клиенту например?
AB
или сделать ретрай
МБ
Это не то.
Суть супервизора в том, что бы сделать системе выкл и вкл. Если в ней накопились внутренние устранимые баги, то они вылечатся.
Если проблема снаружи, то надо сдохнуть и позвать старшего дежурного администратора
Суть супервизора в том, что бы сделать системе выкл и вкл. Если в ней накопились внутренние устранимые баги, то они вылечатся.
Если проблема снаружи, то надо сдохнуть и позвать старшего дежурного администратора
Не спорю, но у меня проще ситуация, есть бот, у него 5 баз, если, вдруг, одна упала, он должен продолжить работать с остальными и подождать пятую, а не рухнуть цедиком
МБ
Как правило даун продолжается несколько секунд, но за это время все валится, что недопустимо
A
Подскажите, туплю, почему ошибка компиляции и
https://gist.github.com/lyo5ha/909f1389e1c2622b2d08386650f1da0c
list_count.ex:8: undefined function work/2, она же в модуле лежит под носом.https://gist.github.com/lyo5ha/909f1389e1c2622b2d08386650f1da0c
IS
В модуле указана work/1
IS
А вызывается work/2
A
Блин, гениально. Вот это я затупил. спс.
IS
Там, очевидно, имелось ввиду просто ... |> work()
A
Не прпробовал, все равно
list_count.ex:7: undefined function work/1ML
Не спорю, но у меня проще ситуация, есть бот, у него 5 баз, если, вдруг, одна упала, он должен продолжить работать с остальными и подождать пятую, а не рухнуть цедиком
Тогда это задача бота понять, что с той стороны дохлый сервер, завернуть работу с ним в try/catch