Реализация функциональности "Ping" с помощью инспектора сообщений заставляет среду выполнения WCF генерировать исключение NullReferenceException
Я использую WCF для реализации веб-службы. Для этого веб-сервиса требуется функция ping в качестве монитора работоспособности для каждого сервиса. Эта функциональность была реализована с использованием IDispatchMessageInspector и настраивается для каждой конечной точки службы. Это связано с деловым требованием, чтобы пинг был как можно ближе к фактическому коду обслуживания. В то же время я не хотел привязывать его к коду каждой реализации службы, и IDispatchMessageInspector, кажется, подходит.
Служба использует запрос-ответ MEP. Каждое сообщение запроса содержит элемент, который указывает, какая обработка требуется. Затем служба будет использовать это значение, чтобы определить, как обрабатывать данные в сообщении. Этот же элемент используется для определения сообщения запроса в качестве проверки "сердцебиения".
Инспектор сообщений "ping" предварительно обработает сообщение запроса в методе AfterReceiveRequest(), и если он определит, что запрос является "сердцебиением", то он сгенерирует правильный ответ и передаст его методу BeforeSendReply () через объект корреляции, возвращаемый из AfterReceiveRequest (). Параметр сообщения запроса метода AfterReceiveRequest(), который является ссылкой, затем устанавливается равным нулю, чтобы предотвратить обработку сообщения кодом реализации службы.
Техника установки сообщения запроса на ноль была найдена на веб-сайте или в блоге, который я не могу вспомнить или найти URL. Эта методика прекрасно работает сама по себе, и я могу предотвратить выполнение кода реализации службы, если это "сердцебиение" запроса.
К сожалению, установка для сообщения запроса значения NULL в инспекторе сообщений приведет к тому, что среда выполнения WCF будет всегда выдавать исключение NullReferenceException. Из трассировки стека я понимаю, что среда выполнения по-прежнему будет передавать объект сообщения (который будет нулевым после прохождения инспектора сообщений "Ping") диспетчеру, и когда диспетчер пытается десериализовать объект сообщения с нулевым значением, вызывает исключение NullReferenceException.
Тем не менее, моя система также реализует IErrorHandler, чтобы перехватывать любые необработанные исключения в сервисе и регистрировать его. Это означает, что каждый успешный запрос "heartbeat" будет генерировать запись в журнале для исключения NullReferenceException, и "heartbeat" может быть частым, как каждую минуту.
Вопрос:
Что можно сделать, чтобы предотвратить ведение журнала "бесполезного" исключения NullReferenceException, возникающего, когда "Ping" препятствует запуску кода реализации службы, задав для запроса значение null.
Спасибо заранее.
~ рт.ст.
1 ответ
Не самое изящное решение, но потенциальные обходные пути (которые я не проверял), но там, где вы обнаруживаете свои вызовы ping в коде инспектора, вы не могли бы бросить свой собственный тип исключительной ситуации, например PingRequestException, и обработать это, когда он возвращается клиенту? Это позволит избежать попадания в код времени выполнения WCF, что позволит избежать регистрации необработанных исключений.
В противном случае вы можете попытаться использовать базовый сервис, унаследованный всеми вашими сервисами (другая сторона кода времени выполнения wcf), который обнаруживает и обрабатывает запросы ping в конструкторе, прежде чем выполнить фактический код сервиса.