Помойка, да. Я старался этой помойкой не пользоваться. Это как в C# везде dynamic пользоваться. Чувствуешь себя богом в компайл тайме пока не выходишь в рантайм. Евентстрим такая же фигня. Кажется хорошей вещью, но

но помойка)

Я там логи гонял кастомные и технические сообщения

Значит, буду продумывать структуру, что с чем должно взаимодействовать

Теоретически можно поднять отдельную актор систему и соединить их друг с другом. У каждой актор системы будут свои евент стримы

Но лучше так не делать

Значит, буду продумывать структуру, что с чем должно взаимодействовать

это же самое интересное в акке

Вот и я о том

ПОходу, тут кода много не надо писать, а надо много думать

да, и это здорово

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

И все же в акке смущает, то что сообщение может не дойти, а хэндлить это надо через прослушивание dead letters

ПОка не могу понять, как от аска избавиться

ВОт есть соединение с сервером

В теории это отдельный актор, который дает коннекшн агенту

Есть актор, который отправляет и получает сообщения

А, я понял

Есть актор, который отправляет и получает сообщения

тебе транзакционность нужна?

Ептыть

В верхнем акторе вводится месседж, который менеджит стейт

тебе транзакционность нужна?

Транзакционность лесом

ПОка не могу понять, как от аска избавиться

Актор А отправляет сообщение ЗАПРОС Актору Б и переходит в сосотяние ОЖИДАНИЯ, в котором он принимает только сообщения вида ОТВЕТ. Все остальные, например, игнорит, или стешит. Тебе решать. Но главное что он на них реагирует! (а не висит на аске). Актор Б получает сообщение ЗАПРОС, и формирует ОТВЕТ, который засылает обратно по адресу Sender. Актор А который всё это время был доступен получает ОТВЕТ, реагирует на него и переходит обратно в состояние АКТИВЕН, в котором сообщения обрабатываются обычным образом. Ранее принятые сообщения (в режиме ожидания) если он их сташил, можно вывалить в мейлбокс и таки обработать, а можно новых подождать

Не понимаю в чем сложность. Актор который отправляет запрос на данные ожидает получения сообщения с ответом. Актор который отвечает за бд получает сообщение с запросом, идёт в бд и отправляет сендеру новое сообщение с ответом (которое ожидает сендер).

А, да, вот Ayrat выше все подробнее описал

Сложность в том, чтобы это осознать

А так все ок

Во время режима ожидания можно на все вопросы отвечать сендерам "занято, идите нахер".

Кстати, в akka.fsharp become есть?

Это очень круто когда у тебя есть гигантский кластер доменной логики и ты на любой запрос вместо мучительных ожиданий (а если ты наговнокодил всё на ask, то могут быть глубокая вложенность этих асков), сразу получаешь вменяемый результат, например - БД занята, или там - нехватает бабок, или ещё что

Кстати, в akka.fsharp become есть?

ага, верни другую функцию в LOOP ()

А, ну так и делаю

В общем-то

ну для ФП это и есть оно.

Become это костыль для ООП

у нас вот большая акка хрень на любой запрос давала за 20мс ответ. Мы метриками всё обвешали и ни один мессадж от входа до выхода не жил более 20мс. В начале у нас было много ask, потом ловили проблемы неполучения ответов, потом повешали таймауты, стали ловить сраные таймауты, потом мы нашли все аски и выжгли их огнемётом. Система моментально стала офигенной.

Кстати, в akka.fsharp become есть?

В Akkling есть.

https://github.com/Horusiath/Akkling/blob/master/examples/basic.fsx#L66-L69

Это видел

В акклинге настораживает то, что придется много кода читать

Исходного

Его там немного.

Его там немного.

Кода нет? ?

В акклинге настораживает то, что придется много кода читать

Зато ActorRef<'T>!

так вроде ж несложно обернуть ActorReft в какой-нибудь TypedActorRef<'T>

так вроде ж несложно обернуть ActorReft в какой-нибудь TypedActorRef<'T>

А зачем, если в Akkling уже сделали? ?

А зачем, если в Akkling уже сделали? ?

разумно :)

не за чем

Чет не пойму, как в один актор засунуть несколько типов месседжей

Через ?: ?

В оригинале так и делается. Но можно DU, ща

в оригинале это в смысле сама AkkaNet

А если без DU

Если без DU, то только кастом конечно же

А чем тебя DU не устраивает?

Я ща пытаюсь понять, как мне, например, стейты менеджить

замыканиями, let actor ... = let mutable state ... = let loop () = actor { ... // здесь принимаем месаджи, меняем state } loop () можно так. в mutable нет ничего страшного, т.к. актор синхронный. Если не хочется mutable , пихай стейт в аргументы loop

У меня получается что-то вроде Repository=|Init|Find|FindOne|Update

Как в akka.fsharp прописать beforeStart?

Типа создание и посылка месседжа передвозвратом ссылки на актор?

Как в akka.fsharp прописать beforeStart?

насколько я знаю никак.

Пичалька

Придется вводить фейковую инит функцию

Придется вводить фейковую инит функцию

зачем? Ты же можешь начинать актор в статусе init, там делат ьвсе что нудно и переводить актор в статус working например

Ну вообще всяких там onRestart и PostStop евентов в F# акке не хватает.

Если чо, в F# всегда можно по-старинке сделать type ... = inherit ActorBase и т.д.

Так неинтересно, но, возможно, придется

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

Как и зачем тебе могли потребоваться обычные мейлбоксы??

Ну стейты хранить, синхронизировать доступ

Чем акковский мейлбокс отличается от F#??? это та же очередь + рекурсивная функция обработки.

И там, и там стейт делается одинаково

не понимаю

Смотри

Есть следующий сценарий

Из внешнего канала запрашивается список с некоторой контрольной суммой

Если контрольная сумма совпала, нам придет пустая коллекция, и ничего не надо делать

Если нет, то надо обновить коллекцию в базе

Тем, что пришло

Допустим

Контрольные суммы для разных типов хранятся в отдельном репозитории

Точнее, в моей случае в отдельной коллекции dblit

dblite

litedb

очень допустим

Вот вопрос, как это в акторы засунуть

Так же как в мейлбоксы?)

Ну т.е. серьёзно, почему ты не можешь сделать так же

Там у меня есть PostASync

ну а тут Send

неблокирующий

Тьфу, PostAndREply

ну а тут mailbox.Context.Sender

mailbox.Context.Sender.Tell ReponseMessage

ты всегда знаешь кто тебе прислал конкретный мессадж

Теперь у меня следующие шаги:

1. ПОлучить crc для конкретного типа из базы 2. Отправить серверу сообщение 3. На основании ответа сервера обновить crc\коллекцию определенного типа в базе

Получается, что мне нужно делать последовательное flow из акторов

Да, и это нормально

Акторы для опроса бд, акторы с логикой, акторы роутеры и т.д.