Oℕ
Т.е. в принципе известно, что если можешь написать решение без распределёнщины - нужно его так и писать
Size: a a a
2020 July 23
λ
В чем проблема иметь сервисы, а рядом пару тройку акторов?
ну наверное в такой общей постановке нет проблем)
ЮБ
В чем проблема иметь сервисы, а рядом пару тройку акторов?
А зачем? Если можно иметь только сервисы, без акторов?
AD
В чем проблема иметь сервисы, а рядом пару тройку акторов?
Проблема интеропа и проблема акторов
Oℕ
В чем проблема иметь сервисы, а рядом пару тройку акторов?
нет, проблемы, так и делали иногда
XX
с этим сложно спорить 🙂 если у тебя система не в одном JVM-процессе, это действительно проблема
да даже в одном процессе. Дело же не только в доставке сообщений, т.к. в любом request/response (в т.ч. без ask-ов) в принципе может быть любая проблема с обработкой сообщения (в самом акторе, цепочке акторов) и приходится либо на это просто забивать, либо обмазывать странной лапшой даже просто для того, чтобы донести ошибку до вызывающей стороны
VS
X X
да даже в одном процессе. Дело же не только в доставке сообщений, т.к. в любом request/response (в т.ч. без ask-ов) в принципе может быть любая проблема с обработкой сообщения (в самом акторе, цепочке акторов) и приходится либо на это просто забивать, либо обмазывать странной лапшой даже просто для того, чтобы донести ошибку до вызывающей стороны
Есть ошибки, которые нужно обрабатывать и тогда таких проблем не возникает по определению. Программерские ошибки нет смысла обрабатывать, надо фиксить. Так что зависит от того, как сделаешь.
Мне тяжело представить, где нужен ask, кроме границы между пользователем и сервисом, допускаю, что такие кейсы существуют. Получит пользователь ошибку с таймаутом или другую ошибку "что-то пошло не так" - ему все равно, запрос не выполнился. В остальных случаях можно и без ask жить. К слову, в акторах можно настроить supervision strategy и сделать так, чтобы у тебя не вся система сложилась из-за ошибки, а только один актор, например, обрабатывающий запросы пользователя.
Мне тяжело представить, где нужен ask, кроме границы между пользователем и сервисом, допускаю, что такие кейсы существуют. Получит пользователь ошибку с таймаутом или другую ошибку "что-то пошло не так" - ему все равно, запрос не выполнился. В остальных случаях можно и без ask жить. К слову, в акторах можно настроить supervision strategy и сделать так, чтобы у тебя не вся система сложилась из-за ошибки, а только один актор, например, обрабатывающий запросы пользователя.
VS
TL;DR: как напишешь - так и будет )
AD
TL;DR: как напишешь - так и будет )
Крайне плохая стратегия
VS
А какая хорошая?
VS
Кроме "бросить все и выращивать овощи в огороде"
M
Кроме "бросить все и выращивать овощи в огороде"
Крайне хорошая стратегия, главное масштабировать
ᛒ
TL;DR: как напишешь - так и будет )
AD
А какая хорошая?
"Как напишешь - так и будет" это фраза из разряда programming defeatism, смысл которой в открещивании ото всех попыток сделать как надо
VS
как раз наоборот. Ты можешь сделать как надо, а можешь, цитата, "обмазывать странной лапшой"
VS
и "как надо" - тоже расплывчатое понятие. В зависимости от задачи оно может означать "уродливо, но быстро" или "красиво и все равно как" или что-то еще
AD
как раз наоборот. Ты можешь сделать как надо, а можешь, цитата, "обмазывать странной лапшой"
Неа, как надо это не качество исполнения, это методология уменьшающая требования к качеству
ZM
В чем акка точно плоха, так это в том что всякая беседа о ней превращается в душные занудные софизмы на несколько дней.
ZM
Сразу хочется на дзяву и спринг.
VS
подальше от людей хочется >_<