WCF を使用して Web サービスを実装しています。この Web サービスには、各サービスのヘルス モニターとして「ping」機能が必要です。この機能は IDispatchMessageInspector を使用して実装されており、サービスのエンドポイントごとに構成されています。これは、「ping」を実際のサービス コードにできるだけ近づけるというビジネス上の要件によるものです。同時に、これを各サービス実装のコードに結び付けたくはありませんでした。IDispatchMessageInspector が適しているようです。
このサービスは、Request-Reply MEP を使用します。各要求メッセージには、必要な処理を指定する要素が含まれています。次に、サービスはこの値を使用して、メッセージ内のデータを処理する方法を決定します。同じ要素を使用して、リクエスト メッセージを「ハートビート」チェックとして定義します。
「ping」メッセージ インスペクターは、AfterReceiveRequest() メソッドで要求メッセージを前処理し、要求が「ハートビート」であると判断した場合、正しい応答を生成し、それを BeforeSendReply() メソッドに渡します。 AfterReceiveRequest() から返される相関オブジェクト。参照による AfterReceiveRequest() の要求メッセージ パラメータは、サービス実装コードによってメッセージが処理されないように null に設定されます。
リクエスト メッセージを null に設定する手法は、私が覚えていない、または URL を見つけることができない Web サイトまたはブログで見つかりました。この手法は単独でうまく機能し、「ハートビート」リクエストの場合にサービス実装コードが実行されるのを防ぐことができます。
残念ながら、メッセージ インスペクターで要求メッセージを null に設定すると、WCF ランタイムは常に NullReferenceException をスローします。スタック トレースから、ランタイムが引き続きメッセージ オブジェクト (「Ping」メッセージ インスペクターを通過した後は null になる) をディスパッチャーに渡し、ディスパッチャーが null メッセージ オブジェクトを逆シリアル化しようとすると、NullReferenceException が発生することがわかりました。
ただし、私のシステムは IErrorHandler も実装して、サービスで未処理の例外をキャッチしてログに記録します。これは、「ハートビート」リクエストが成功するたびに NullReferenceException のログ エントリが生成され、「ハートビート」が 1 分おきに発生する可能性があることを意味します。
質問 ：
「Ping」がリクエストをnullに設定することによってサービス実装コードの実行を妨げているときにスローされる「役に立たない」NullReferenceExceptionのロギングを防ぐにはどうすればよいですか。
よろしくお願いします。
~hg