【发布时间】：2012-02-19 00:41:23
【问题描述】：
这是一个简单的问题，但我找不到答案。
假设我的消息被放入重试队列（谁创建重试队列？是 WCF 还是 MSMQ 服务？）
5 分钟后（这是我的重试延迟），该消息返回到应用程序队列。
问题：谁在超时后将消息从重试队列移动到应用程序队列？
额外问题：如何跟踪延迟？消息是否获得“移动”时间戳和“重试”时间戳？
【问题讨论】：
【发布时间】：2012-02-19 00:41:23
【问题描述】：
带有 MSMQ 4.0 的 WCF 确实提供了 automatic retry and poison message handling，尽管 Hugh 的回答对于旧版本的 MSMQ 是正确的。
从 cmets 编辑： 在识别将消息移动到重试队列并返回的过程时，我假设它是 MSMQ 服务本身，因为这是 MSMQ 4.0 中的一个新功能。 WCF 参与了包装所有这些活动的事务，当然，它还处理由 MSMQ 放入队列中的消息。
【讨论】：
-
谢谢 - 我不知道这个新功能。
-
我的客户已经在大容量电子商务环境中使用它一年多了，而且它坚如磐石。保存他们的饼干一两次:)
-
我看过那篇文章，但我不清楚“消息已移至重试队列”——这是谁在做的？由于重试参数是在 WCF 绑定上定义的，感觉就像 WCF（即 Web 服务）负责，但同时重试是 MSMQ 4 的一个特性。这就是我感到困惑的地方。
-
我对将消息移动到重试队列的内部机制一无所知，但我猜除了定义重试参数之外，WCF 不参与该过程。由于这是 MSMQ 4.0 中的一项新功能，因此我假设所有消息移动都是由 MSMQ 在内部完成的。 WCF 将影响包装此处理的事务以及当它返回常规队列时对消息的“重新处理”。
-
我认为这是一个合理的推理。请把它放在答案中。
具有标准 msmq 绑定（netMsmqBinding 和 msmqIntegrationBinding）的 WCF 不支持重试。所以回答你的问题：
谁创建了重试队列？ - 你做的。
谁在超时后将消息从重试队列移动到应用程序队列？ - 你这样做。
如何跟踪延迟？ - 你必须这样做。
NServiceBus 是开源的，可以使用 MSMQ 进行传输。此产品提供开箱即用的重试功能，但不使用 WCF。
更新
以上适用于 MSMQ 3 及以下版本。
【讨论】：
根据这篇文章Handling Poison Messages MSMQ 4 提供了一些允许应用程序使用子队列处理有害消息的新功能。这些特点是：
- 中止计数器
- 移动计数器
- 能够在主队列和子队列之间以及子队列之间移动消息。
所以看起来实际的移动是由 WCF 处理的，而不是 MSMQ；并且 MSMQ 现在只是具有支持有害消息和重试处理的工具。
【讨论】：