0

キュー (MSMQ) でメッセージをリッスンする WCF サービスがあります。HTTP ステータス コードを返す Web サーバー (REST API) に要求を送信します。

ステータス コードが 400 の範囲内にある場合、メッセージは破棄されます。アイデアは、400 範囲のエラーが成功することは決してない (未承認、不正な要求、見つからないなど) ため、再試行を続けたくないということです。

他のすべてのエラー (例: 500 - 内部サーバー エラー) については、メッセージを "再試行" キューに入れるように WCF を構成しています。再試行キューのメッセージは、一定の時間が経過すると再試行されます。サーバーが一時的にダウンしているため、しばらく待ってからもう一度試してください。

WCF の設定方法FaultExceptionでは、サービス コントラクトで をスローすると、自動的にメッセージが再試行キューに入れられます。

メッセージが 400 範囲のエラーを引き起こした場合、エラーを飲み込んでいるだけです (ログに記録するだけです)。これにより、再試行メカニズムが起動されなくなります。ただし、メッセージを配信不能キューに移動することをお勧めします。このようにして、ユーザーやシステム管理者に電子メールを送信することでエラーに対応できます。

これらの不良メッセージをすぐに配信不能キューに移動する方法はありますか?

4

2 に答える 2

1

まず、配信不能キューについて言及し続けました。この質問を投稿した時点では、WCF/MSMQ がポイズン サブキューと呼ばれるものを自動的に作成することを知りませんでした。構成された回数で配信できないメッセージは、有害なサブキューに入れられます。

私の状況では、一部のメッセージが成功しないことがわかっていたので、メッセージをすぐにキューから移動したいと考えました。

解決策は、「ポイズン」と呼ばれる 2 番目のキューを作成することでした (ポイズン サブキューと混同しないでください)。私の catch ブロックは、WCF クライアントのインスタンスを作成し、メッセージをこの有害なキューに転送します。同じクライアントを再利用して、元のキューとポイズン キューの両方に投稿できます。それぞれの構成ファイルに個別のクライアント エンドポイントを作成する必要がありました。

ServiceHostキューを読み取る2 つの別個のインスタンスを実行していました。元のServiceHostキューの は HTTP リクエストを実行し、回復不能なエラーが発生したときにメッセージをポイズン キューに転送しました。2 つ目ServiceHostは、メッセージが失われたことを記録するために電子メールを送信するだけです。

最大試行回数を超える一時的なエラーの問題もありました。WCF/MSMQ は、 というサブキューを自動的に作成します<myqueuename>;poison。WCF 経由でサブキューに直接書き込むことはできませんが、ServiceHost. メッセージがポイズン サブキューに入るたびに、元のハンドラーの catch ブロックで使用したのとまったく同じクライアントを使用して、メッセージをポイズン キューに転送するだけです。

エラー メールにスタック トレースを含める機能が必要でした。すべてのハンドラーで同じクライアントとサービス コントラクトを再利用していたため、スタック トレースを文字列として渡すことはできませんでした (すべてのデータ コントラクトに追加しない限り)。代わりに、ポイズン ハンドラーにもう一度コードを実行させようとしたところ、再び失敗し、スタック トレースが吐き出されました。

これは、私のメッセージ キューが最終的に次のようになったものです。

MyQueue
    - Queue messages
    - Retry
    - Poison
MyQueuePoison
    - Queue messages

このアプローチはかなり複雑です。WCF サービス ハンドラー内から WCF クライアントを呼び出すのは奇妙でした。また、サーバー上にもう 1 つのキューを設定し、クライアントがメッセージを転送するキューを指定するための大量の追加の構成セクションを設定することも意味していました。

于 2015-03-11T19:58:39.677 に答える