ServiceBus RetryExponential属性含义 [英] ServiceBus RetryExponential Property Meanings

问题描述

我很难理解与QueueClients一起使用的RetryExponential类(我也假定为SubscriptionClients).

I'm having a hard time understanding the RetryExponential class that is used in conjunction with QueueClients (and I assume SubscriptionClients as well).

此处列出了这些属性，但我认为我对它们的描述的解释不正确.

The properties are listed here, but I don't think my interpretation of their descriptions is correct.

这是我的解释...

    var minBackoff = TimeSpan.FromMinutes(5);  // wait 5 minutes for the first attempt?
    var maxBackoff = TimeSpan.FromMinutes(15);  // all attempts must be done within 15 mins?
    var deltaBackoff = TimeSpan.FromSeconds(30); // the time between each attempt?
    var terminationTimeBuffer = TimeSpan.FromSeconds(90); // the length of time each attempt is permitted to take?
    var retryPolicy = new RetryExponential(minBackoff, maxBackoff, deltaBackoff, terminationTimeBuffer, 10);

我的工作人员角色在过去一个小时内仅尝试两次处理队列中的消息，尽管我认为，根据上述配置，消息应更频繁地处理(每30秒+上一次尝试使用的处理时间)最多90秒).我认为这些设置将强制每2分钟重试一次.但是，我完全看不到这种解释是指数的.

My worker role has only attempted to processing a message off the queue twice in the past hour even though I think based on the configuration above it should go off more frequently (every 30 seconds + whatever processing time was used during the previous attempted up to 90 seconds). I assume that these settings would force a retry every 2 mins. However, I don't see how this interpretation is Exponential at all.

我对每个属性的解释(在上面的评论中)正确吗?如果不是(我认为它们不正确)，那么每个属性是什么意思?

Are my interpretations for each property (in comments above) correct? If not (and I assume they're not correct), what do each of the properties mean?

推荐答案

您怀疑，所包含的值对于这些参数的含义没有意义.这是我对参数的理解:

As you suspected, the values you included do not make sense for the meaning of these parameters. Here is my understanding of the parameters:

• DeltaBackoff-用于重试间隔按指数递增的间隔.
• MaximumBackoff-两次重试之间所需的最长时间.
• MaxRetryCount-系统重试该操作的最长时间.
• MinimalBackoff-您希望两次重试之间的最短时间.
• TerminationTimeBuffer-系统在放弃之前重试该操作的最长时间.

在您的情况下，它将始终重试到maxRetryCount，直到10，除非首先达到了terminationTimeBuffer限制.

It always will retry up to the maxRetryCount, in your case 10, unless the terminationTimeBuffer limit is hit first.

它也不会尝试大于terminationTimeBuffer的时间，在您的情况下为90秒，无论尚未达到最大重试次数.

It will also not try for a period greater than the terminationTimeBuffer, which in your case is 90 seconds, regardless of it hasn't hit the max retry count yet.

minBackoff是重试之间等待的最短时间，而maxBackoff是重试之间等待的最长时间.

The minBackoff is the minimal amount of time you will wait between retries and maxBackoff is the maximum amount of time you want to wait between retries.

DeltaBackOff值是每个重试内部值将按指数增长的值.请注意，这不是确切时间.它随机选择一个比该时间少一点或多一点的时间，以便所有重试的多个线程都不会在同一时间这样做.它的随机性使它有些错开.在第一次实际尝试和第一次重试之间，将仅存在minBackOff间隔.由于您将deltaBackOff设置为30秒，因此如果进行第二次重试，则大约需要30秒加上minBackOff.第三次重试将是90秒加上minBackOff，依此类推，直到每次重试达到最大后退.

The DeltaBackOff value is the value at which each retry internal will grow by exponentially . Note that this isn't an exact time. It randomly chooses a time that is a little less or a little more than this time so that multiple threads all retrying aren't doing so at the exact same time. Its randomness staggers this a little. Between the first actual attempt and the first retry there will be the minBackOff interval only. Since you set your deltaBackOff to 30 seconds, if it made it to a second retry it would be roughly 30 seconds plus the minBackOff. The third retry would be 90 seconds plus the minBackOff, and so on for each retry until it hits the maximum backoff.

我要指出的一件事是，这是一个重试策略，这意味着如果操作收到异常，它将遵循该策略再次尝试.如果诸如Retrieve，Deadletter，Defer等的操作失败，则将使用此重试策略.这些操作针对服务总线，而不是您自己的处理中的异常.

One thing I would make sure to point out is that this is a retry policy, meaning if an operation receives an exception it will follow this policy to attempt it again. If operations such as Retrieve, Deadletter, Defer, etc. fail then this retry policy is what will kick in. These are operations against service bus, not exceptions in your own processing.

对此我可能是错的，但是我的理解是，除非接收调用失败，否则这并不直接与实际接收的消息相关联.通过Receive方法和您自己的代码循环，或通过使用OnMessage操作(在后台也使用Receive)来处理连续处理.只要实际上没有错误尝试接收，就不会应用此重试策略.调用接收之间的时间间隔是由您自己使用需要时间的Receive方法来设置的，或者是在创建queueClient对象之前设置了MessagingFactory.OperationTimeout来设置的.如果接收呼叫达到等待的限制，或者是因为您使用了在Receive上提供时间跨度的重载，或者它达到了默认值，则仅返回Null.这不是例外，因此重试策略不会生效.

I could be wrong on this, but my understanding is that this isn't directly tied to the actual receipt of a message for processing unless the call to receive fails. Continuous processing is handled through the Receive method and your own code loop, or through using the OnMessage action (which behind the scenes also uses the Receive). As long as there isn't an error actually attempting to receive then this retry policy doesn't get applied. The interval used between calls to receive is set by either your own use of the Receive method which takes a timespan, or if you set the MessagingFactory.OperationTimeout before creating the queueClient object. If a receive call reaches it's limit of waiting either because you used the overload that provides a timespan on Receive or it hits the default, a Null is simply returned. This is not considered an exception and therefore the retry policy won't kick in.

可悲的是，我认为您必须编写自己的指数补偿才能进行实际处理.虽然有很多例子.

Sadly, I think you have to code your own exponential back off for actual processing. There are tons of examples out there though.

是的，您可以在QueueClient和SubscriptionClient上都设置此重试策略.

And yes, you can set this retry policy on both QueueClient and SubscriptionClient.

这篇关于ServiceBus RetryExponential属性含义的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！