Этот вопрос является продолжением предыдущей темы.
Хранение токенов отмены в сервисах сервисной фабрики
Открыл новую ветку, потому что отвечать на этот вопрос не будет тривиальным.
Подводя итог тому, что обсуждалось в отношении отмены задания / задачи, выполняемой в конкретной службе в некотором разделе фабричной службы:
Ограничение токена аннулирования:
Токен отмены работает в служебном разделе, и это является ограничением при хранении экземпляров по частям, вероятно, причина, по которой токен отмены не снабжен сериализуемыми атрибутами (попытка была сделана с использованием ISerializationSurrogate для сериализации в байтовый массив и сохранена в классе с помощью Атрибут DataContract присоединен, и он теряет все вложенные данные структуры при десериализации обратно.), Поэтому надежный словарь не может быть использован.
Два разных использования токенов отмены в приложении сервисной фабрики:
- Предоставлена Service Fabric, которая изначально внедряется в такие методы, как RunAsync (CancellationToken) {цикл навсегда} или используется дескриптором запроса отмены Web API, который также может перенаправляться пользовательским методам в субъекте / службе для вызовов веб-API.
- Сгенерированные пользователем токены отмены должны управляться иначе, чем те, которые создаются # 1 (Более подробное описание того, как управлять этими токенами, относится к предыдущему потоку, связанному в верхней части этого потока).
Вопрос к этой теме:
Как переадресовать запрос API, полученный через конечные точки нескольких разделов, на нужный раздел? Я полагаю, что как только запрос был переадресован с конечной точки Web API на правильный раздел, тогда, кажется, все это имеет смысл, потому что в этот момент вы должны просто иметь возможность вызывать cancellationtokensource.cancel () с сохраненным токеном отмены в этом конкретном разделе, при условии, что что cancellationtoken.Cancel () работает по разделам.