464条消息后，Workflow Service停止响应 [英] Workflow Service stops responding after 464 messages

问题描述

我在执行工作流程时遇到一个特殊的问题.
我已经尝试了所有我能想到的东西，现在需要一些想法.

I am having a peculiar issue while executing workflows.
I have tried everything I could think of and now need ideas.

这是我的配置:
1. WF4工作流服务(xamlx)托管在IIS 7中，并使用net.msmq/netMsmqBinding进行传输(MSMQ是事务性的).
2.不使用工作流持久性.
3.我使用控制台应用程序客户端将消息发送到工作流(每条消息都会创建新的工作流). 4.每个工作流程如下:等待START消息->等待END消息(我仅发送START消息).

Here is my configuration:
1. A WF4 Workflow Service (xamlx) hosted in IIS 7 and uses net.msmq/netMsmqBinding for transport (MSMQ is transactional).
2. No Workflow Persistence is used.
3. I use a console app client to send messages to the workflow (each message creates new workflow). 4. Each workflow looks like: Wait for START message -> Wait for END message (I only send START messages).

如果我发送500条消息-464被正确处理，但在此之上，所有消息都进入lock_ *队列，然后移至中毒队列. 我已经检查了调试，分析事件日志以及消息和跟踪svclog 这是我得到的最详细的消息:

If I send 500 messages - 464 get processed correctly, but above that all messages go to the lock_* queue and then move to poison queue. I have inspected Debug, Analytic event logs, as well as messages and trace svclogs Here is most detailed message I get:

System.TimeoutException，mscorlib， 版本= 4.0.0.0，文化=中性， PublicKeyToken = b77a5c561934e089操作 未在指定的00:00:30超时内完成.时间 分配给此操作的时间可能更长 暂停.在 System.Runtime.AsyncResult.End [TAsyncResult](IAsyncResult结果)位于 System.ServiceModel.Activities.Dispatcher.PersistenceProviderDirectory.LoadOrCreateAsyncResult.HandleReserveThrottle(IAsyncResult 结果) System.Runtime.AsyncResult.AsyncCompletionWrapperCallback(IAsyncResult result)System.TimeoutException: 在指定的00:00:30超时内操作未完成. 分配给此操作的时间可能是 超时时间更长.在 System.Runtime.AsyncResult.End [TAsyncResult](IAsyncResult结果)位于 System.ServiceModel.Activities.Dispatcher.PersistenceProviderDirectory.LoadOrCreateAsyncResult.HandleReserveThrottle(IAsyncResult 结果) System.Runtime.AsyncResult.AsyncCompletionWrapperCallback(IAsyncResult 结果)

System.TimeoutException, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089The operation did not complete within the allotted timeout of 00:00:30. The time allotted to this operation may have been a portion of a longer timeout. at System.Runtime.AsyncResult.End[TAsyncResult](IAsyncResult result) at System.ServiceModel.Activities.Dispatcher.PersistenceProviderDirectory.LoadOrCreateAsyncResult.HandleReserveThrottle(IAsyncResult result) at System.Runtime.AsyncResult.AsyncCompletionWrapperCallback(IAsyncResult result)System.TimeoutException: The operation did not complete within the allotted timeout of 00:00:30. The time allotted to this operation may have been a portion of a longer timeout. at System.Runtime.AsyncResult.End[TAsyncResult](IAsyncResult result) at System.ServiceModel.Activities.Dispatcher.PersistenceProviderDirectory.LoadOrCreateAsyncResult.HandleReserveThrottle(IAsyncResult result) at System.Runtime.AsyncResult.AsyncCompletionWrapperCallback(IAsyncResult result)

此时

向http://localhost/MyWebService?wsdl的请求也失败，并显示404.

at that point request to http://localhost/MyWebService?wsdl also fails with 404.

如果我重新启动IIS，一切将恢复正常，直到发送464条消息为止.

If I restart IIS - everything goes back to normal until 464 messages are sent.

1. 在哪里可以找到更详细的日志? (我已经将System.Diagnostics设置为最大详细程度)
2. 464号真的是魔术吗?
3. 什么原因导致此Web服务被锁定?

推荐答案

听起来您正在遇到节流限制，这些设置对WF4的适用性与对WCF的适用性一样. maxConcurrentInstances设置设置在给定时间可以在内存中的工作流实例的最大数量.

It sounds like you are running into the throttling limits, these settings apply to WF4 as much as they do to WCF. The maxConcurrentInstances setting sets the maximum number of workflow instances that can be in memory at a given time.

<behaviors> 
  <serviceBehaviors> 
    <behavior name="WorkflowServiceBehavior"> 
      <!-- Specify throttling behavior -->
      <serviceThrottling maxConcurrentInstances="1000"/> 
    </behavior>
  </serviceBehaviors>
</behaviors>

顺便说一句，在IIS中托管时，应始终使用持久性. IIS迟早会重新启动AppDomain，如果WorkflowServicehost无法将工作流实例的状态保存到磁盘，它们将丢失.这也意味着可以将空闲的工作流实例从内存中删除，并且不计入内存限制中的maxConcurrentInstances.

Just as an aside you should always use persistence when hosting in IIS. Sooner or later IIS is going to restart the AppDomain and if the WorkflowServicehost can't save the state of the workflow instances to disk they will be lost. It will also mean that idle workflow instances can be removed from memory and don't count against the maxConcurrentInstances which is an in memory restriction.

这篇关于464条消息后，Workflow Service停止响应的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！