2017-01-23 59 views
4

我在Azure中创建了一个服务总线队列,它运行良好。如果邮件在默认尝试(10次)内未收到,则会将邮件正确地移动到死信队列中。重新提交来自死信队列的消息 - Azure服务总线

现在,我想从死信队列中重新提交此消息回到它发出的队列,看看它是否再次有效。我已经尝试使用服务总线浏览器。但它会立即移到死信队列中。

是否有可能做同样的事情,如果有的话如何?

回答

1

服务总线浏览器工具始终会在修复并重新提交来自死信队列的消息时创建原始消息的克隆。它与默认的Service Bus消息不能提供任何消息修复和重新提交机制不同。我建议你调查为什么当你重新提交邮件时,你的邮件会在deadletter队列以及它的克隆中结束。希望这可以帮助!

+2

原始邮件已经死了,因为它试图传递10次,并且由于某种原因,服务不可用。但现在服务又回来了。消息的克隆也显示了与原始消息相同的错误,并且只需一次尝试,计数就已经是11.因此,我假设传递消息的计数不会在克隆消息中复位 –

2

你需要发送一个具有相同有效载荷的新消息。 ASB设计不支持消息重新提交。

1

听起来这可能与ASB的“重复信息检测”功能有关。

当您在ServiceBus资源管理器中重新提交邮件时,它将克隆邮件,从而新邮件将具有与原邮件在死邮件队列中相同的标识。

如果您在队列/主题上启用了“需要重复检测”,并且您尝试在“重复检测历史记录时间窗口”内重新提交邮件,则邮件将立即再次移至死信号队列。

如果您想使用Service Bus Explorer重新提交deadletter消息,那么我认为您必须在队列/主题上禁用“需要重复检测”。

0

如果您直接将BrokeredMessage从死信队列移动到活队列,则可能是“重复消息检测”为Peter Berggreen,或者更有可能,那么DeliveryCount仍然会达到最大值,并且它将返回到死信队列。

将BrokeredMessage从死信队列中拉出,使用GetBody()获取内容,在新的BrokeredMessage中创建该数据并将其发送到队列。您可以通过使用peek从死信队列中获取消息内容,然后将新消息发送到实时队列,然后从死信队列中删除消息,以安全的方式执行此操作。这样,如果由于某种原因无法写入实时队列,您将不会丢失关键数据。

对于新的BrokeredMessage,您应该不会遇到“重复的邮件检测”问题,并且DeliveryCount将被重置为零。