MSMQ 有毒消息和 TimeToReachQueue
我尝试通过以下方式创建有害消息场景。
1-在服务器上创建消息队列（事务队列）。 2-创建了一个接收器应用程序来处理该服务器上的传入消息。 3-创建位于客户端计算机上的客户端应用程序，该应用程序将消息发送到具有特定队列名称的服务器。
4-我使用带有以下代码的发送方客户端应用程序（C# 4.0 框架）：
System.Messaging.Message mm = new System.Messaging.Message("Some msg");
mm.TimeToBeReceived = new TimeSpan(0, 0, 50);
mm.TimeToReachQueue = new TimeSpan(0, 0, 30);
mm.UseDeadLetterQueue = true;
mq.Send(mm);
因此，这将到达队列的超时设置为 30 秒。
- 第一次测试效果很好。消息已通过并被服务器应用程序接收。
- 我的第二次测试，我断开了以太网电缆，然后从客户端计算机进行了另一次发送。
我可以在客户端计算机上的消息队列中看到消息正在等待发送（“等待连接”）。我的问题是，当超过 30 秒（或 50 秒）时，消息永远不会进入客户端计算机上的死信队列。
为什么会这样呢？ ...我原以为它会去那里，但有些超时了。
在 Windows 7（客户端）/Windows Server 2008 r2（服务器）上测试
I tried creating a poison message scenario in the following manner.
1- Created a message queue on a server (transactional queue).
2- Created a receiver app that handles incoming messages on that server.
3- Created a client app located on a client machine which sends messages to that server with the specific name for the queue.
4- I used the sender client app with the following code (C# 4.0 framework):
System.Messaging.Message mm = new System.Messaging.Message("Some msg");
mm.TimeToBeReceived = new TimeSpan(0, 0, 50);
mm.TimeToReachQueue = new TimeSpan(0, 0, 30);
mm.UseDeadLetterQueue = true;
mq.Send(mm);
So this is setting the timeout to reach queue to 30 seconds.
- First test worked fine. Message went through and was received by the server app.
- My second test, I disconnected my ethernet cable, then did another send from the client machine.
I can see in the message queue on the client machine that the message is waiting to be sent ("Waiting for connection"). My problem is that when it goes beyond the 30 sec (or 50sec too), the message never goes in the Dead-letter queue on the client machine.
Why is it so ? ... I was expecting it to go there some it timed-out.
Tested on Windows 7 (client) / Windows server 2008 r2 (server)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
你的问题已经有几天了。你发现什么了吗？
我对您的情况的解释是拔掉电缆是关键。
在约翰描述的场景中，存在现有连接，并且接收方无法在设定的时限内正确处理消息。
但是，在您的场景中，接收端点永远没有机会处理消息，因此永远不会发生超时。正如您所说，消息的状态是
等待连接。 从未发送的消息在逻辑上不能有超时来到达其目的地。问问自己，如果队列本质上不活动，Windows/MSMQ 会不必要地牺牲多少资源（以及多久一次）来检查 MessageQueues 的多少个条件？系统上可能有很多队列，其中包含大量消息。
我期望的行为是，如果您重新插入网络电缆并重新建立连接，那么，仅在需要时您的有害消息才会被显示。检查超时并最终移至死信队列。
您可能想检查一下这个场景 - 或者您是否已经检查过？
Your question is a few days old already. Did you find out anything?
My interpretation of your scenario would be that the unplugged cable is the key.
In the scenario John describes, there is an existing connection and the receiver could not process the message correctly within the set time limit.
In you scenario, however, the receiving endpoint never gets the chance to process the message, so the timeout can never occur. As you said, the state of the message is
Waiting for connection. A message that was never sent cannot logically have a timeout to reach its destination.Just ask yourself, how many resources Windows/ MSMQ would unneccessaryly sacrifice - and how often - to check MessageQueues for how-many conditions if the queues is essentially inactive? There might be a lot of queues with a lot of messages on a system.
The behavior I would expect is that if you plug the network cable back in and the connection is re-established that then, only when it is needed, your poison message wil be checked for the timeout and eventually moved to the DeadLetter queue.
You might want to check this scenario out - or did you already check it out the meantime?