AppFabric託管工作流並不總是在延遲/卸載後重新加載

我有一個WCF Windows工作流（4.5）工作流服務託管在IIS和使用AppFabric 1.1。工作流程實例長時間運行（長達大約一週），但大部分時間都用於延遲活動。AppFabric託管工作流並不總是在延遲/卸載後重新加載

這似乎一開始工作正常，但是當同時運行多個工作流實例（2 +個實例導致這種情況）時，其中一些只是在延遲步驟中從內存卸載後纔會喚醒。當我查看日誌，我發現所有的錯誤是這樣的：

   System.OperationCanceledException: The execution of InstancePersistenceCommands has been canceled because the InstanceHandle was freed. 
      at System.Runtime.AsyncResult.End[TAsyncResult](IAsyncResult result) 
      at System.ServiceModel.Activities.Dispatcher.DurableInstanceManager.WaitAndHandleStoreEventsCallback(IAsyncResult result)

不幸的是，我沒有找到該錯誤消息的任何有用的信息。

AppFabric Persisted Instances Table中的SuspensionExceptionName和SuspensionReason字段顯示System.NullReferenceException：未將對象引用設置爲對象的實例。但是這不會發生在我的工作流程內，只在外面。

附加信息：

我跑活動作爲消防&忘記（接收活動，沒有發送）
我的工作流程調用到其他WCF服務來獲取數據。
我在Server 2012 R2上運行IIS 8（不是天藍色）
Workflow Persistence正在工作。我可以重置IIS，重啓......當我運行2個實例時，它有問題。
我絕對沒有遇到任何類型的限制。雖然工作流程處理幾MB的數據，但這個問題發生在2+實例。

任何想法可能發生在這裏？

編輯：我意識到我發現了更多關於問題如何運作的信息，並且從未將它添加到問題中。當延遲問題發生時，它的運行很像一個由2個線程寫入的靜態變量。

這裏有一個可視化：

WF1 Start ---->Do Stuff--->Sleep------------*1----->Cancelled Exception at some point 

------WF 2 Start---->Do Stuff------->Sleep->Wake up---------*2------>More Stuff---->End Successfully 

*1 - When WF Instance 1 Should Wake up (Same time as WF 2 wakes) 

*2 - When WF Instance 2 Should have woken up (Seems to be ignored)

之前有人問......我在我的代碼去掉每一個靜態變量，方法，類的。沒有什麼是靜止的了。

來源

2015-03-25 ChrisG

我一直在類似的問題掙扎了很長一段時間。我使用WFW4，當工作流實例處於長時間延遲時，我發現類似的錯誤。

我不知道問題的原因是什麼，但我有一個解決方法，您可能會發現有幫助。

在我的情況下，我得到的錯誤來自工作流管理服務，並且說：無法在'net.pipe：//.svc'處調用服務管理端點以激活服務'/Arts/Workflows/.xamlx' 。例外：「訪問被拒絕」。

這些錯誤在實例進入長時間延遲後的6到30小時之間的某個時間開始發生。

我發現如果在第一個實例處於延遲並且發生錯誤時創建了工作流的新實例，那麼Workflow Management Service將能夠恢復與第一個睡眠實例的交互。

因此，我製作了一個新的工作流程，其唯一目的是定期啓動並終止包含長時間延遲的工作流程實例。

這實際上讓這項工作變得更復雜一點。我希望這個新的工作流程能夠在創建並殺死第一個工作流程的新實例時進入休眠狀態。但是，這種睡眠會導致新工作流程的實例遭受與第一個工作流程相同的問題。因此，我修改了新的工作流程，以便執行以下操作： - 延遲一段相當短的時間，例如30分鐘 - 創建第一個工作流程的實例 - 等待一分鐘 - 第一個工作流的創建的實例 - 創建這個新的錯誤，防止工作流程的新實例 - 終止

由於在做這件事，我不再工作流管理服務獲得訪問被拒絕的錯誤！

希望這有助於

來源

2015-04-02 16:59:53 hanksterr7

感謝您的回答！這聽起來像一個與我有什麼不同的問題（我的問題只會在多個實例出現時纔會發生，並且更像靜態變量被線程覆蓋，一個在錯誤的時間喚醒，另一個不會喚醒...）但是我會記住長時間的延遲。 – ChrisG 2015-04-02 17:55:58

原來我的第一個答案是不正確的，但我相信這個答案是正確的，並解決ChrisG是有問題的。

我的解決方法實際上並不奏效。花了一段時間才解決了這個問題。精確到29小時 - 應用程序池回收所需的默認時間。

所以對我來說，解決方案是讓我的應用程序池不回收。如果應用程序池在工作流實例處於延遲活動狀態時進行回收，則工作流ManagementManagementService無法喚醒實例並引發訪問被拒絕錯誤。如果您在應用程序池回收後創建工作流程的新實例，那麼第一個實例將從停止的位置繼續，但有時仍然存在問題，這是我認爲正在發生的問題。

ChrisG，看着你的視覺效果，appPool可能在wf1睡覺的時候回收？我認爲這是個例外。如果您在* 2通過後啓動了一個新的wf實例（並且在* 1之前發生了應用程序池回收），則會喚醒wf1和wf2，但wf1無法正常工作（至少在我的經驗中）

此外，這發生在iisresets和服務器重啓之後。要處理這些問題，您需要使用IIS7，它允許承載xamlx文件的Web應用程序（以及網站）在iisreset或服務器重新啓動後自動啓動。該選項在IIS6中不可用。詳情請見http://www.postseek.com/meta/991815402b369e71ce925cde47ac907d

希望能幫到你！

來源

2015-04-06 13:39:23 hanksterr7

AppFabric託管工作流並不總是在延遲/卸載後重新加載

回答

相關問題