正如您所怀疑的,您包含的值对于这些参数的含义没有意义。以下是我对参数的理解:
- DeltaBackoff - 用于以指数方式增加重试间隔的间隔。
- MaximumBackoff - 您希望重试之间的最大次数。
- MaxRetryCount - 系统重试操作的最长时间。
- MinimalBackoff - 您希望两次重试之间的最短时间。
- TerminationTimeBuffer - 系统在放弃之前重试操作的最长时间。
它始终会重试最多 maxRetryCount(在您的情况下为 10),除非首先达到终止时间缓冲区限制。
它也不会尝试大于终止时间缓冲区(在您的情况下为 90 秒)的时间,无论它尚未达到最大重试计数。
minBackoff 是您在重试之间等待的最短时间,maxBackoff 是您在重试之间等待的最长时间。
DeltaBackOff 值是每次重试内部将按指数增长的值。请注意,这不是一个准确的时间。它随机选择一个比该时间稍短或稍长的时间,以便所有重试的多个线程不会在完全相同的时间执行此操作。它的随机性有点让人错愕。在第一次实际尝试和第一次重试之间仅存在 minBackOff 间隔。由于您将 deltaBackOff 设置为 30 秒,因此如果进行第二次重试,则大约需要 30 秒加上 minBackOff。第三次重试将是 90 秒加上 minBackOff,每次重试依此类推,直到达到最大退避值。
我要确保指出的一件事是,这是一个重试策略,这意味着如果某个操作收到异常,它将遵循此策略再次尝试。如果检索、死信、延迟等操作失败,则将启动此重试策略。这些是针对服务总线的操作,而不是您自己的处理中的异常。
我在这一点上可能是错误的,但我的理解是,这并不直接与实际接收要处理的消息相关,除非对接收的调用失败。连续处理是通过 Receive 方法和您自己的代码循环或通过使用 OnMessage 操作(在幕后也使用 Receive)来处理的。只要实际尝试接收时没有出现错误,则不会应用此重试策略。调用接收之间使用的时间间隔可以通过您自己使用需要一定时间跨度的 Receive 方法来设置,也可以通过在创建queueClient 对象之前设置MessagingFactory.OperationTimeout 来设置。如果由于您使用了在 Receive 上提供时间跨度的重载或达到了默认时间跨度而导致接收调用达到等待限制,则只会返回 Null。这不被视为例外,因此重试策略不会生效。
可悲的是,我认为您必须为实际处理编写自己的指数回退代码。不过,有很多例子。
是的,您可以在 QueueClient 和 SubscriptionClient 上设置此重试策略。