2011-07-05 77 views
3

我有一個有點不尋常的場景,我需要能夠徹底屠殺「掛」,自我託管WorkflowInstance的超過給定的超時閾值。我嘗試了Abort(),Terminate()Cancel()方法,但這些都太「好」了。它們在被授予之前似乎都需要來自WorkflowInstance的響應。如何強制終止WorkflowInstance?

在我的方案中,工作流進入無限循環,因此無響應。由於工作流程完全沒有響應,所以調用上面提到的常規方法會很簡單。我很驚訝地得知WorkflowRuntime沒有出現處理這種情況的機制,或者Abort()Terminate()僅僅是建議而不是暴力指令。

我搜索谷歌/ MSDN/stackoverflow /等試圖找出當Terminate()乾脆不會完成工作,幹得不好。我考慮創建自己的基本活動,並給它一個超時值,這樣,如果其「子」活動的一個子活動掛起,它可以自行終止活動。這種方法好像我會用大錘敲打蒼蠅......

有沒有我忽略的技術?

回答

1

唯一的真正的解決方案是考慮這個錯誤,修正出錯的地方,並考慮此事關閉。

強制中止任意被鎖定在無限循環中的代碼的唯一方法是在線程上調用Abort()。當然,這被認爲是不好的,只有在通話結束後才能確保應用程序的狀態時才能進行。

所以,你必須提供WorkflowApplication你寫它可以線程工作流Post() s到上調用Abort()SynchronizationContext的實現。

+0

它被允許執行的事實的確是一個真正問題的徵兆,這是一個錯誤,它已經把它變成了一個它從未實現過的環境。同意,也是本週與我的團隊討論的主題......我希望提供某種故障安全方式,如果這種代碼在將來以某種方式使其脫離開發環境,除了改進代碼推廣過程,這對於一個全新的問題本身來說可能就足夠了。我想避免對線程本身進行處理,但這可能就是這樣。 –

+0

此外,這很有可能成爲答案,就像我不希望它成爲......我並沒有停下來想它是一個直線線程問題。我希望利用WorkflowRuntime的一些管道來爲我完成繁重的工作。保持它開放一點,看是否可以追求任何其他角度,但不幸的是,這可能是無效的。 –

0

我不確定這是否會工作,但您是否嘗試過WorkflowInstance.TryUnload()函數?我記得這是爲了在工作流程內激發一些事件(自從我這麼做以來已經有一段時間了),所以你可能能夠在你的工作流程中有一個事件處理程序來捕獲這個事件,並對其自身執行kill命令。