我在IIS中托管工作流服务(xamlx)。它有一些接收活动,例如MethodA和MethodB。我写了一个MVC应用程序作为客户端来调用这些方法。在PageA中,用户提交表单将调用MethodA,工作流将转到等待MethodB的Receive Activity。然后在页面B中,用户提交表单将调用MethodB。但是,如果用户在PageA中提交然后返回到PageA并再次为同一工作流实例提交,它将等待一分钟并给出超时异常:
请求频道在等待回复后超时 00:01:00。增加传递给Request或者调用的超时值 增加Binding上的SendTimeout值。分配给的时间 此操作可能是较长超时的一部分。
此错误似乎来自WCF,而我认为它会产生以下错误:
InstancePersistenceCommand的执行被中断了,因为 实例键'guid'未与实例关联。这个可以 因为实例或密钥已被清理,或因为 密钥无效。如果生成消息,密钥可能无效 from是在错误的时间发送或包含不正确的相关性 数据
我有几个问题:
我们可以设置任何配置,以便可以捕获另一个异常而不是等待一段时间才能捕获到超时异常吗?我知道我们可以在绑定标记中设置一个较小的超时值,但它不应该是一个解决方案。
当工作流实例未处于正确状态时,有没有办法避免显示PageA? (即使这样做了,我们还需要解决问题1,因为用户可以在提交之前打开PageA并闲置一段时间)
感谢。
答案 0 :(得分:3)
Re:超时异常。
这是WF4中的已知错误。这是因为WF / WCF基础设施将尝试传递消息。这意味着它会暂停一下消息并查看工作流是否处于可以处理消息的状态。基础结构并不真正了解工作流的结构。因此,即使您完全意识到工作流处于一种状态,即在给定当前状态的情况下,它永远无法处理消息,基础结构将等待。
回复:避免显示PageA。
这完全取决于UI层和工作流范围之外。正如你所指出的那样,并非完全可以避免。但是,我在使用持久性存储中的书签信息方面取得了很大成功。每个Receive活动创建一个具有已知名称的书签,我基本上检查了那里的书签。根据这些信息,我将启用/禁用部分UI。它不能真正解决用户打开页面并将其保留15分钟的问题,因此在调用服务方法时仍需要错误处理程序。改进的一种方法是,假设HTML基于UI一段时间,使用WebSockets或SignalR更实用,并将工作流状态更改从服务器推送到客户端。仍然不会消除错误处理的需要,但应该使UI处于错误状态的窗口小得多。
答案 1 :(得分:0)
由于我遇到了类似的问题,我想在Maurice's answer的超时部分提供一些背景信息。
该信息来自this Microsoft forum thread上Jim Carley的一篇文章。遗憾的是,不支持直接链接到该帖子 - 搜索"协议书签"。我将在这里总结一下重要的部分。
当收到操作消息且操作没有协议书签时,工作流基础结构会检查工作流实例是否有任何未完成的非协议书签。
以下活动都会创建内部书签,因此在与Receive活动和无序消息传递混合时会导致超时问题:
对于Pick,可能的解决方法是将Parallel with CompletionCondition设置为true
。