我们有一个基于NServiceBus的Pub/Sub系统，其中我们在消息在发布者传出队列中无限期停留时发生间歇性问题，而不是传输到订阅者输入队列。NServiceBus MSMQ消息间歇性地停留在传出队列中
注意要点：
令人讨厌的是我们的开发环境没有表现出这种行为，但是再次，发布者和订阅者都在这个环境中驻留在同一个局域网中。
MSMQ邮件卡在传出队列中纯粹是一个MSMQ问题。
重新启动发布服务器和订阅服务应该没有什么区别，因为它们不直接涉及消息传递。如果您只能通过重新启动发布/订阅服务而不是消息排队服务来解决问题，那么它看起来像资源/内存泄漏问题。
我想象这样的事情发生：
只有足够的内核内存被使用它的许多服务和设备驱动程序中的一个暂时释放时，才会发生偶然消息。这篇博客的
第4项是最有可能的罪魁祸首： http://blogs.msdn.com/b/johnbreakwell/archive/2006/09/18/insufficient-resources-run-away-run-away.aspx
干杯
约翰Breakwell
谢谢约翰，我们会更详细地检查一下，看看它是否有帮助。感谢您的帮助。 我唯一怀疑的是消息量很小。也许每天只有一到两个，但是在那些吞噬内核内存的服务器上可能还有别的东西。将调查和建议。 – 2011-12-14 20:02:21
也遇到了这个问题，我知道它不是第4项，因为在它停留在传出队列中之前，我不会发送任何内容。如果我在发送消息之前让发布者和订阅者坐了大约10分钟，它就永远不会离开发送队列。如果我在这段时间之前发送一条消息，它流动正常。另外，如果我重新启动用户，则消息将流动。 – BlackICE 2011-12-20 20:05:40
我们在生产类似的情景，后来我们迁移我们的用户终端之一一个新的物理主机，并在关闭旧端点之前忘记取消订阅。我们的发布商正试图向新旧终端传递消息，但只能达到新消息。最终，发布者出站队列变得如此之大，以至于它开始影响所有传出的邮件。
我也遇到过这个问题，我知道它不是第4项，因为我没有发送任何东西在它卡在传出队列中之前。如果我在发送消息之前让发布者和订阅者坐了大约10分钟，它就永远不会离开发送队列。如果我在这段时间之前发送一条消息，它流动正常。另外，如果我重新启动用户，则消息将流动。每当我让他们闲置10分钟时，这是可重现的。
我想我找到了答案在这里，至少在这个固定的，我遇到的问题：
http://support.microsoft.com/kb/2554746
而且，在我的情况下，它不得不无关重新启动，所以不要让那把你扔掉，我确实在netstat中显示了这些症状，并且当客户端首次启动时，消息最初会通过。
只是把我的2P在：
我们有一个问题，即排队服务的消息有某种内存泄漏，并会消耗大量的内存是没有释放。
这导致邮件被卡住了很长一段时间 - 尽管他们最终会被交付（有时后3天）。
我们并没有打算解决这个问题，因为它只发生在服务负荷很重时，并不经常发生。
好奇，订阅机有多个网卡？在我的情况下，用户是一台同时拥有局域网和无线网络的笔记本电脑，但带有Win7和1个网卡的台式机却没有出现问题。 – BlackICE 2011-12-21 14:43:29