ни в коем случае! акторреф при стоп/старте меняется. Акторселекшн вечный

Ты это гарантируешь или просто когда-то запомнил и более не юзал?

Блъ.

А шо? По-моему это в доке жЫрным выделено

А шо? По-моему это в доке жЫрным выделено

Хде? Я видимо пропустил.

Как лучше сделать. Если надо создавать акторов в динамике и так же их удалять, делать это через актора диспетчера который будет заведовать лайфтаймом акторов. например - кто-то посылает NewUserChat сообщение в систему. Актора под такого юзера нет, поэтому у нас есть актор UserChatsDispatcher через которого проходят все сообщения для UserChat акторов. Он видит что такого актора нет, создаёт его и роутит сообщение туда. Он в себе держит все ActorRef чтобы их убивать при необходимости. Таким образом мы не получим потери сообщений и не надо ресолвить каждый раз все акторселекшны

Хде? Я видимо пропустил.

Я думал у меня акторы будут вечными :)

Хде? Я видимо пропустил.

В стейте Dispatcher'a хранить Map<int64, IActorRef>?

жырным не выделено https://getakka.net/articles/actors/receive-actor-api.html#actor-lifecycle An IActorRef always represents an incarnation (path and UID) not just a given path. Therefore if an actor is stopped and a new one with the same name is created an IActorRef of the old incarnation will not point to the new one.

Но персистентный актор переродится по той же ссылке?

Dictionary только

Так быстрее будет из-за мутабельности?

И ещё, если я буду персистентность делать, получается диспетчер не должен быть персистентным?

не вижу ни одной причины чтобы это было так

Вроде бы когда он падает, он респавнится самостоятельно и воспроизводит все ивенты. Я предполагал, что это происходит без полноценного пересоздания актора.

Но персистентный актор переродится по той же ссылке?

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

Если вам надо сделать формочку, то берите жаву. Если вам надо разобраться в с++, то берите с++)

Ну значит в правильном иду направлении :)

Ребят, орлианс это условная жава, а акка это условный с++

А я думал, что орлинс это WCF

воспроизводится цепочка событий, реакция на которые прописана в акторе События - персистентнты. реакция - нет. Соответственно стейт который получится в результате фолда всех реакций на стрим евентов может быть разный! (это бонус)

Ну значит в правильном иду направлении :)

мне казалось ты про цепи Маркова говорил

А снэпшот нужен лишь для того, чтобы не воспроизводить всю цепочку, а лишь часть?

Только в орлианс

Да не совсем так. Можно считать, что в орлеанс у актора есть супервизор по умолчанию. И им нельзя управлять. А в акке супевизор детерминированный, и насколько я понимаю имнно ему принадлежит mailbox дочернего актора.

Нет

Там, разве не интерфейсы с кучей async-методов?

Похоже на WCF

Тем что там один метод, который принимает Msg и там патерн-матчит его - наверное да, но я не специалист

в смысле интерфейс между клиентом/сервером

Нет - это просто match переписаный на интерфейс. Внутри все так же. И grains общаются друг с другом через GrainRefernces

Я про WCF, я с орлинсом плохо знаком

А вот сримов, как в акка в нем нет. И порог входа там ниже.

я всё хотел изучить из-за нативной поддержки грейнов в ажурном облаке. Но вот после ажурных функций на F# чот больше нет надобности

Не считая того, что орлеанс быстрее 😊 И в простых случаях удобнее

https://github.com/AkkaNetContrib/Home/issues/24