когда восстановление процесса с начальным стейтом абсолютно бесполезно

202 и 208 статусы становятся просто как родные ?

не проще ли ловить ошибки обработки сообщений и отвечать отправителям этих сообщений каким-нибудь {:error, :unknown_reason}, за одно записать в лог причину ошибки и отправить сообщение разрабу, чтобы позырил и устранил. А потом продолжать обрабатывать остальные сообщения.

если стейт ценен - он должен сразу персиститься наружу в базу

вот вот

так, а альтернатива какова? Допустим стрим весьма ценнен и нельзя терять сокет, значит сокетом владеет один процесс, а принимает данные другой.

чанки просто принимать и обрабатывать потом. Фактически тут просто труба - влить данные с ответом 202 или 208 если такие уже поймал чанки. Обработать потом тихо в норке никого не тревожа

так, а let it crash где мешает этому?

а если чел хранит ценный стейт в сервисе а потом пытаестя всеми силами его спасти то тут что то не так

так, а let it crash где мешает этому?

я выше написал о костылях чтобы летиткреш цвел и пах

когда нельзя клиента держать в ожидании 200

да ну нахер этот лет ит краш

ошибка с одним клиентом должна по минимуму влиять на работу других клиентов

просто у летиткреша есть обратная сторона - когда крешнулся не тред, а ВМ решила что все плохо и делает не рестарт, а релоад

Ну так это не костыль, нужно правильно разбивать состояние на процессы, и каждый может независимо падать -- всё в русле let it crash

а тут вся очередь сообщений херится - в жопу такой лет ит креш.

в итоге если у тебя на трубе клиенты, они все повисли

просто у летиткреша есть обратная сторона - когда крешнулся не тред, а ВМ решила что все плохо и делает не рестарт, а релоад

wat

я не агитрую против, я за понимание что это не панацея

Ну так это не костыль, нужно правильно разбивать состояние на процессы, и каждый может независимо падать -- всё в русле let it crash

Ну если ты пишешь сраный бложик, то наверное так можно.

wat

ага, я тоже так WAAAT когда первый раз процесс поднимался секунд 5

когда нельзя клиента держать в ожидании 200

так ответь ему сразу ченить и путь он потом перезапросит

просто у летиткреша есть обратная сторона - когда крешнулся не тред, а ВМ решила что все плохо и делает не рестарт, а релоад

я просто вообще не понял, что ты за ситуацию описываешь

так ответь ему сразу ченить и путь он потом перезапросит

вот да.

так ответь ему сразу ченить и путь он потом перезапросит

я так и сделал. Принял данные и сразу отпустил клиента с миром, мол принято

отдал ему ключ с которым он придет позже за результатом

Если стейт в результате ошибки не портится накой подыхать-то нужно?

просто у летиткреша есть обратная сторона - когда крешнулся не тред, а ВМ решила что все плохо и делает не рестарт, а релоад

Чёт я запутался совсем. Тред, имеется ввиду OS thread? ВМ делает рестарт/релоад -- в какой момент? Супервизор делает рестарт для отдельных процессов, да.

отдал ему ключ с которым он придет позже за результатом

+1

я просто вообще не понял, что ты за ситуацию описываешь

я вот тоже ещё не понял проблему

отдал ему ключ с которым он придет позже за результатом

а еще принял от него его ключ к этим же данным, чтобы клиент мог что-то узнать, если не получит ответа

Чёт я запутался совсем. Тред, имеется ввиду OS thread? ВМ делает рестарт/релоад -- в какой момент? Супервизор делает рестарт для отдельных процессов, да.

я про лайтвейт треды, типа таски и прочее, что может крашится и не важно, beam все разрулит

ага, т.е. процессы эрланга

но есть момент, когда например в тред подал кривой код или данные и код еще кривой. На примере загрузки изображений. Все наверное пытались пользоваться ark

в нем был интересный баг - таск мог ломаться так, что beam убивала весь процесс

у меня вот некий сторонний сервис может тупо ответить кривым json или невалидным utf и что мне из-за этого валить половину системы?

при это происходит перегрузка приложения, что занимает несколько секунд если приложение небольшое.

что-то вообще неправильно, зачем перегрузка?

у меня вот некий сторонний сервис может тупо ответить кривым json или невалидным utf и что мне из-за этого валить половину системы?

о! это мое любимое. Феникс на ковбоее из коробки валится на кривом пейлоаде

у меня вот некий сторонний сервис может тупо ответить кривым json или невалидным utf и что мне из-за этого валить половину системы?

ну так обработай это. let it crash или нет - на свое усмотрение

в нем был интересный баг - таск мог ломаться так, что beam убивала весь процесс

в смысле, ошибка доходила до корневого супервизора приложения и оно отмирало целиком?

о! это мое любимое. Феникс на ковбоее из коробки валится на кривом пейлоаде

что прям весь erlang процес валится?

ну так обработай это. let it crash или нет - на свое усмотрение

тут есть одна интересная мелочь. Если клиент шустрый, то может сделать очень много запросов и тогда супервизор не поднимет процесс, т.к он считается плохим

если ты получил кривой ответ, и он не матчится -- процесс падает, всё правильно. Если это суперважно, то супервизор пытается рестартануть его, и потом дохнет всё приложение. Если это не важно, то просто нужно добавить процесс как transient в supervision tree, и он молча сдохнет никому не помешав.

так настройку супервизора можно поменять

Короче, let it crash - не нужен. ?

что прям весь erlang процес валится?

нет, феникс просто засирает все в логах и выдаст 500, но клиент как бы хотел просто что неверный пейлоад

что за пейлоад?

кривые данные в каком-нибудь POST-запросе?

так настройку супервизора можно поменять

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

если клиент сам кривой то пусть на свою рожу пеняет

если клиент сам кривой то пусть на свою рожу пеняет

это не хороший вариант. Сервер железобетонно должен дать нормальный ответ а не 500

подай тому же гитхабу на апи хоть полено

не надо делать работу клиента за него

это не хороший вариант. Сервер железобетонно должен дать нормальный ответ а не 500

Абсолютно согласен. Все 500-ые ошибки должны планомерно искореняться

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

так там временные настройки вроде есть

пятисотками святить не дело. Да и в моем случае мне клиент за 10 минут выжрал всю квоту в трекере ошибок

какой-то странный диалог

да)

какой-то странный диалог

я запутался, кому ответил, кого пропустил

тетралог?

или пенталог?

какой-то странный диалог

оче сложно, еще и терминологию не все соблюдают

короче ребята, все в ваших руках и если что-то не работает сами знаете кто виноват и что делать

короче: летиткреш - не панацея, beam может острелить весь процесс и переподнять его, что займет несколько секунд и ну никак не катит на летиткреш. святить 500 всем подряд - плохо, нужно все отлавливать и выдавать клиенту какой-то нормальный ответ или банить сразу

На самом деле let it crash - это совсем не философия эрланга или эликсира как языков. Скорее это философия OTP

которой можно подтерется, если хочется.

короче: летиткреш - не панацея, beam может острелить весь процесс и переподнять его, что займет несколько секунд и ну никак не катит на летиткреш. святить 500 всем подряд - плохо, нужно все отлавливать и выдавать клиенту какой-то нормальный ответ или банить сразу

отстрелить процесс или приложение?

На самом деле let it crash - это совсем не философия эрланга или эликсира как языков. Скорее это философия OTP

меня в эликсир купили летиткрешем, приятным синтаксисом(ПАЙПЫЫЫЫ!!), и шансом быть пионером, чтобы потом плевать с трона во вновь прибывших и брюзжать, как дед

ERROR: S client not available

отстрелить процесс или приложение?

+1. это что за процесс такой должен быть, чтобы секунды подниматься

отстрелить процесс или приложение?

+1

короче: летиткрэш -- самая охуенная вещь для создания архитектуры что была придумана за последние 30 лет

> шансом быть пионером, чтобы потом плевать с трона во вновь прибывших и брюзжать, как дед ты уже опоздал, нужно было на эрланге начинать

отстрелить процесс или приложение?

весь апп, т.к он пропадает из процессов и потом раскручивается вновь

ок, теперь понятно. да, есть такое

Мне такое чувство, что все кто хают let it crash в чяте тупо не дочитали доку про supervision trees и child specs

короче: летиткрэш -- самая охуенная вещь для создания архитектуры что была придумана за последние 30 лет

+100

если фениксу сунуть кривой HTTP-заголовок или просто мусора насыпать в сокет, он что тоже сделает let it crash, навалит кучу красного говна в логи и ответит 500-й ошибкой?

а то я уж было подумал, что что-то упустил в понимании того, как бим работает)

если фениксу сунуть кривой HTTP-заголовок или просто мусора насыпать в сокет, он что тоже сделает let it crash, навалит кучу красного говна в логи и ответит 500-й ошибкой?

да просто скобку не закрой в json и подай ему, будет тебе красный лог и 500

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

потому у OTP есть механизм failover-takeover. избыточный по сути, но есть.

дело в том что брюзжать все равно придется и надо просто выбрать с чем )))

ну в своих контроллерах я, допустим могу сам обрабатывать json-ы и ловить ошибки их парсинга, а что с тем, что обрабатывается в глубинах самого феникса?

не используйте феникс)

+1

мы в нынешней итерации архитектуры вообще отказались от сколько-то долгоживущих процессов.

ну в своих контроллерах я, допустим могу сам обрабатывать json-ы и ловить ошибки их парсинга, а что с тем, что обрабатывается в глубинах самого феникса?

там до контролера дело не дойдет, причем даже до роутера фениксового не долетят запросы

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

Ну одно дело удобные механизмы автоподнятия упавших процессов - это хорошо. Другое дело философия "упало, ну и хуй с ним, само поднимется"

все свалится на эндпоинте и плаге

не используйте феникс)

+1

из всего что есть, феникс ок

А что использовать? голой ковбой? там есть шанс чего-то поймать?

анонимные стейтлесс воркеры на очередях. даже beam как таковой не нужно

Ну одно дело удобные механизмы автоподнятия упавших процессов - это хорошо. Другое дело философия "упало, ну и хуй с ним, само поднимется"

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

короче, это уже на совести того, кто архитектуру проектирует. за это деьги платят в конце концов)

ну я let it crash именно так и понял "упало, ну и пусть, забей болт"

ну я let it crash именно так и понял "упало, ну и пусть, забей болт"

ненене! ни в коем разе!

бля, вы меня печалите с фениксом

из всех говн, феникс самое нормальное говно

неконтролируемые 500-е ошибки меня бесят ужасающе