Служебная шина Azure: временные ошибки (исключения), полученные через насос сообщений со встроенной политикой повторных попыток. Зачем?

Question

Я читал о модели программирования событий, управляемой событиями, представленной в апреле 2013 года, событии OnMessageOptions.ExceptionReceived, встроенном RetryPolicy (май 2013 года, RetryPolicy.Default), прикладном блоке обработки временных ошибок (2011), который устарел и многое другое (см. внизу).

Я отслеживал исключения, полученные через насос сообщений для временных ошибок, и получаю ежедневные исключения MessagingCommunicationExceptions. В этой статье (Обновлено: 16 сентября 2014 г.) рекомендуется следующее:

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

Насколько я понимаю, после версии 2.1 (2013) нет необходимости писать дополнительный код для обработки ошибок переходных процессов в служебной шине. Если моя предпосылка не верна, почему я получаю ошибки переходного процесса каждый день? Следует ли игнорировать исключения, полученные через насос сообщений? Если игнорировать, я могу только предположить, что неожиданные исключения также будут игнорироваться... и я не хочу, чтобы это произошло, конечно.

Версия Microsoft.ServiceBus: 2.4.0.0

Также представляет интерес: обновление служебной шины Windows Azure с 1.x до 2.0 - политика повторных попыток, введение модели программирования сообщений на основе событий для служебной шины Windows Azure, что нового в выпуске Azure SDK 2.0 (апрель 2013 г.), что нового в выпуск служебной шины 2.1 (май 2013 г.), временная обработка ошибок.

Answer 1

Официально ответил здесь. Короче говоря, исключения повторяются для целей мониторинга после повторных попыток. В длинных:

Временные исключения, которые вы получаете от обратного вызова ExceptionHandler, означают, что эти исключения скопированы после повторных попыток. Вы должны просто войти в систему для целей мониторинга. Примите меры, если вам нужно. Например, если ваш клиент теряет подключение к сети, вы должны ожидать большое количество исключений связи, проходящих через обработчик. В таких случаях вам может потребоваться принять соответствующие меры для исправления ситуации. Так что ответ на вопрос "должен ли я их игнорировать?" действительно зависит от условий. - Серкант Карака, Microsoft