3

Мне сложно понять класс RetryExponential, который используется совместно с QueueClients (и я также предполагаю, что и SubscriptionClients).ServiceBus RetryExponential Значения свойств

Свойства указаны here, но я не думаю, что моя интерпретация их описаний верна.

Вот моя интерпретация ...

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 минуты. Однако я не вижу, как эта интерпретация вообще экспоненциальна.

Являются ли мои интерпретации для каждой собственности (в комментариях выше) правильными? Если нет (и я предполагаю, что они не правильные), что означает каждое из свойств?

ответ

7

Как вы подозревали, значения, которые вы включили, не имеют смысла для значения этих параметров. Вот мое понимание параметров:

  • DeltaBackoff - интервал, используемый для экспоненциального увеличения интервала повтора.
  • MaximumBackoff - максимальное количество раз, которое вы хотите между попытками.
  • MaxRetryCount - максимальное время, в течение которого система будет повторять операцию.
  • MinimalBackoff - минимальное время, необходимое между попытками.
  • TerminationTimeBuffer - максимальное время, в течение которого система будет повторять операцию до сдачи.

Он всегда будет повторять до maxRetryCount, в вашем случае 10, если только предел termTimeBuffer не был первым.

Он также не будет пытаться на период больше, чем termTimeBuffer, который в вашем случае составляет 90 секунд, независимо от того, что он еще не ударил счетчик макс.

MinBackoff - это минимальное количество времени, которое вы будете ждать между попытками, а maxBackoff - это максимальное количество времени, которое вы хотите ожидать между попытками.

Значение DeltaBackOff - это значение, при котором каждый внутренний повтор будет расти экспоненциально. Обратите внимание, что это не точное время. Он случайным образом выбирает время, которое немного меньше или немного больше, чем на этот раз, так что несколько потоков, все повторные попытки, не делают этого в одно и то же время. Его случайность немного мешает. Между первой фактической попыткой и первой попыткой будет только интервал minBackOff. Поскольку вы установили deltaBackOff на 30 секунд, если он перешел на вторую попытку, это будет примерно 30 секунд плюс minBackOff. Третий повтор будет составлять 90 секунд плюс minBackOff и т. Д. Для каждой повторной попытки, пока он не достигнет максимального отступления.

Одна вещь, которую я хотел бы указать, это то, что это политика повтора, то есть если операция получает исключение, она будет следовать этой политике, чтобы повторить попытку. Если операции типа Retrieve, Deadletter, Defer и т. Д. Терпят неудачу, то эта политика повторных попыток - это то, что произойдет. Это операции с шиной обслуживания, а не исключения в вашей собственной обработке.

Я мог ошибаться в этом, но я понимаю, что это напрямую не связано с фактическим получением сообщения для обработки, если вызов для получения не выполняется. Непрерывная обработка обрабатывается методом Receive и вашим собственным циклом кода или с помощью действия OnMessage (которое за кулисами также использует Receive). До тех пор, пока не будет предпринята попытка получить ошибку, эта политика повтора не применяется. Интервал между вызовами для приема устанавливается либо вашим собственным использованием метода Receive, который занимает промежуток времени, либо если вы установите MessageFactory.OperationTimeout перед созданием объекта queueClient. Если получающий вызов достигает предела ожидания, либо потому, что вы использовали перегрузку, которая предоставляет временной интервал при получении, или он достигает значения по умолчанию, Null просто возвращается. Это не считается исключением, поэтому политика повторных попыток не влечет за собой.

К сожалению, я считаю, что вам нужно закодировать свой экспоненциальный откат для фактической обработки. Однако есть множество примеров.

И да, вы можете установить эту политику повтора как на QueueClient, так и на SubscriptionClient.

+1

Майк, вы утверждаете, что не принимаете участие в повторной попытке. Операция получения возвращает null или сообщение, а затем вам нужно будет снова позвонить, чтобы вы получили следующее сообщение. Повторная политика предназначена для обработки ошибок и повторения этих операций, таких как заполнение сообщений, отправка сообщений или создание очереди и т. Д. –

+0

@MikeКогда все документы и люди говорят о MaximumBackoff, но ценность? Знаете ли вы о ценности? –

+0

@NuriYILMAZ MaximumBackoff - это промежуток времени. Политика повторной попытки для служебной шины по умолчанию устанавливается RetryPolicy.Default, которая использует 30 секунд MaximumBackoff. Если вы устанавливаете это на что-то еще, вы хотите использовать значение, которое имеет наибольшее количество времени, которое вы готовы подождать между проверкой очереди на работу. – MikeWo