【问题标题】:DeadLettering BrokeredMessages while Sending to a Topic in Azure Service Bus发送到 Azure 服务总线中的主题时出现 DeadLettering BrokeredMessages
【发布时间】:2017-03-30 12:53:02
【问题描述】:

在 Azure 服务总线中,我希望消息发送失败,但没有定义订阅。我通过将EnableFilteringMessagesBeforePublishing 设置为true 来实现这一点,这会引发异常NoMatchingSubscriptionException

现在,在处理此异常时,我想对其进行死信处理。如果我打电话给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(); 
}

这意味着消息只能在接收时被死信,而不是在发送时。

上述假设正确吗?

无论如何,处理失败消息发送的最佳策略是什么?发送失败的消息有没有办法最终进入死信队列以供日后调查?

谢谢

【问题讨论】:

    标签: azure azureservicebus


    【解决方案1】:

    Deadletter 队列 (DLQ) 与发送消息的队列相关联。如果您没有订阅(这是一个队列),也没有关联的 DLQ。

    关于策略,您有两个问题:

    1. 有订阅者吗?
    2. 发送操作失败的消息如何处理?

    第一个问题更多的是关于您所做的假设,即如果这些应用程序不应该继续运行。第二个问题是在整个应用程序运行期间肯定会发生的事情,您需要决定应该采取什么补偿措施。

    就个人而言,我不一定要启用EnableFilteringMessagesBeforePublishing 功能,除非您绝对需要知道没有发布者(问题#1)。如果您更关心消息 a 发送失败的事实,而不是没有发布者,我建议您使用自定义代码来捕获故障并将其作为另一种类型的消息发送到存在的队列中以进行控制/报告肯定的(即您的应用程序确保它存在)。

    【讨论】:

      猜你喜欢
      • 2021-05-23
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2019-07-25
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多