токены аннулирования магазина в сервисных сервисах

Question

Я пытаюсь выполнить функцию отмены задач в сервисах с отслеживанием состояния сервисной структуры.

План использует маркер отмены для распространения уведомлений по связанным потокам / задачам.

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

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

Пожалуйста, помогите мне, что может быть хорошим решением для решения этой проблемы.

Обновление (Я не хотел создавать новый поток, теряющий некоторые важные контексты, упомянутые в этом обсуждении, поэтому обновление в этом посте.)

Подтверждено, что в приведенном ниже описании ссылки действительно показан надежный сервис, и методы-субъекты могут поддерживать маркер отмены.Тем не менее, типичный вариант использования - это получение запроса на отмену напрямую через веб-API с использованием таких пользовательских функций, как обновление клика, переход на другую страницу и т. Д. В таком сценарии одна и та же конечная точка должна получать запрос, в то время как предыдущий запрос http сохраняется с некоторымидолгое задание или застрял.Это не сценарий в этой теме.

По ссылке: https://blogs.msdn.microsoft.com/azureservicefabric/2016/02/23/service-fabric-sdk-v1-5-175-and-the-adoption-of-virtual-machine-scale-sets/

CancellationToken поддержка IService / IActor

Надежный сервис и надежный актерметоды теперь поддерживают токен отмены, который можно удалить с помощью ActorProxy и ServiceProxy, что позволяет реализовать совместное аннулирование.Клиенты, которые хотят отменить долгосрочную службу или метод субъекта, могут сигнализировать токен отмены, и это намерение отмены будет распространено на метод субъекта / службы.Затем этот метод может определить, когда остановить выполнение, посмотрев на состояние его аргумента токена отмены.

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

        public interface IPrimeNumberActorInterface : IActor
        {

            Task<ulong> FindNextPrimeNumberAsync
                (ulong previous, CancellationToken cancellationToken);

        }

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

Answer 1

CancellationToken & CancellationTokenSource не сериализуемы и не передаются через сервисные вызовы или репликацию данных в SF.Он может использоваться только для того, чтобы сообщить обработчику в том же процессе, что операция была отменена, и должен прекратить любую обработку или игнорировать любое продолжение в случае получения ответа.

Если вы хотите иметь возможность начать иЧтобы отменить операцию в другом сервисе, вы должны разделить операцию на два вызова.

• При первом создании будет сгенерирован идентификатор операции, который будет возвращен клиенту, и создайте CancellationTokenSource для этой операции для генерации.CancellationToken для передачи в Task \ Thread, работающий в фоновом режиме
• Второй получит и OperationID и определит, существует ли CancellationTokenSource, и отменит его, чтобы токен был предоставлен любой Task \ Threadможет остановить любую обработку, если она еще не завершена или отменена.

Вы можете просто сохранить ее как Dictionary<Guid, CancellationTokenSource> в процессе \ разделе, выполняющем задачу.

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

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