PG
Ничего, минус сообщения
Size: a a a
2020 April 26
V
Как понять "ничего"? Все необработанные сообщения будут утрачены? Или все необработанные сообщения будут доступны в receive перезапущенного процесса?
PG
Да, утрачены. Подумай сам, в общем случае у процесса может не быть супервизора или супервизор может его не рестартовать
PG
В конце концов супервизор перезапускает не процесс, а своего ребёнка, процесс – новый
V
И какие способы используются, чтобы не терять сообщения в мессаджбоксах?
PG
Лучше бы я не знал
PG
Очереди сообщений, если вкратце
V
Т.е. не хранить сообщения в мессаджбоксах процессов? Ясно
PG
Ну может у тебя данные не особо важные и их можно терять, всякое бывает
V
Это детали. Мне интересен сам принцип, как и почему в супернадёжном эрланге теряются сообщения в мессаджбоксах. Ну как интересен. Шаблон трещит.
PG
Не существует никаких супернадежных эрлангов, это миф. Есть эрланг, он дает тебе акторную модель. Есть OTP, он дает тебе стандартные акторы для построения дерева наблюдения. Все, дальше сам.
LL
Доброй ночи. Кто знает хороший способ обхода деревьев с поиском узла с остановкой при нахождении? Я сделал через два условия: совпадение?; есть дети? -> создать список и перезапустить. Сначала попался на том, что возвращается не конечное значение, а значение при котором была вызвана рекурсия. Нашёл выход через find_value. Но все как-то криво. Кто как делает?
throw catchAU
Любопытно
AU
Посмотрел, написано что try отменяет рекурсивную оптимизацию. В моём случае в этом нет ничего страшного, потому что деревья короткие, но надо иметь ввиду.
LL
V
Следующий вопрос.
Что происходит с сообщениями в мессадж боксе умершего процесса?
Например есть процесс с пидом
Я в курсе, что этот вопрос целиком и полностью про эрланг. Но почему-то до сих пор ответ мне не попадался.
Что происходит с сообщениями в мессадж боксе умершего процесса?
Например есть процесс с пидом
pid. В этот пид другие процессы накидали три тысячи сообщений. А он взял и помер, не успев обработать все, но затем быстренько был восстановлен супервизором. Что произойдёт с необработанными сообщениями?Я в курсе, что этот вопрос целиком и полностью про эрланг. Но почему-то до сих пор ответ мне не попадался.
Никакого дефолтного способа в эрланге нет, но эта проблема легко решается в отп. Проблема в том, что процесс не может знать почему упал другой процесс без явной коммуникации между ними, поэтому тут процессы могут падать от ошибок, могут падать от физических проблем, могут падать от ошибок в биме, могут падать от нагрузки и не всегда вообще можно получить очередь
Если процесс падает от ошибок, то есть в
Если нужно правда хранить сообщения, то есть уже готовые
Если процесс падает от ошибок, то есть в
GenServer коллбек terminate в котором можно посмотреть очередь и переслать её куда-нибудь, например. Но это какой-то экстренный и ненадёжный костыль.Если нужно правда хранить сообщения, то есть уже готовые
rabbitmq и прочее. Если кролик слишком большой, то можно сделать свою реализацию (но велика вероятность что получится неподдерживаемое говно, в котором разбирается только один человек)AF
V
И какие способы используются, чтобы не терять сообщения в мессаджбоксах?
Пославший сообщение процесс вешает монитор на тот процесс, которму послал сообщение. Если ответа он не получит, а монитор сработает, то он узнает, что возможно сообщение не было обработано. Это не совсем способ “не терять сообщения”, но это то, как с этим явлением живут.
На практике просто стоит пользоваться не прямой посылкой сообщений, а синхронными вызовами типа
На практике просто стоит пользоваться не прямой посылкой сообщений, а синхронными вызовами типа
GenServer.call.a
V
Следующий вопрос.
Что происходит с сообщениями в мессадж боксе умершего процесса?
Например есть процесс с пидом
Я в курсе, что этот вопрос целиком и полностью про эрланг. Но почему-то до сих пор ответ мне не попадался.
Что происходит с сообщениями в мессадж боксе умершего процесса?
Например есть процесс с пидом
pid. В этот пид другие процессы накидали три тысячи сообщений. А он взял и помер, не успев обработать все, но затем быстренько был восстановлен супервизором. Что произойдёт с необработанными сообщениями?Я в курсе, что этот вопрос целиком и полностью про эрланг. Но почему-то до сих пор ответ мне не попадался.
Честно говоря, хотелось бы увидеть пример. Если у вас в очереди накапливается 3 тысячи сообщений, которые обязательно нужно обработать, иначе сообщить о фейле и как-то восстановится без потери сообщений - заведомо выбран неправильный инструмент.
Эрланг предоставляет (акторную) систему, которая позволяет системе быть, что называется, self-healing, и не более того.
Вам требуются какие-то гарантии. Это уже различные MQ решения, как упомянули выше
Эрланг предоставляет (акторную) систему, которая позволяет системе быть, что называется, self-healing, и не более того.
Вам требуются какие-то гарантии. Это уже различные MQ решения, как упомянули выше
AB
Плюсану про call
AB
Он очень много вопросов снимет. Если сообщений накапливается много, то это проблема. Добавляй железа. Если оно разгребает и хватает памяти, то вроде не очень проблема. Если не хватает памяти — добавить. Бесконечно то оно расти не будет, потому что у call дефолтный тайм-аут 5 секунд.
AB
Суть в том, что просто надо прийти к пониманию того, что система может разгребать в секунду определенное значение запросов. На чем бы ни была написана.