2011-08-09 16 views
3

私はすべての着信要求をキューに入れ、後で処理するメッセージベースのサービスを開発中です。エラーを処理するためのベストプラクティスは何ですか。たとえば、次のシステムに情報を送信するときに、不正な形式のメッセージまたは通信エラーが発生した場合。Spring JMSによるエラー処理のベストプラクティス

トランザクションを使用することで後者に対処することができますが、メッセージの形式が誤っている場合は、再試行または保持することはありません。さまざまなシナリオに対して異なるエラー処理を実装する考えはありますか?そうであれば、どうすればよいでしょうか?

ありがとうございます!

答えて

9

あなたは正しい方向にいると思います。 3つの一般的なパターンは、ここにあります:

  • メッセージが有効であり、通常の処理が適用され

を処理することができます。

  • メッセージは有効ですが、おそらく、あなたがメッセージを処理する必要があるいくつかのリソースが利用できない今

を処理することはできません。この場合、トランザクションをrollbackOnlyに設定すると、メッセージが再配信されます。うまくいけば、あなたのJMS実装はの再配信が遅れたという考え方をサポートしています。 MIAリソースが再び利用可能になるまで同じメッセージを何千回も再処理しないようにしてください。そうでない場合(私はWebSphere MQを見ています)、通常は、メッセージを一時的に処理できないメッセージとコミット用に予約された別のJMSキューにプッシュします。 MIAリソースがオンラインに戻ったとき、私は手続き的にそのキューからすべてのメッセージを読んで、それらが完了するまで処理されたメインの[元の]キューに書き戻します。

  • メッセージが無効である

は例外を抑制し、トランザクションをコミットします。あなたはそのメッセージをもう一度見ることはありません。無効なメッセージの監査証跡を保持するには:

  • は、それが後で調べることができ悪いキューに無効なメッセージをオフに書きます。
  • ログメッセージ
  • の中身うち主なポイントは、しかし、確認することです

無効(タイプ別に、ソース・キュー、解析エラーなど)メッセージのJMXカウンタをキープを知っている場合は、となることはありません。そのメッセージを処理できるようにしてください。

+0

非常に便利な回答ありがとうございます!これは良いアプローチのように思えます。これをSpringで実装した経験はありますか?今は、DefaultMessageListenerContainerを大いに中継しています。これにより、各イベントで提案されたアクションを実行するのが少し難しくなります。しかし、私は低レベルに行きたくはありません。何か案は? – Kristoffer

関連する問題