Question

我有一个在IIS下托管并使用AppFabric 1.1的WCF Windows Workflow（4.5）工作流服务。工作流实例长时间运行（最多约一周），但大部分时间都花在Delay活动上。

这开始似乎工作得很好，但是当同时运行多个工作流实例时（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持久实例表中的SuspensionExceptionName和SuspensionReason字段显示System.NullReferenceException：未将对象引用设置为对象的实例。但这不会发生在我的工作流程中，只能在外面发生。

其他信息：

我正在以Fire＆amp; amp;忘记（接收活动，不发送）
我的工作流调用其他WCF服务来获取数据。
我在Server 2012 R2，IIS 8（非天蓝色）
工作流持久性正在发挥作用。我可以重置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)

在有人要求之前......我在代码中删除了所有静态变量，方法，类。没有什么是静止的了。

Answer 1

我一直在努力解决类似的问题。我使用WFW4，当工作流实例长时间延迟时，我发现类似的错误。

我不知道问题的原因是什么，但我有一个你可能会觉得有用的解决方法。

就我而言，我得到的错误来自Workflow Management Service，并说：无法在＆＃39; net.pipe：//.svc'上调用服务管理端点;激活服务＆＃39; /Alerts/Workflows/.xamlx'。例外：＆＃39;访问被拒绝。＆＃39;

这些错误在实例进入长时间延迟后的6到30小时内的某个时间开始发生。

我发现如果我在第一个实例处于延迟状态并且发生错误时创建工作流的新实例，那么工作流管理服务就能够恢复与第一个睡眠实例的交互。

所以，我创建了一个新的工作流程，其唯一目的是定期启动然后杀死包含长延迟的工作流实例。

实现这项工作实际上要复杂一些。我希望这个新的工作流程在它创建和杀死第一个工作流程的新实例之间也会进入休眠状态。但是这种情况会导致新工作流程的实例遇到与第一个工作流程相同的问题。所以，我修改了新的工作流程，因此它执行以下操作： - 延迟一段相当短的时间，例如30分钟 - 创建第一个工作流的实例 - 等一下 - 杀死刚创建的第一个工作流实例 - 创建此新的防错工作流的新实例 - 终止

自从完成此操作后，我不再从Workflow Management Service获得Access is Denied错误！

希望这有帮助

Answer 2

原来我的第一个答案不正确，但我相信这个答案是正确的，并解决了ChrisG所遇到的问题。

我的解决方法实际上并没有奏效。花了一段时间才重新浮出水面。准确地说是29个小时 - 应用程序池回收所需的默认时间。

所以对我来说，解决方案是让我的应用程序池不回收。当应用程序池在工作流实例处于延迟活动时进行回收时，workflowManagementService无法唤醒实例并抛出Access is Denied错误。如果您在应用程序池回收后创建工作流的新实例，则第一个实例将从中断处继续，但有时仍会出现问题，这就是我认为ChrisG正在发生的事情。

ChrisG，看着你的可视化，是否有可能在wf1睡觉的时候回收appPool？我相信那是异常的原因。如果你在* 2过后再启动一个新的wf实例（并且如果一个应用程序池回收发生在* 1之前），那将唤醒wf1和wf2，但是wf1不能正常工作（至少在我的经验）

此外，在iisresets和服务器重新启动后会发生这种情况。要处理这些问题，您需要使用IIS7，它允许托管xamlx文件的Web应用程序（以及网站）在iisreset或服务器重新启动后自动启动。 IIS6中不提供此选项。有关详细信息，请参阅http://www.postseek.com/meta/991815402b369e71ce925cde47ac907d

希望这有帮助！

延迟/卸载后，AppFabric托管工作流程并不总是重新加载

2 个答案: