NServiceBus MSMQ消息间歇性地卡在传出队列中

Question

我们有一个基于NServiceBus的Pub / Sub系统，我们遇到间歇性问题，消息无限期地卡在Publishers传出队列上，而不是传输到Subscribers输入队列。

注意事项：

1. 当我们重新启动发布服务和订阅服务时，消息流会暂时恢复。
2. 如果消息之间持续一段时间，问题似乎会更频繁发生。
3. 发布者服务驻留在LAN上，即防火墙另一侧的订阅者。
4. 有些消息可以通过！正如服务重启后提到的那样，事情会好一段时间。
5. 使用QueueExplorer，我可以看到传出队列中的消息状态为WAITING。

令人讨厌的是，我们的开发环境没有表现出这种行为，但是发布者和订阅者都在这个环境中同时驻留在同一个局域网上。

Answer 1

MSMQ消息卡在传出队列中纯粹是一个MSMQ问题。
重新启动发布者和订阅者服务应该没有区别，因为它们不直接参与消息传递。如果您只能通过重新启动发布/订阅服务而不是消息队列服务来解决问题，那么它看起来就像是资源/内存泄漏问题。

我想象这样的事情发生了：

1. 消息流向目标，在存储时消耗内核内存
2. 由于某种原因，内核内存耗尽（消息过多，内存泄漏，无论如何）
3. Destination现在拒绝新消息，因为它们无法通过电线
加载到内存中
4. 重置连接，直到达到WaitTime值才重新连接;队列正在“等待”
5. 系统循环到（3）和（4）直到......
6. 重新启动了Pub / Sub服务，现在有足够的资源来传递消息
7. 转到（2）

当使用它的许多服务和设备驱动程序之一暂时释放足够的内核内存时，偶尔会发出消息。

这篇博文的第4项是最可能的罪魁祸首： http://blogs.msdn.com/b/johnbreakwell/archive/2006/09/18/insufficient-resources-run-away-run-away.aspx

干杯
John Breakwell

Answer 2

我们在生产中遇到了类似的情况，结果我们将我们的一个订阅者端点迁移到一个新的物理主机，忘记在关闭旧端点之前取消订阅。我们的发布商试图向旧端点和新端点发送消息，但只能到达新端点。最终，发布者出站队列变得如此之大，以至于它开始影响所有外发消息。

Answer 3

我也遇到过这个问题，我知道它不是第4项，因为在它被卡在传出队列之前我没有发送任何东西。如果我在发送邮件之前让发布者和订阅者都坐了大约10分钟，它就永远不会离开传出队列。如果我在这段时间之前发送消息，它会正常流动。此外，如果我重新启动订阅者，则该消息将流动。每次我让它们闲置10分钟时，这是可以重复的。

我想我在这里找到了答案，至少这解决了我遇到的问题：

http://support.microsoft.com/kb/2554746

此外，在我的情况下，它与重新启动无关，所以不要让它让你失望，我确实在netstat中展示了症状，并且当客户端第一次启动时，消息最初会通过。

Answer 4

只是把我的2p扔进去：

我们遇到了一个问题，即消息队列服务存在某种内存泄漏，并且会占用大量未释放的内存。

这会导致邮件长时间卡住 - 尽管最终会被发送（有时会在3天后）。

我们还没有费心去解决这个问题，因为它只会在服务处于负载不足的情况下才会发生。