Comments 10
1) в мастеровом DoJobCommandHandler:
groupActor.Forward(doJobCommand); _groupIdToActor.Add(doJobCommand.GroupName, groupActor); _actorToGroupId.Add(groupActor, doJobCommand.GroupName);
Почему сначала вызывается метод Forward, а потом актор добавляется в словари? Методологически надо наоборот, а вызывать Forward вообще один раз для обеих ветвей (новый актор или старый).
2) в Итоге впервые, без объяснений встречается слово akka. Надо в начале хотя бы в одном предложении заметить, что показана работа библиотеки akka.
3) хорошо бы добавить обратные уведомления о прогрессе (проценте) выполненной задачи.
@dyadyaSerezha, 3 ий пункт выглядит, как очень даже интересная функциональность
Постановка задачи непонятна.
Чего хотели добиться то?
Чтобы просто запустить кучу задач и знать статус их выполнения, достаточно сделать нужное количество Task.Run(...) и смотреть, не completed ли каждая нужная из них. Положите в структуру\класс, для того чтобы поименовать или как-то ещё отметить.
@MonkAlex, добрый день, задача состоит в создании интерфейса IJobContext, имплементация которого для метода DoAsync абстрагирует работу со скоупом Di, определит стратегию перезапуска задачи, в нужное время (StopAsync) самостоятельно отменит CancellationTokenSource и даст возможность получить нетолько результат работы задачи, но и в момент ее выполнения даст возможность обращаться к ее текущему состоянию. Голый таск ран вполне может быть использован для некоторых отдельных функций из списка выше, но для всех разом - это уже будет какая-то другая имплементация требуемого списка функциональности из IJobContext не акке, а на таск ране
Не всё понял в вашем ответе, но поясню, к чему был мой вопрос. Когда вы пишите статью, очень неплохо для начала объяснить, какие задачи решаете. Т.е. пояснить, что вот есть задача А, со своими особенностями. И вот такой инструмент как Б, позволяет написав вот такой код, получить нужный результат.
А вашу статю я читаю как "вот есть такой код, который позволяет получить что-то". В конце упомянута акка, что добавило мне понимания. Но всё ещё неясно, какую изначально задачу решаем.
Отдельно отмечу, что акка - это обычно что-то на тему concurrent & distributed, что в статье не вижу, может пропустил.
Чего хотели добиться то?
Я так понял, что тут хотели показать примеры работы с каким-то фреймворком для подобных задач, но, как-то явно про это не написали, только ссылка в конце статьи.
Общая схема запросов будет выглядеть как MasterActor→ GroupActor → ManagerActor → WorkerActor
Это оверинжиниринг, на мой взгляд. Ещё и акторы зачем-то.
В .net есть BackgroundService и всё сводится к 3м сервисам:
Общая очередь (можно в памяти, синглтон или статик ConcurrentQueue) с данными для таски
BackgroundService который смотрит эту очередь и запускает таску
Сервис с бизнес-логикой самой таски. Паттерн стратегия.
@RouR , согласен, если просто фономо нужно что-то запустить, то BackgroundService - отличное решение
Чтобы просто фоном запустить что-нибудь достаточно Task.Run, чтобы передать команду на завершение - передать в исполняемый через делегат метод CancellationToken а в коде метода - смотреть, что он не отменен, чтобы отслеживать custom-состояние - сделать в классе volatile поле (с доступом снаружи к нему напрямую или через свойство), имеющее тип, обновления которого атомарны (т.е., грубо говоря - не struct) и писать туда из метода состояние по мере выполнения - и так далее, по мере усложнения задачи.
Так что присоединяюсь к мнению@MonkAlex: код из вашей статьи решает не приведенную в начале текста простую задачу, а гораздо более сложную.
Создание фоновых задач в .NET с запросом состояния запущенного таска