Вот как выглядит актор для опроса бд, интересно

получил доменный месадж, замапил его в SqlCommand, вызвал асинхронный запрос БД, вошёл в состояние - "отъебитесь, я занят", задаче на вызов бд в колбек повесил отправку себе пробуждающего сообщения, которое иницирует посылку ответа

Посылку кому, вот в чем вопрос

context.Sender

ВОзможно тебе стоит почитать про Акку)

Что сендеру, понятно

Тогда непонятно что тебе непонятно

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

Ну вот есть у меня некий CheckStateActor, который должен выполнить n шагов

У каждого шага разные типы сообщений

Которые актор принимает\посылает

Назови его DbActor, который владеет конектом к БД. Допустим принимает месаджи Create Id, Delete Id Вот он принял Create 123, забацал из него INSERT INTO ... VALUES (123) вызвал conn.ExecuteAsync command подождал асинхронно, отправил отве сендеру

это если ты хочешь побыстрее закодить, но обработка сообщений заблочится

в твоём случае это может быть некритично

У меня не sql, но это неважно

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

т.е. будет типа actor { let! msg = mailbox.Receive() match msg with | Create x -> let sqlCommand = ... let! response = connection.ExecuteAsync sqlCommand context.Sender.Tell response | Delete id -> ...

Это я понимаб

ПОнимаю

Тут вопросов нет

Тогда я уже что-то явно не понимаю)

По факту я сначала должен получить crc

Из одного актора

Перейти в стейт отправки сообщения

Отправить сообщение в другой актор

Обработать ответ

Окей, есть такой паттерн в ынтерпрайзых - saga, он же процесс манагер, Сделай актора отвечающего за шаги логики и инфраструктурных, тупых

один инфраструктурный всегда опрашивает crc, другой умеет с БД, третий логи в эластик складывать

актор за логику пусть ведёт какой-то процесс (конкретный или глобальный это я уж хз) и да у него будут стейты шаги, где он будет по очереди спрашивать чо как у других акторов

А как он будет от них ответы получать, если без ask?

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

Таааак

Теперь вопрос

Как это все внутрь одного актора засунуть?

т.е. в одном состоянии мы реагируем только на месадж CrcResponse, а в другом уже на DbResponce

в DU запихни и всё

Это подводит к необходимости создания акторов - конвертеров сообщений

состояния вынеси в несколько рекурсивных функций типа let waitingForCrcLoop () = actor{ let! msg = receive match msg | CrcResponce resp -> return! processResponseLoop resp | _ -> return () }

и кидайся этими функциями туда сюда чтобы ходить по стейтам

processResponseLoop тоже actor возвращает?

ага

О чем-то таком я думал, да

Там же надо мейлокс прокидывать в параметры функции, так?

мейлбокс

при этом стейт между этими лупами можно просто в общее замыкание мутабельное повесить, let mutable state = ... let startLoop() = actor { ... } let loopTwo() = actor { ... } let finishLoop() = actor { ... } startLoop()

не, ты можешь это делать в общей функции let createSuperActor mailbox = let mutable state = ... le t startLoop() = actor { ... } let loopTwo() = actor { ... } let finishLoop() = actor { ... } startLoop()

А, точно

это всё будет один актор с тремя состояниями и общим шаред стейтом, который можно смело делать мутабельным и не трахать себе мозги перекидыванием в ФП стиле этого стейта по функциям

Да, так сработает

Выхожу на новый уровень :)

стикер ужасен)

В скале это в тыщу раз лучше выглядит

Aether.lenses

Ну да, знаю. Но там тоже надо обмазать этот рекорд тайп линзами

Я к тому что в скале есть языковая поддержка для линзового синтаксиса

Кстати

Как мне гарантированно перейти в стейт прослушивания дочернего актора до отправки ему сообщения,ответ на которое я хочу слушать?

А какая разница?

Ну разница в том , что в теории я могу отправленное сообщение потерять

Т.к. принимающий актор будет не в том стейте

Отправляю сообщение из одного стейта, слушаю в другом

Можно пример, я пока не понял

Это понятно

Т.е. стейт я переключаю не при приеме ответа

при отправке, да

А при отправке tell

Я так понимаю, в данном случае поведение недетерменированно

Да)

Ну т.е. сообщение может упать в дед летерс и всё.

И молодая не узнает какой у парня был конец

Вот и я о том

И молодая не узнает какой у парня был конец

Вот это в акке и убивает. В орлианс у тебя будет exception.

Глянуть на орлианс,шоле

Хотя у него под f# ничего нет

Глянуть на орлианс,шоле

Не, к твоему кейсу не подойдёт. Ты как раз попадаешь в те 10% где нужна акка

Хотя у него под f# ничего нет

Orleannka

Ну и из коробки он тоже норм работает

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

Да это не проблема, хочешь детерминированности context. System.Sheduler.TellOnceCancellable себе зарядил на всякий случай и все.

Там акторы в облаке только.

Да это не проблема, хочешь детерминированности context. System.Sheduler.TellOnceCancellable себе зарядил на всякий случай и все.

Что даёт?

Ааа

Это если у тебя система с отказоустойчивостью овер 9000 нужна

Понял будет слать пока ты не ответишь что получил

Да это не проблема, хочешь детерминированности context. System.Sheduler.TellOnceCancellable себе зарядил на всякий случай и все.

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

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

А потом в орлианс появился eventsourcing и стало жить легко

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

Так это на каждое взаимодействие между акторами писать надо.

Да не надо же, только на ремоутинг.

Так у тебя и локально сообщения могут не дойти

Ну и если используешь cluster.sharding то там хз где локально где нет будет.

Актор пасы типизируешь и избавляешься от промахов по адресу. Всех акторов делаешь реактивными и избавляешься от таймаутов ин процесс

Актор пасы типизируешь и избавляешься от промахов по адресу. Всех акторов делаешь реактивными и избавляешься от таймаутов ин процесс

Не понял ни способа ни реализации)

Откуда ещё взяться отсутствию ответа?

Ток с работы ушёл, завтра гист скину.

Короче, чует мое сердце, что я ступил на охуенно тонкий лёд

Ок, буду благодаркн