Question

虽然我的问题与SO上已经发现的问题类似，但这些帖子对我没有帮助，所以这里是：

假设：

同一网段上的两台计算机（自然位于同一网域，实际上位于同一桌面上）
这两台机器都是Windows 7工作站
两台机器都已禁用防火墙
两台机器互相看见（ping工作）
其中一个上有一个私人非交易消息队列测试。
发件人计算机有HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\SimpleClient\@BinaryEnabled = 'Yes'
队列所有者从另一台计算机发送消息
邮件卡在传出队列中，永远不会到达目标。
当从同一台机器（即本地）发送时，消息即可到达。

使用以下代码发送消息：

var q = new MessageQueue(@"FormatName:Direct=OS:il-mark-lap\private$\test");
q.Send(string.Format("Test message sent at {0} from {1}", DateTime.Now, Environment.MachineName));

il-mark-lap 是带队列的机器的地址。

为了使这件事有效，我该怎样做？

非常感谢。

Answer 1

我想我找到了这个问题的答案，我遇到了似乎同样的问题，但是在我没有向客户端发送消息10分钟后我才陷入困境。看看这篇知识库文章，它可能会对你有所帮助。另外，在我的情况下，它与重新启动无关，所以不要让它让你失望，我确实在netstat中展示了症状，并且当客户端第一次启动时，消息最初会通过。

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

Answer 2

我刚刚处理了问题，以下是我为解决问题而采取的步骤：

从Microsoft获取DTCPing实用程序，在使用MSMQ的计算机上运行它，DTC必须能够相互通信才能使MSMQ正常工作。

Troubleshooting MSDTC issues with the DTCPing tool

这反过来让我意识到MSMQ高度依赖于NetBIOS名称 - 机器必须能够通过单独使用NetBIOS名称相互ping通。

完成此操作后，请确保重新启动所有消息队列服务（在发送计算机和目标计算机上，因为它需要能够执行反向NetBIOS操作）。

在我的情况下，一旦我使用NetBIOS名称解析进行DTC - 重新启动服务 - 一切都开始神奇地工作。

我强烈建议您访问this page以获取更多资源。

Answer 3

我今天遇到了这个问题。要解决此问题，我们必须打开接收服务器的消息队列属性对话框，并在“服务器安全性”选项卡上取消选中“禁用未经过身份验证的RPC调用”复选框。此外，在私有队列属性|安全选项卡我们更改了安全性以授予Everyone完全控制权。在我的情况下，机器在同一个网段上，但不在同一个网域上。该队列是非事务性的。我们使用IP地址作为端点绑定（WCF），NetBIOS / DNS不在使用中。

Answer 4

我遇到了一个问题，我们有2台服务器向第三台服务器发送消息。只收到一个服务器的消息。来自另一个的消息在“未确认”中被卡在传出队列中。

问题是因为所有计算机都克隆了VM并且在注册表项中具有相同的QMId：HKLM \ Software \ Microsoft \ MSMQ \ Parameters \ Machine Cache。我们在修复问题的服务器上重新安装了MSMQ。

参考文献：

http://baleinoid.com/whaly/2012/08/random-bug-msmq-unacknowledged-messages/ http://blogs.msdn.com/b/johnbreakwell/archive/2007/02/06/msmq-prefers-to-be-unique.aspx

Answer 5

LAN中的私有队列通常可以相互发送消息。但有时私有队列可能无法访问并导致其他人创建传出队列......不知道原因。

Answer 6

答案很简单。确保您可以telnet端口1801,135,2103＆amp; 2105从源机器到目的地，反之亦然。还要确保MSMQ在两台计算机上运行。

Answer 7

如果一个服务器突然拒绝接收消息（导致另一个服务器在传出队列中有消息队列），这可能是因为日志消息大小限制。

如果服务器的日志队列积压超过 1GB，MSMQ 将静默拒绝消息。这可以通过查看 C:\Windows\System32\MSMQ\ 及其子目录来验证。

当日志队列消息被删除并且大小不再超过 1GB 时，它应该立即开始再次接受消息（无需重新启动消息队列服务）。

MSMQ消息被困在传出队列中

7 个答案: