AB
erts: A received SIGTERM signal to beam will generate a 'stop' message to the init process and terminate the Erlang VM nicely. This is equivalent to calling init:stop/0.
Size: a a a
2021 January 14
AB
То есть, он должен корректно сообщение stop прислать
AN
Привет! Я не очень опытен с эликсиром, возник затуп, надеюсь, вы мне поможете)
У меня есть пул GenServer под управлением пуллбоя. Я хочу сделать graceful shutdown по sigterm. Проблема вот в чём - если на момент вызова terminate в инбоксе процесса есть какие-то сообщения - то они теряются. Есть ли какой-то способ в этот момент достать все сообщения, обработать, а потом уже выйти?
Или как вообще принято делать? Ничего внятного нагуглить не смог
У меня есть пул GenServer под управлением пуллбоя. Я хочу сделать graceful shutdown по sigterm. Проблема вот в чём - если на момент вызова terminate в инбоксе процесса есть какие-то сообщения - то они теряются. Есть ли какой-то способ в этот момент достать все сообщения, обработать, а потом уже выйти?
Или как вообще принято делать? Ничего внятного нагуглить не смог
в
trrminate колбэке вызвать рекурсивный receive do m -> process(m) after 0 -> : ok endVP
Привет! Я не очень опытен с эликсиром, возник затуп, надеюсь, вы мне поможете)
У меня есть пул GenServer под управлением пуллбоя. Я хочу сделать graceful shutdown по sigterm. Проблема вот в чём - если на момент вызова terminate в инбоксе процесса есть какие-то сообщения - то они теряются. Есть ли какой-то способ в этот момент достать все сообщения, обработать, а потом уже выйти?
Или как вообще принято делать? Ничего внятного нагуглить не смог
У меня есть пул GenServer под управлением пуллбоя. Я хочу сделать graceful shutdown по sigterm. Проблема вот в чём - если на момент вызова terminate в инбоксе процесса есть какие-то сообщения - то они теряются. Есть ли какой-то способ в этот момент достать все сообщения, обработать, а потом уже выйти?
Или как вообще принято делать? Ничего внятного нагуглить не смог
Навскидку погуглил: https://github.com/botsquad/graceful_stop
u
Спасибо ребят, буду эти варианты смотреть
IK
в
trrminate колбэке вызвать рекурсивный receive do m -> process(m) after 0 -> : ok endкласс 👍
IK
статью бы запилить по этому поводу
AN
класс 👍
да это хреновый подход так-то) не должны сообщения в инбоксе копиться в идеале
AN
но как говорится, "так делать нельзя, но если очень хочется, то иногда можно"
ŹR
в
trrminate колбэке вызвать рекурсивный receive do m -> process(m) after 0 -> : ok endЯ даже боюсь представить что будет, если случайно внутри этого process посылаются сообщения на еще один подобный генсервер, который тоже заблочился в terminate
IK
Я даже боюсь представить что будет, если случайно внутри этого process посылаются сообщения на еще один подобный генсервер, который тоже заблочился в terminate
можно запустить другой процесс, который по истечении таймаута, сделает hard kill
ML
тут надо менять подход
если процесс пошел помирать, а от него что-то ждут, значит надо смириться с этим и выстроить процесс посылки сообщений с пониманием этого факта
На terminate рассчитывать нельзя. Во-первых, он всегда вызывается, во-вторых не обязан он вообще вызываться
если процесс пошел помирать, а от него что-то ждут, значит надо смириться с этим и выстроить процесс посылки сообщений с пониманием этого факта
На terminate рассчитывать нельзя. Во-первых, он всегда вызывается, во-вторых не обязан он вообще вызываться
ŹR
Я думаю что система с gracefull stop вся должна строится на внешних процессах и зависеть от бизнес логики
ŹR
Т.е. мы сперва делаем так, чтобы в системе не появлялось энтропии в виде новой инфы - это часть номер один
ŹR
А вторая часть - понять что все кто разгребал - освободились
ML
Я думаю что система с gracefull stop вся должна строится на внешних процессах и зависеть от бизнес логики
> система с gracefull stop вся должна строится
система с gracefull stop в 21-м году не должна строиться =)
это как бы пройденный этап из тех древних времен, когда ещё полагали, что такое сделать можно и нужно
система с gracefull stop в 21-м году не должна строиться =)
это как бы пройденный этап из тех древних времен, когда ещё полагали, что такое сделать можно и нужно
IK
еще как вариант, можно вынести message inbox из системы к какую-нибудь queue, что само собой напрашивается раз сообщения нельзя терять
IK
да это хреновый подход так-то) не должны сообщения в инбоксе копиться в идеале
я не знал что это возможно)
AN
складывать все необработанные сообщения в :dets и на старте ее процессить, потом попытаться сделать нормальную очеред к своему пулбою и через два года обнаружить, что вы переизобрели кролика)