MOMorの背後にある考え方は理解していると思いますMessage Queuesが、次の実装の詳細についてはわかりません。
ディスパッチャとして機能する要素が 1 つあるため、(信頼性が要件であるため)すべてのクライアントに対して永続的な TCP 接続が必要です。
そのため、NクライアントNの場合、現在通信がない場合でも、常に接続を開いています (N は任意に大きくなります)。
これは正しいです？
これは、人気のあるフレームワークの堅牢な実装によってどのように処理されますか?
質問する
192 次
2 に答える
1
クライアントがリアルタイムでメッセージを受信したいと仮定すると、はい、JMS サーバーへのアクティブで持続的な接続が必要です。
スタンドアロン JMS クライアントは専用接続を使用するため、1 クライアント = 1 接続です。一方、アプリ サーバー内で実行されるメッセージ駆動型 Bean は、通常アプリ サーバーで構成可能なプールから接続オブジェクトとセッション オブジェクトを再利用して、これらのオブジェクトの数を制限しますが、接続は「常に」接続されます。 JMS サーバーへ。アプリ サーバーでの実装方法は製品ごとに異なります。したがって、アプリケーション サーバーで、MDB の消費メッセージが 20 ある場合でも、最大 10 の接続を使用するようにプールを構成すると、確実に 10 の接続のみが開かれます。
非アクティブな接続
キュー クライアントはサーバーに接続する必要はありませんが、メッセージはキューに蓄積され、クライアントが接続すると、すべてのメッセージが順番に配信されます。
接続のドロップ
接続がドロップされた場合、クライアント (JMS サーバーではなくコンテナー) は、メッセージを再度消費する前に再接続する必要があります。
JMS サーバーへの接続数が気になりますか? スタンドアロンの JMS クライアントまたは MDB のことですか?
于 2013-07-31T00:02:16.687 に答える