BizTalk中的线程饥饿

Question

我的BTS制作环境存在问题，我们无法在其他环境中重现。跟我在一起。

我们的解决方案的一部分，编排（orch1）使得向消息框发送直接绑定消息，然后在一个分支上进入具有相关接收形状的监听形状，并在另一个分支上执行延迟（实现接收超时）科。延迟时间设置为10分钟。

直接绑定请求由另一个业务流程（orch2）处理，然后该响应将响应（再次通过直接绑定）返回到消息框，以便orch1可以接收它。

正在发生的事情是，在这种类型的每50次操作中，orch1中的超时大约一次被击中，当orch2的响应返回时，我们得到路由失败（这是你期望的orch1上的实例订阅对于该消息已被删除）。

奇怪的是，orch2甚至没有初始化，直到在orch1中达到超时之后（参见下面的截图）

在这里你可以看到orch1将直接绑定请求发送到消息框，10分钟后超时被命中。请求在11:26:31发送，超时在11:36:32发送。

这显示了orch2的时间。正如您所看到的那样，只有在orch1（在11:36:45）触发超时后才会触发接收形状

奇怪的是，orch1和orch2都托管在同一主机中。此外，我们有一个负载均衡的集群，我们有2个这个主机的实例可以工作。所以我希望orch2上应该始终有可用来处理传入的工作。然而，情况似乎并非如此。

我当前的怀疑是两个主机实例之间的线程饥饿。不过我的问题是

1. 这是一个明智的怀疑吗？
2. 我做了一些根本错误的事情吗？
3. 使用影响线程的listen形状有什么用吗？

请注意，我们已将主机线程设置配置为推荐级​​别（MaxIOThreads = 100，MaxWorkerThreads = 100，MinIOThreads = 25，MinWorkerThreads = 25）

Answer 1

听起来像竞争条件，但我不知道在哪里。

您是否考虑过分离任务？

1. orch1的第一部分发送请求。
2. Orch2处理任务1的输出。
3. orch1的第二部分处理来自orch2 / Task 2的响应。

缺点是它无法响应超时。 我不知道这对你的问题是否重要。