Question

我试图让队列的重试逻辑正常工作，而且我遇到了问题。 minBackoff变量似乎并没有真正起作用。我在日志中看到收到的消息然后失败然后几乎立即重试。我的minBackoff设置为600秒。

以下是设置查询的代码：

client.RetryPolicy = new RetryExponential(minBackoff: TimeSpan.FromSeconds(15),
                                                         maxBackoff: TimeSpan.FromSeconds(600),
                                                         maxRetryCount: 3);

        client.OnMessage(message =>
        {

            UserCreationSubmitted msg = message.GetBody<UserCreationSubmitted>();
            Console.WriteLine("------------------------------");
            Console.WriteLine($"Body {msg.UserName}");

            Random rnd = new Random();
            int ranNum = rnd.Next(0, 9);
            if (msg.UserName.Contains(ranNum.ToString()))
            {
                Console.WriteLine("!!!Error!!!");
                Console.WriteLine("------------------------------");
                throw new Exception();
            }
        });

这里的代码“我觉得不应该工作......”

{{1}}

有没有人知道为什么minbackoff和maxbackoff似乎没有真正在这里工作？奇怪的是，maxRetryCount的工作就像一个骑兵，所以我想它在我的实施中肯定会导致其他人无法工作。

Answer 1

当接收消息失败时，ASB客户端使用

RetryExponential进行重试。在您的代码中，在收到消息之后，在OnMessage API回调中处理期间抛出异常。 OnMessage API将abandon the message，使其立即显示。

您可以选择几个选项：

克隆消息，将ScheduledEnqueueTimeUtc设置为您想要的延迟，然后发送，然后填写原始消息。
推迟发送消息，但之后您只能通过SequenceNumber收到消息。在这种情况下，您可以创建一条新消息，其中包含原始消息序列号作为有效负载，安排新消息并发送它。这样您就可以在原始邮件上获得准确的计数。

理想情况下，放弃带有时间跨度的消息会很好，但使用当前的API是不可能的。

Azure Service Bus Retry Policy的minbackoff不起作用？

1 个答案: