IMHO
Если уж изучать, то тогда хардкордно Erlang. Так сказать первоисточник.

Сталкивался с AKKA.... толи заливная рыба... толи Карузо в перепеве Рабиновича. Т.ч. если уж изучать, то подлинник.

На форуме была ветка с парой десятков страниц AKKA-срача. Но людей которые бы на нем реально кодили большие системы, как-то не наблюдается.

andreykaTобщение через мессаджи между сервисами.
универсальный механизм общения между любыми объектами-акторами в системе. Т.е. это не только и не столько общение/сеть, сколько совместная работа/отсутвие блокировок/многозадачность.

IMHO & AFAIK

Повторю мою критику AKKA из четверговых акторов

Там ошибко-безопасность. Насколько я понял читая теорию актор может падать в хлам сколько угодно.

OK. Упал, подняли, в общем проблемы с актором действительно нет.

При этом ни один байт данных не пострадает и месседжи
которые будут необработаны остаются в очередях до тех пор пока поднятый актор снова их не отработает.

Стоп... стоп... стоп... Что значит, ни один байт не пострадает?
Логика работы:
1. Актор ПОЛУЧИЛ сообщение из очереди (оно из очереди уже УШЛО)
2. Актор попытался его обработать и почему-то УПАЛ
3. Т.к. упал, актор НЕ смог послать сообщения-ответа с результатом или ошибкой.

Необработанное сообщение ПОТЕРЯЛОСЬ и, самое страшное, ошибки нет (((

Ищущий Знаниявот сейчас финансовую систему.
So do I.
Точнее So did I ))) в past simple )))

Ищущий Знания....Все вот эти ваши сайтики... отлично пишутся на акторах....

"финансовая система", "микросервис", over несколько сотен тысяч юзеров по миру.

Первый сценарий:

NIO.

Клиент установил соединение, channel записался в какие-то внутренние списки NIO
Клиент прислал HTTP-запрос, запрос записался в какие-то внутренние списки NIO, ожидает ассинхронного ответа
Разобрали запрос, сформировали AKKA-сообщения, послали актору
На ответное AKKA-сообщение, формируем HTTP-ответ и отсылаем через NIO, после отсылки NIO свои списки почистит

Какой-то актор из 100500 акторов в системе "ошибко-безопасность" упал.... УПС.... а как мы об этом узнаем?... нам же НИЧЕГО в ответ никто не пришлет и прислать не может (т.к. актор который должен был послать ответ "упал")

Т.е. получаем "ошибко-безопасный" resource leak

note: более частая ситуация, программист в одном из 100500 if в коде или забыл послать сообщение-ответ или не верно сформировал сообщение-ответ (поэтому актор "верхнего уровня" его не получил). Или ошибка или рефакторили и в процессе рефакторинга пару мест пропустили. Ошибки нет, а resource leak есть (((

Второй сценарий:

Создание акторов - все хорошо. В "финансовой системе" на каждый символ на бирже создавали отдельный актор. Для "обычных бирж" где торгуется несколько тысяч, максимум десяток тысяч символов... все хорошо ))) Но были отдельные случае бирж (специфику я уже не помню), где коль-во символов было за сотни тысячь.... УПС.... а память то не резиновая... до 300-500 000 акторов система ЖУТКО тормозила, но стоически пыталась работать, но после 500 000 акторов - просто падала

Отсюда мораль: Акторы нужно не только создавать, но и стопить.

А как КОРРЕКТНО остановить актор в AKKA ?

Упс... Упс.... Оно же асинхронно и доступа к очереди нет... Упс... Пытаемся остановить актор, а он, в этот момент, из очереди уже какое-то сообщение прочитал/читает/обрабатывает. Если мы ему скажем AKKA'вскую STOP, то это будет просто KILL, с ПОТЕРЕЙ ВСЕХ НЕОБРАБОТАННЫХ СООБЩЕНИЙ в его очереди + описанный Выше resource leak.

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

Очень хотелось бы узнать от ГУРУ, как без велосипедо-строения и без русской матери, два описанных выше кейса можно реализовать на AKKA ? Кейсы не теоретические, а практические, по результату работы с реальной "финансовой системой"

Ищущий ЗнанияСерьезно отвечать на эти высеры, тем кто реально пишет на акке проекты, не интересно
Повторю свой вопрос:
КАК КОРРЕКТНО ОСТАНОВИТЬ АКТОР В AKKA с гарантией отстутствия потерль данных/сообщений.

Мне кажется, что ответ на такой элементарный вопрос должен легко находится.... но я я искал и ответа не нашел (((. В результате пришлось писать и тестировал под тысячу строк велосипедо-кода в реальном проекте. С огромной кучей synchronize, коллекций и прочий мути. От которых AKKA обещает "избавить программиста"

При этом ни один байт данных не пострадает и месседжи
которые будут необработаны остаются в очередях до тех пор пока поднятый актор снова их не отработает.

упс... упас...

насколько я помню, в AKKA, каждому актору соответствует своя "очередь" (в кавычках! там все хитро). Если мы актор останавливаем, то его очередь убивается тоже. Подозревая, что если актор упал и мы создаем новый, то тоже, у нового актора будет новая очередь

Т.ч., как раз таки, мы ТЕРЯЕМ ВСЕ необработанные сообщения, т.к. с актором теряем все содержимое его очереди

Плохо не то, что теряем, плохо то, что теряем ТИХО. Т.к. сообщить об ошибке, нам никто не может. Актор-верхнего уровня, сообщение корректно послал. Актор-нижнего уровня, просто упал. Данные потерялись в между-акторном-пространстве В результате, в каком-то звене системы получаем или resource leak или performance проблему (в случае retry по timeout'у)

IMHO & AFAIK

Declaimer :
НЕ ИМЕЮ НИЧЕГО ПРОТИВ акторов как идеи. Т.к. оригинального Erlang'а не видел/не знаю. Идея, сама по себе, вроде хорошая.
Сужу о Корузо (акторы, erlang) по перепевам Рабиновича (AKKA).

забыл никВообще есть подозрение что вы их просто так и научились готовить
честно говоря, я и не пытался. Я там вообще месяца 3-4 проработал, из них больше месяца разбирался с peformance проблемой с NIO на продакшин сервере. Т.ч. больше занимался или системным (NIO) или performance (NIO, PostgreSQL и прочее)

Меня больше удивляло, что люди которе на проекте > 3 лет + контора до этого работала с ErLang'ом как-то не сильно умели их готовить. Акторы работы с базой, у меня вообще вызывали жуткое ощущение (((

забыл никНу и 300-500 тысяч это на одной ноде? Ну как бы неудивительно, акторы еще и скалить можно.

Честно говоря, у меня вообще полное непонимание желания заменить СУБД на что-то в памяти. (будь это или акторы или экземпляры классов).

Да занафига скалить, если они все одновременно не нужны. Просто впилил LRU Cache (из Apache Commons) и гасил неиспользуемые акторы. Но вот про "When a message is sent to an Actor that is terminated before receiving the message, it will be sent as a DeadLetter to the ActorSystem's EventStream" не знал (((

Чувство, что делаем велосипеды возникало. Но опять таки, сам до этого с AKKA не сталкивался, а народ который до этого вроде работал аж с ErLang'ом тоже ничего предложить/сказать не мог.

забыл никХотя конечно нельзя не согласится что дебажить трудно,

причина по которой контора ушла от ErLang'а.

Но там вообще был полный зоопарк. Когда я там был, у них был новый любимец - Go
Erlgang - сложно дебажить
Java - тормозная
Go это наше будущее )))

забыл никНу тут интересно на самом деле.. а что и как они пытались заменить?

Блокировки в БД (select for update) это плохо (для производительности)
А мы распилили БД по символам, символы в акторы - блокировок нет (явные блокировки в БД не нужны)

)))
забыл никevent sourcing

Там сама система целиком (я работал в команде над только одним микросервисом, "всю" задачу целиком не видел), скорее была как event sourcing.

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

===

Еще одна проблема, которую пытались решить "велосипедом". Performance и необходимость сооружения "бутылочного горлышка"

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

Если в AKKA какое нибудь средство ограничить длину очереди для актора?