Какие исключения дают повторы в Azure Service Bus SubscriptionClient?

Question

Я слишком быстро борюсь с сообщениями, попадающими в очередь недоставленных писем. Я указал политику ExponentialRetry следующим образом:

        private readonly RetryExponential _retryPolicy = new RetryExponential(
            TimeSpan.FromSeconds(1),
            TimeSpan.FromMinutes(20),
            10);

Когда SQL Server временно не работает ("because its replica role is RESOLVING which does not allow connections. Try the operation again later."), тогда сообщения попадают в очередь недоставленных сообщений без повторных попыток.

Что мне делать, чтобы получить повторные попытки?

Я просмотрел исходный код для SDK , и кажется, что только временное исключение ServiceBusException дает повторные попытки, но я нахожу, что вполнестранно.

ОБНОВЛЕНИЕ:

После обсуждения с коллегами и просмотра более подробных сведений в Application Insights я вижу, что на самом деле он повторил попытку 10 раз, но всев течение 2 секунд. Это максимальное количество доставки, установленное на самой подписке, а не на клиенте. Эта доставка не зависит от экспоненциального отката, как я хочу и нуждаюсь.

Answer 1

Я посмотрел в исходном коде для SDK, и кажется, что только переходный ServiceBusException дает повторные попытки, но я нахожу это довольно странным.

Это правильно и соответствует дизайну. Если ошибка является временной ошибкой (проблема с подключением, регулирование и т. Д.), Клиент повторяет попытку, используя RetryPolicy. В противном случае повторная попытка не поможет, поэтому повторная попытка той же операции не поможет.

В вашем конкретном случае - ваш код выполняется и сообщение обрабатывается. Там нет проблем между клиентом и брокером. Вот почему политика не включается. Далее вы подтверждаете, что это проблема приложения, учитывая, что сообщение повторяется вашим процессом и заканчивается в очереди недоставленных сообщений.

IЯ борюсь с сообщениями, попадающими в очередь недоставленных сообщений слишком быстро.

Вам необходимо выполнить повторную попытку приложения и его откат, чтобы сообщение не повторялось сразу несколько раз, что приводит к его мертвой букве. Эта часть может быть немного сложнее, в зависимости от того, как долго ваш сервер SQL не работает. Есть несколько вариантов:

1. Запланируйте сообщение на будущее, чтобы позволить SQL Server восстановиться. Эта опция потребует запланировать новое сообщение.
2. Отложить сообщение и обработать его позже. Это будет означать, что вам нужно вести запись отложенного сообщения SequenceNumber s. Одним из способов реализации этой опции является планирование нового сообщения с порядковым номером исходного сообщения.
3. Используйте абстракцию поверх служебной шины, которая предоставляет концепцию / функцию высокого уровня для выполнения повторных попыток, например MassTransit или NServiceBus ( Восстанавливаемость ).