2

SpringDefaultMessageListenerContainerのを使用してJMSメッセージを受信すると、2に設定しても、JMSメッセージが再配信されません。sessionAcknowledgeMode

RuntimeException私のJavaBean内の場合onMessage()、メッセージはJMSプロバイダー（ActiveMQ）内で確認応答されず、キューで保留中のままになります。ただし、再配信されることはありません。これは、Springが呼び出すことはないという事実が原因だと思います。これは、 ActiveMQのドキュメントsession.recover()によると、再配信を行うために必要です。

DefaultMessageListenerContainerRuntimeExceptionsの場合に呼び出すように構成する方法のヒントを教えてもらえますsession.recover()か？

よろしく、
マーティン

4

1 に答える 1

3

Session.CLIENT_ACKNOWLEDGEであるsessionAcknowledgeMode2を使用していることを示します。次のステートメントは、AbstractMessageListenerContainerJavadocから直接取得されます。

  • "CLIENT_ACKNOWLEDGE"：リスナーの実行が成功した後のメッセージの自動確認。例外がスローされた場合の再配信はありません。

したがって、問題はSpring DMLCにあるのではなく、実行時例外がスローされたときにSession.recover（）を呼び出す機能です。リスナーのonMessage（）メソッドでtry / catchを使用して、Session.recover（）を自分で呼び出すことにより、実行時例外を処理することは可能ですか？

アップデート：

あなたはボイラープレートコードについて良い点を述べています。それは多くの場所に散らばり、リファクタリングを懇願します。そのようなコードを抽象化することはできませんか？これは一般的な解決策です。適切な処理を伴うtry/catchを含むメソッドを使用して抽象親クラスを作成すると、うまくいくはずです。次に、親クラスを拡張して、必要な数のカスタムプロセッサを実装します。その後、Springアプリのコンテキストを使用して、適切な方法でプロセッサを相互に接続することもできます。

Spring固有のコードはどこでも実行できるため、アプリケーションに問題を追加したことはありません。これは、私がSpringを使い始めたときの私にとって重要でした。これは単一のアプリサーバーやサーブレットコンテナに固有のものではないため、com.ibmまたはcom.oracleをソースコードにインポートした場合のように、Springを使用して自分自身を隅にコーディングしているわけではありません。実際、私は1つのMOMでSpring JMS APIを使用し、JMS接続ファクトリ定義以外は何も変更せずに別のMOMに切り替えました。

于 2010-02-03T16:40:18.540 に答える