У меня есть несколько необычный сценарий, когда мне нужно иметь возможность прямого забоя "зависших", самостоятельно размещенных WorkflowInstance
после заданного порога времени ожидания.Я попробовал методы Abort()
, Terminate()
и Cancel()
, но все они слишком "хороши".Кажется, что все они требуют ответа от WorkflowInstance, прежде чем их соблюдают.
В моем сценарии рабочий процесс вошел в бесконечный цикл и поэтому не отвечает.Вызовы обычных методов, упомянутых выше, будут просто зависать, поскольку рабочий процесс полностью не отвечает.Я был удивлен, узнав, что WorkflowRuntime
, похоже, не имеет механизма для работы с этим сценарием, или что Abort()
и Terminate()
являются просто предложениями, а не насильственными директивами.
Я искал google / msdn/ stackoverflow / etc пытается выяснить, что делать, когда Terminate()
просто не справится с работой и не справится.Я подумал о создании собственной базовой активности и присвоении ей значения тайм-аута, чтобы моя «корневая» активность могла убить себя, если одно из ее дочерних действий зависнет.Похоже, что при таком подходе я буду бить кувалдой по мухам ...
Есть ли техника, которую я пропустил?