Question

在Azure Service Bus中，我希望发送的消息失败，但没有定义订阅。我通过将EnableFilteringMessagesBeforePublishing设置为true来实现此目的，这会引发异常NoMatchingSubscriptionException。

现在，在处理此异常时，我想要DeadLetter它。如果我致电BrokeredMessage.DeadLetter()，则会向InvalidOperation发送消息“ReceiveContext is null”

try
{
    await topicClient.SendAsync(brokeredMessage);
}
catch (NoMatchingSubscriptionException ex)
{
    // **throws exception** if message is attempted to move to DeadLetter queue
    await brokeredMessage.DeadLetterAsync(); 
}

这意味着只有在收到消息时才会将消息设为DeadLetter，而不是在发送时。

上述假设是否正确？

无论如何，处理失败邮件发送的最佳策略是什么？发送时是否有失败的消息可以在DeadLetter队列中结束以供以后调查？

由于

Answer 1

Deadletter queue（DLQ）与发送消息的队列相关联。如果您没有订阅（这是一个队列），那么也没有关联的DLQ。

关于策略，您有两个问题：

有没有订阅者？
如何处理发送操作失败的邮件？

第一个问题更多的是关于您不会继续这些应用程序的假设。第二个问题肯定会在整个应用程序运行时发生，你需要决定应该采取哪些补偿措施。

就个人而言，除非您绝对需要知道没有发布商（问题＃1），否则我不一定会启用EnableFilteringMessagesBeforePublishing功能。如果您更关心消息a发送失败的事实，而不是没有发布者，我建议使用自定义代码捕获失败并将其作为另一种类型的消息发送到存在的队列中用于控制/报告目的肯定（即你的申请确保它存在）。

DeadLettering BrokeredMessages在发送到Azure Service Bus中的主题时

1 个答案: