【问题标题】:How to intentionally deadletter a message is azure functions v2如何故意死信一条消息是 azure functions v2
【发布时间】:2018-10-23 20:36:26
【问题描述】:

这个问题与其他有答案的问题相似,但我认为 AF v2 可能会改变(我在没有 v1 经验的情况下跳入 v2)。 AF v2集成的用于与ServiceBus交互的程序集似乎是Microsoft.Azure.ServiceBus,它有一个名为“Message”的类,与其他微软服务总线程序集中的“BrokeredMessage”不太一样。两者之间的一个关键区别是 BrokeredMessage (在几乎所有文档、示例和我能找到的任何其他线程中都引用了它)有一个 .Deadletter() 方法,而 Message 没有。当我无法访问收到消息的客户端或接收者时,如何故意将消息死信?

(我已经看到有关克隆消息、放置我自己的“死信”队列以及让 AF 提交原始消息的建议——我认为这不是一个适当的解决方案。)

【问题讨论】:

  • 如果你抛出异常并且没有捕获它,函数宿主将放弃该消息。当达到 maxdeliverycount 时,您的消息将被推送到死信队列
  • 是的,但是有“可重试”异常和“不可重试”异常——我想立即捕获不可重试和死信,而不是浪费资源重试直到达到 maxdeliverycount
  • 可以考虑把不可重试的抓一次,通过代码移到毒队列中。毒药队列通常使用以下名称“originalqueuename-poison”创建。
  • 是的,你这样做你不能使用 servicebustrigger
  • @Baskar - 我可能会遗漏一些东西,但听起来你建议创建我自己的“死信队列” - 我在我的 OP 中指出这不是一个理想的解决方案 - 如果我知道,请告诉我我错过了一些与您的建议不同的地方。

标签: azure azure-functions servicebus


【解决方案1】:

我还没有在functions环境中证明出来,但是根据我在github上打开的ticket(https://github.com/Azure/azure-webjobs-sdk/issues/1986),webjobs v3支持在function trigger中绑定收到它的Message和MessageReceiver,然后MessageReceiver 可用于对消息进行死信。

【讨论】:

  • 他们确实需要更新文档,您的回答是我遇到的对该解决方案的唯一参考。我确认它有效。
【解决方案2】:

这是一个真正的痛苦,因为它仍然没有记录在案。 Azure SDK for .NET 项目自述文件中的 API 参考甚至指向旧命名空间中的文档?‍♂️

我不得不搜索源代码以找到获取 LockToken 的正确方法。

    [FunctionName("MyFunction")]
    public static async Task Run([ServiceBusTrigger("myqueue", Connection = "myconnectionstring")] Message message,
        ILogger log, MessageReceiver messageReceiver)
    {
        await messageReceiver.DeadLetterAsync(message.SystemProperties.LockToken);
    }

将MessageReceiver作为参数自动绑定,无需额外设置。

【讨论】:

猜你喜欢
  • 1970-01-01
  • 2021-08-02
  • 2016-12-11
  • 1970-01-01
  • 2020-08-30
  • 2015-04-22
  • 1970-01-01
  • 2020-03-03
  • 2012-09-23
相关资源
最近更新 更多