2

我在我们的 BTS 生产环境中遇到了无法在其他环境中重现的问题。在这里忍受我。

作为我们解决方案的一部分，编排 (orch1) 将直接绑定的消息发送到消息框，然后进入侦听形状，其中一个分支上的相关接收形状和另一个分支上的延迟（实现接收超时）。延迟设置为 10 分钟。

直接绑定请求由不同的编排（orch2）处理，然后将响应（再次通过直接绑定）返回到消息框，以便 orch1 可以接收它。

发生的情况是，大约每 50 次这种类型的操作中，orch1 中的超时被击中，当来自 orch2 的响应返回时，我们会遇到路由失败（这是您所期望的 orch1 上的实例订阅消息已被删除）。

奇怪的是，orch2 甚至在 orch1 中超时后才初始化（请参见以下屏幕截图）

Orch1 计时

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

Orch2 计时

这显示了 orch2 的时序。如您所见，接收形状仅在 orch1 中触发超时后才被击中（在 11:36:45）

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

我目前的怀疑是两个主机实例的线程饥饿。但是我的问题是

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

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

4

1 回答 1

0

听起来像是比赛条件，但我不知道在哪里。

您是否考虑过分离任务？

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

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

于 2012-06-18T19:05:26.030 回答