Е
вы что-то делаете не так (c)
Size: a a a
2018 November 08
DR
вы что-то делаете не так (c)
Все мы делаем так... Не так - это позволять из-за дизайна ген сервера cascading failure.
DR
Который приводит к большой нагрузке в системе.
AG
ну если я не ошибаюсь любой сервер в том числе и Gen падать должен редко, а желательно никогда, если сервер падает это косяк который надо фиксить. вы согласны? :)
DR
Опять же, если процессы связаны, то они будут и на уровне супервизора связаны чаще всего. Ситуации разные бывают, но когда один процесс может жить без другого - он не должен падать из GenServer.call-а и никакие без основанные цитаты-клише, когда нет аргументов, типа ты "делаешь что-то не так" - не переубедят меня в этом.
DR
ну если я не ошибаюсь любой сервер в том числе и Gen падать должен редко, а желательно никогда, если сервер падает это косяк который надо фиксить. вы согласны? :)
Да, кроме тех случаев - когда это Flow в дизайне библиотеки, который не просто пофиксить.
DR
Опять в продакшене не все так однозначно, потому что авторы библиотек не идеальны - и со всем этим надо работать, если хочешь чтобы твоя система работала стабильно.
DR
ну если я не ошибаюсь любой сервер в том числе и Gen падать должен редко, а желательно никогда, если сервер падает это косяк который надо фиксить. вы согласны? :)
А ещё, не повод на каждый косяк падать половине системы, и нет систем без багов, поэтому на каждое падение система должна адекватно реагировать... И повторюсь - если два процесса могут прожить один без другого - то при падении первого второму падать не нужно.
DR
Фиксишь нужный ген сервер и радуешься, что у тебя пол системы не упало и не создало огромнейшей нагрузки из-за одного мелкого бага.
AG
не, я за то чтобы фиксить баги
ŹR
GenServer пришёл без переделок из эрланга, а там никто не заморачивается из-за try catch
ŹR
И если бы сделали специальный “call!”, внутри все равно был был exception
ŹR
Я конечно понимаю, что психологически легче вызывать функции и не писать try блок, но под капотом одно и тоже
ŹR
Иначе нужно походу патчить beam, но я понятия не имею можно ли это в принципе сделать или нет, и на что это повлияет
YZ
Dmitry Russ (Aleksandrov)
try do- подобный код у нас часто встречается.
GenServer.call(...)
catch
:exit, {:timeout, {GenServer, ...}} ->
{:error, ...}
end
Я никогда за всю свою практику такого не делал. Если ген сервер не успевает делать всю работу, которой его нагружают, то надо что-то менять в системе так, что бы успевал. Искать узкое место и устранять.
YZ
И если бы сделали специальный “call!”, внутри все равно был был exception
Зачем нужен такой call, если уже есть cast?
YZ
Это, типа, ответь мне на такой-то запрос, но если не можешь ответить, то и фиг с ним. Мне ответ не очень-то и нужен.
YZ
Это довольно странное поведение :)
YZ
Какой бы мощной не была система, у нее все равно есть предел. Таймаут на ген-сервере, это один из типичных признаков того, что система достигла предела. И про этот факт очень хотелось бы вовремя узнать. А скрывать этот факт от самого себя - - плохая идея.
DR
Yuri Zhloba
Какой бы мощной не была система, у нее все равно есть предел. Таймаут на ген-сервере, это один из типичных признаков того, что система достигла предела. И про этот факт очень хотелось бы вовремя узнать. А скрывать этот факт от самого себя - - плохая идея.
Чаще всего отлавливается то, что процесса уже нет. К примеру, у нас можно для каждого рабочего юнита - получить с него информацию, чем он занимается, но я хочу чтобы ответ был - юнит уже умер, вместо того, чтобы спрашивающий процесс крэшился.