私は最近、JMS、Spring (および TIBCO EMS) の接続、セッション、コンシューマー、プロデューサーに関するベスト プラクティスについて多くのことを読みました。
春の世界で働くとき、一般的な知恵は
- 消費/受信フローの場合- を
AbstractMessageListenerContainer多数のコンシューマー/スレッドで使用します。 - フローの生成/公開用- の
CachingConnectionFactory下にあるを使用JmsTemplateして、ブローカーへの単一の接続を維持し、セッションとプロデューサーをキャッシュします。
プロデュース/パブリッシュのために、これは私の（大規模な）サーバーアプリケーションが現在行っていることです。以前は、ローコネクションファクトリを使用しているため、パブリッシュするすべてのメッセージに対して新しい接続/セッション/プロデューサーを作成していました（悪い！）JmsTemplate. 以前の動作では、ブローカーで数千の接続が作成され、高ピーク時に短時間で閉じられ、結果としてソケット/ファイル ハンドルの制限に達することさえありました。
ただし、このモデルに切り替えると、ブローカーへの単一の TCP 接続を使用する場合のパフォーマンスの制限/考慮事項を理解するのに苦労します。JMS プロバイダーは、マルチスレッドの方法などで使用できるようにすることが期待されていることを理解していますが、実際的な観点からは
- それはただの 1 つの TCP 接続です
- JMS プロバイダーは、パイプの書き込みをある程度調整する必要があるため、内部プロトコルにチャンクが含まれていても、インターリーブされた寄せ集めにならないようにする必要があります。
- 確かにこれには、単一の接続を使用するスレッド/セッション間の競合が含まれます
- 特定のネットワーク セマンティクス (ブローカーへの待ち時間が長い? スループットが不安定?) では、単一の接続は理想的ではありませんか?
私がある程度正しい軌道に乗っているという前提で
- 基本的な接続がどのように機能し、JMS プロバイダーによって共有されるかを誤解しているのでしょうか?
- 接続を増やすことで問題が軽減されるのか、それとも単に競合をブローカーに移すだけなのか?
- 誰かが共有できるような限界に達した実際の経験がありますか? 特定のメッセージまたはネットワークのスループット、または接続を並行して共有するスレッド/セッションの数によって引き起こされる場合もあります
- 単一接続のシナリオで、非常に大きなメッセージを書き込むセッションが小さなメッセージを書き込む他のセッションをブロックすることに注意する必要がありますか?
他のブローカーとの経験や主題に関するより多くの読書への考えや指針をいただければ幸いです.