0

着信メッセージを処理する「MessageReader」pojo クラスをセットアップする以下の構成があります。これは構成されているため問題なく動作していますが、Spring Integration の経験があまりないため、下で何が起こっているのか、監視できるかどうかについていくつかの基本的な質問があります。

  1. 基になるメッセージ リスナー コンテナーがメッセージのキューをポーリングする頻度に関するドキュメントを見つけることができません。何か不足していますか？以下の構成を正しく理解していれば、デフォルトで「DefaultMessageListenerContainer」が使用されます。クラスが AbstractPollingMessageListenerConainer を拡張していることがわかります。receiveTimeout は表示されますが、ポーリング間隔を指定するものは何も表示されません。そのような設定はありますか？以下に示すように構成してテストすると、かなり瞬時に見えます。私たちのニーズはそれほど積極的ではありません。キューが 30 秒ごとにポーリングされていれば問題ありません。
  2. コンテナーが起動してキューでメッセージを検索したときに (何も見つからない場合でも) ログに記録できる方法 (おそらく単純に log4j 設定) はありますか? 私たちの維持チームは、メッセージが送信されていない場合でも、プロセスが「実行中」であることを確認できるようにしたいと考えています。つまり、コンテナーがハングした可能性がある場合のトラブルシューティングの方法が必要です。これは、メッセージが送信されたと思われるが受信されていない場合に、ハングしたスレッドを除外するための単なるツールです。

以下のようにデフォルトを受け入れるのではなく、コンテナーを構成する必要があるかもしれないことを認識していますが、上記のことを達成できればそれで問題ありませんか??

<int:channel id="inboundChannel" />

<jms:message-driven-channel-adapter 
  connection-factory="myConnectionFactory" 
  destination="queue" channel="inboundChannel" />

<int:service-activator input-channel="inboundChannel">
  <bean class="com.myapp.MessageReader" />
</int:service-activator>
4

2 に答える 2

0

コンテナーはメッセージ駆動型です。プロバイダーのクライアント ライブラリでブロックされたスレッド (複数可) が常にあり、新しいメッセージが到着するのを待っています。キューをポーリングするのではなく、クライアントをポーリングします。受信タイムアウト (デフォルトは 5 秒) は、コンテナーが stop() に反応できるようにするためのものです (そうしないと、スレッドはクライアントでブロックされ、中断する方法はありません - クライアントの実装によって異なります)。

TRACE デバッグをオンにすると、このアクティビティが表示されますが、これは毎回ブローカーへの往復があるという意味ではなく、ブローカーから新しいメッセージが到着したかどうかをクライアントに尋ねるだけであることを覚えておいてください。

コンテナーがコンシューマーを作成すると、ブローカーはそれを認識し、メッセージを直接送信します。キュー自体のポーリングはありません。

于 2013-09-04T15:04:23.153 に答える
0

メッセージ リスナーを使用している場合は、受信コールバック関数を定義するだけで、受信タスクをライブラリに委譲します。論理的または設計的な観点から、ポーリングしていません。関数は「すぐに」呼び出されます (リアルタイムではありませんが、実際には 30 秒よりも小さくする必要があります)。

監視に関しては、ログメッセージだけに頼ることはありません。通信チャネルも確認するには、メッセージ リスナーに「ping」リクエストを送信することをお勧めします。別のキューに「pong」メッセージを送信することで応答できます (監視専用)。監視システムは、キュー内の待機中のメッセージの現在の数と、ping/pong の往復時間と合わせて、オペレーティング システムがそれを確認する必要があるかどうかを判断できます。

于 2013-09-04T16:16:30.263 に答える