DF
Селектив ресивом, конечно.
Size: a a a
2019 November 18
V
со всеми пеналтями, ага
DR
@define_null @shizzard Полностью согласен, в общем-то вы меня понимаете, почему я не хочу блокировать процесс и собирать сообщения в меилбоксе.
V
ну вот попробуй через это аргументировать
DF
Я вообще проблему не понял, просто триггернулся на селектив ресив :)
ML
Dmitry Russ (Aleksandrov)
Привет! Вопрос по архитектуре и дизайну.
Есть long running worker, который выполняет сложную логику, который очень сложно было дебаггить.
Теперь, я в своё время добавил то, что он собирает статистику и сделал его дизайн полностью step-by-step, что он мог останавливаться (по запросу), что его можно было интроспектировать и говорить, работай дальше, при том основную часть запросов я там научил складывать в queue и не держать в message queue.
Пришёл другой разработчик и хочет возможность процесса работать step-by-step убрать и добавить
Мне казалось правильнее, если процесс сам умеет обрабатывать вещи частями, а другой разработчик считает, что это должно быть не в buisness логике, а вообще отдельно и вот таким образом приделывает.
Что считаете? Как по Вашему опыту лучше? Заранее благодарю за любое мнение.
Есть long running worker, который выполняет сложную логику, который очень сложно было дебаггить.
Теперь, я в своё время добавил то, что он собирает статистику и сделал его дизайн полностью step-by-step, что он мог останавливаться (по запросу), что его можно было интроспектировать и говорить, работай дальше, при том основную часть запросов я там научил складывать в queue и не держать в message queue.
Пришёл другой разработчик и хочет возможность процесса работать step-by-step убрать и добавить
debugger модуль, а основной процесс умеет только делать - attach_debugger, detach_debugger и добавляет в одном месте возможность обратиться к дебаггеру и блокируется и уже другой процесс отвечает за то, продолжить или остановиться и что делать с процессом.Мне казалось правильнее, если процесс сам умеет обрабатывать вещи частями, а другой разработчик считает, что это должно быть не в buisness логике, а вообще отдельно и вот таким образом приделывает.
Что считаете? Как по Вашему опыту лучше? Заранее благодарю за любое мнение.
офигенно, если у тебя получится превратить его в машинку (настоящий fsm), обрабатывающую входные команды в таком стиле, чтобы у тебя мог получиться replay log
СИ
со всеми пеналтями, ага
Так затык обработки уже авария. Чо на пинальти пенять. К тому же в 21 оптимизировали же
V
Затык обработки это твоя стратегия бороться с оверлоад. Ты можешь встать раком, а можешь обработать столько сколько можешь.
DF
У тебя затык обработки by desing если ты сообщения оставляешь в очереди.
V
Но трабла в том, что ты даже backpressure сделать на этом нормально не можешь, чтобы сказать другому процессу - горшочек не вари, дай я разгребу.
V
т.е. в итоге что будет случаться -креш по памяти и потерянные очереди сообщений. Неограниченные очереди, тем более на мессадж кью процесса здоровенный антипаттерн для акторных систем
V
почитай Planning for Overload от Freda если мне не веришь =)
СИ
У тебя затык обработки by desing если ты сообщения оставляешь в очереди.
Про то и речь. Перекладывание яиц это прячет
DF
Куда прячет?
V
перекладывание яиц даёт тебе возможность обработать этот затык так как тебе нужно
V
а ты предлагаешь игнорить
DF
У тебя кроме message_queue_len инструментов интроспекции нет?
СИ
Куда прячет?
В никуда. От рефакторинга. А дропнуть очередь и системную можно. См gun
V
В никуда. От рефакторинга. А дропнуть очередь и системную можно. См gun
куда смотреть-то конкретно?