забыл никЕсли вам нужно блокирующее ожидание, то акторы идут мимо вас. Это совершенно другая Concurrency model, глупо на нее смотреть с позиции sharing&Locking.
+++
акторы это совершенна другая идеология, местами логична, местами идиотична..

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

забыл никНет такой задачи, которую обязательно нужно(и только на акторах решать) это просто еще один инструмент, где-то он подойдет лучше, где-то хуже.
имхо
а вот это совсем не факт. сомневаюсь, что один и тот же разработчик, может одинаково хорошо мыслить/проектировать систему в двух принципиально разных идеологиях. За исключением явно выраженных случаев психических заболеваний типа раздвоения личности )))

а использовать акторы, если не умеешь в них мыслить... проще за день сотворить самопальную очередь сообщений и обменивать ими, сколько душе угодно... не втаскивая в проект ворох проблем которые идут с АККА в одной коробке, подарочным набором (сложность отладки, сложность обработки ошибок /скажи прощай эксепшенам/, совершенно отличные способы и ограниченный набор средств для оптимизации производительности и так далее)

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

IMHO.

p.s. ничего не имею против акторов как идеи, сам мыслить в них не умею, но и не встречал тех, кто бы умел. А проекты, классический ява программист + добавь немного АККА..... на мой взгляд смысл отсутствует полностью

Cheblin...

Один из фундаментальных компонентов распределенных систем - протокол обмена...
И разработчики AKKA предоставляют...

протокол обмена изначально НЕ гарантирующий доставки и обработки сообщений

Если человек может мыслить в идеологии: если выполнился модуль A, то следом может выполниться и модуль B... но может и не выполнятся - все хорошо

А если привык к обычным языкам программирования: если выполнилась строка 11, то следом выполнится строка 12 или произошло исключение - то все плохо ((( Т.к. результат использования АККА будет кучу распределенного гуана без обработки ошибок

IMHO

Ищущий Знания
Leonid Kudryavtsevпротокол обмена изначально НЕ гарантирующий доставки и обработки сообщений

Ни один протокол не гарантирует доставку (гуглить задача о двух генералах) и уж тем более протокол не может гарантировать обработку это вообще не его задача.

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

В AKKA afaik в большинстве случаев генерация ответного сообщения - на ответственности вызываемого модуля. Если забыли/не_получилось - ответного сообщения просто не будет. Вызывающий модуль может ждать ответа до следующего ребута системы.

Про автоматическое отслеживание [например таймаут] на уровне библиотеки и говорить не стоит. Нет его.

Ищущий ЗнанияКакие модули, какие строки, хоспади? Это обычная асинхронная обработка, как в любых других языках.
См. выше.

В нормальной Java или гарантированна обработка или гарантирован эксепшен. В AKKA - нет.

Или ВСЕ вызовы через AKKA нужно обрамлять своим кодом отслеживающих ошибок или говорить об обработки ошибок вообще не приходится. Но если обрамлять ВСЕ - то тогда нафига оно вообще нужно?

Ну и синтаксис стандартных exception в AKKA afaik полностью убит, что тоже не делает обработку ошибок простой задачей.

Насчет обычной асинхронной обработки - асинхронная обработка в обычных приложениях, вещь совершенно НЕ обычная и обычно инкапсулирована ))) в отдельном небольшом модуле/программном коде. Где, ясное дело, с теми же проблемами иногда приходится сталкиваться. НО в отдельно взятом модуле. Если же пользоваться AKKA, то это нужно делать и держать в голове всегда и везде.

===

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

Но в принципе, imho любое убийство актора автоматом приводит к данной проблеме. Т.ч. получаем нормальное средство программирование, где создать актор можно без проблем, а вот корректно убить его, крайне тяжело.

Со стороны пославшего не легче. Даже если пославший модуль определит наступление timeout'у, у него нет никаких возможностей повлиять [terminate] на обработку созданных им сообщений. Да и просто понять, в каких акторах сейчас происходит обработка которую он инициировал.

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

afaik Возможно я что-то не знаю.