1

以下を理解するのに助けてください：

私はCachingConnectionFactory自分のアプリで使用しており、最初にjmsテスト中にそれを使用して、保証された配信、ロールバック/コミットなどのjms構成をテストしました。

JmsTemplate送信DefaultMessageListenerContainer時と配信時にSpringを使用しています。

  1. 複数のテストメソッドを使用してシーケンシャルに実行する場合、これは難しい/不可能であることに気付きました。例：テストメソッドでは、AIがメッセージリスナー（コンシューマー側）で例外をスローし、再試行が発生します。次に、テストBが実行され、メソッドAIで別のテストが実行されますが、このテストを開始しても、テストAから再試行メッセージが表示されます。これは明らかに望ましくありません。テストの合間にjmxを介してキューをパージしますが、それでもこれらの再試行を受け取ります：（...検索してデバッグしました...パージが正しく行われたと確信している場合でも、なぜこれらの再試行が発生し続けるのか正確にはわかりません。たぶん、セッションのどこかにすでにキャッシュされていたのかもしれません...わかりません。

  2. SingleConnectionFactoryテスト中に使用する必要があることがわかりました。この接続ファクトリを使用すると、再試行はなくなりますが、その理由はよくわかりません。なんで？（Spring refからの）接続を1つだけ使用していることを理解し、送信アクションごとにコンシューマーが削除されることに気付きましたが、これらの再試行で何が起こるかはよくわかりません：（...何か考えはありますか？（マルチスレッドの動作のためにデバッグが難しく、Web上でそれに関する適切な情報を見つけるのが困難です）また、CachingConnectionFactory 1つのセッションキャッシュサイズ1のみで使用しても、再試行の問題は解決しませんでした。

ありがとう

4

2 に答える 2

1

おそらく、組み込みブローカーを使用して、各テストの間にそれを開始/停止し、deleteAllMessagesOnStartupがtrueに設定されていることを確認し、ブローカーがストアをパージする必要があります。これにより、各テストのスレートがきれいになります。ActiveMQの単体テストを確認することも有益かもしれません。これは、自動テストでブローカーを使用する方法の例の良い情報源です。

于 2011-03-16T14:40:57.180 に答える
1

修正するのは簡単なことではありません。テストの合間にメッセージを削除してください。私は上記のように多くのことを試しました：ブローカーと、メッセージを消費するために使用するSpringのクラスDefaultMessageListenerContainerを停止/開始します。DefaultMessageListenerContainerのキャッシュレベルをConsumerに設定して、コンシューマーがキャッシュされるようにするまでは、すべて機能しているようです。これは、redeliveryPolicyが機能するために必要です。ただし、これにより、DefaultMessageListenerContainerによってキャッシュされたすべてのメッセージが、見た目どおりに混乱しました。

最後に、次のテストを開始できるように、テスト後にすべてのメッセージを単純に消費することで解決しました（1秒待って、すべてOKを消費します）。

于 2011-03-17T13:08:55.890 に答える