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托管工作流并不总是在延迟/卸载后重新加载

回答

相关问题