3

2013 年 4 月に導入されたイベント ドリブン メッセージ プログラミング モデル、 OnMessageOptions.ExceptionReceived Event、組み込みのRetryPolicy (2013 年 5 月、RetryPolicy.Default)、時代遅れの一時的なエラー処理アプリケーション ブロック(2011) について読んできました。 、その他 (下を参照)。

メッセージ ポンプを介して受信した例外を監視して、一時的なエラーを検出しましたが、毎日MessagingCommunicationExceptionsを取得しています。この記事(2014 年 9 月 16 日更新) では、次のことを推奨しています。

この例外は、メッセージング クライアントから Service Bus インフラストラクチャへの接続を正常に確立できない場合に発生する可能性がある通信エラーを通知します。ほとんどの場合、ネットワーク接続が存在していれば、このエラーは一時的なものとして扱うことができます。クライアントは、このタイプの例外の原因となった操作を再試行できます。このエラーは、ターゲット ホスト名を解決できないことを示している可能性があるため、ドメイン名解決サービス (DNS) が動作しているかどうかを確認することもお勧めします。

私の理解では、バージョン 2.1 (2013) 以降の Service Bus で一時的なエラーを処理するために記述する追加のコードはありません。私の前提が間違っていない限り、なぜトランジェントエラーが毎日発生するのですか? メッセージ ポンプを介して受信した例外を無視する必要がありますか? 無視された場合、予期しない例外も無視されると想定することしかできません..もちろん、それが発生することは望ましくありません。

Microsoft.ServiceBus のバージョンは 2.4.0.0 です

また、興味深い : Windows Azure サービス バスの 1.x から 2.0 へのアップグレード - 再試行ポリシー、 Windows Azure サービス バスのイベント駆動型メッセージ プログラミング モデルの紹介 、Azure SDK 2.0 リリース (2013 年 4 月)新機能 、新機能Service Bus 2.1 リリース (2013 年 5 月)一時的な障害処理

4

1 に答える 1

5

ここで正式に回答しました。つまり、再試行後に監視目的で例外がバブルされます。長文:

ExceptionHandler コールバックから取得する一時的な例外は、再試行後にこれらの例外が発生することを意味します。監視目的でのみログに記録する必要があります。必要に応じて行動してください。たとえば、クライアントがネットワーク接続を失った場合、ハンドラーを通じて大量の通信例外が発生することが予想されます。そのような場合、問題を修正するために適切なアクションを実行する必要がある場合があります。では、「それらを無視する必要がありますか?」という質問に対する答えは、次のとおりです。本当に条件次第。- サーカント・カラカ、マイクロソフト

于 2014-11-19T19:14:08.120 に答える