JMS 2.0:トピックの共有-耐久性-コンシューマーと非同期-キューのコンシューマー。参照。公式GlassFish4.0 docs / javaee-tutorial Java EE 7

ヴィシャルパネサール

参照:公式GlassFish 4.0 docs / javaee-tutorial Java EE 7

まず、destination-type of:topicから始めましょう。GlassFish 4.0チュートリアルに従って、セクション「46.4高性能でスケーラブルなJMSアプリケーションの作成」:

このセクションでは、JMS APIを使用して、大量のメッセージを堅牢に処理できるアプリケーションを作成する方法について説明します。

サブセクション「46.4.2共有耐久性サブスクリプションの使用」:

SharedDurableSubscriberExample.javaクライアントは、共有永続サブスクリプションの使用方法を示しています。共有永続サブスクリプションが永続サブスクリプションの利点(クライアントがアクティブでない場合でもサブスクリプションはアクティブのまま)と共有コンシューマーの利点(メッセージの負荷を複数のクライアント間で分割できる)をどのように組み合わせるかを示します。

私たちは「あたりのように、この例を実行すると46.4.2.1まで実行ShareDurableSubscriberExampleとプロデューサークライアント」、それは私たちに、キューの先型の前の例と同じ効果/機能を提供します:私たちは、「従うならば46.2.6.2まで実行AsynchConsumerとプロデューサークライアント」、5以降をポイントし、2つのコンシューマーターミナルウィンドウと1つのプロデューサーターミナルウィンドウを使用してわずかに変更します。

はい、セクション「45.2.2.2パブリッシュ/サブスクライブメッセージングスタイル」には次の内容が記載されています。

JMS APIは、コンシューマーがアクティブでないときに送信されたメッセージを受信する永続的なサブスクリプションをアプリケーションが作成できるようにすることで、この要件をある程度緩和します。耐久性のあるサブスクリプションは、キューの柔軟性と信頼性を提供しますが、それでもクライアントは多くの受信者にメッセージを送信できます。

..そしてとにかくセクション「46.4高性能でスケーラブルな書き込み..」の例はキュースタイルです–コンシューマーごとに1つのメッセージ:

トピックサブスクリプションに追加された各メッセージは、キューに追加された各メッセージが1人のコンシューマーのみによって受信されるのと同様に、1人のコンシューマーによってのみ受信されます。

正確な技術的回答は何ですか:この例では、トピックでのShared-Durable-Consumerの使用が、「高性能でスケーラブルなJMSアプリケーション」とキューでのAsynchronous-Consumerの使用であると想定されている理由です。

giscard.faria

同じ問題が気になっていたので、次のリンクを見つけましたJohn Amentがあなたに正しい応答を与えたことを理解しています。おそらく、完全に理解するには短すぎたのかもしれません。

基本的に、トピックを作成するときは、サブスクライブされたコンシューマーのみがそのメッセージを受信すると想定しています。ただし、このようなメッセージの処理には、重い処理が必要になる場合があります。このような場合、必要な数のスレッドを使用して共有トピックを作成できます。

キューを使ってみませんか?答えは非常に簡単です。キューを使用する場合、そのようなメッセージを処理できるのは1人のコンシューマーだけです。

明確にするために、例を示します。連邦裁判所が毎日数千の文を公開していて、それに依存する3つの異なるアプリケーションがあるとします。

アプリケーションAは文をデータベースにコピーするだけです。アプリケーションBは文を解析し、以前に保存されたすべての文の周りの人々の間のすべての関係を見つけようとします。アプリケーションCは文を解析し、以前に保存されたすべての文の周りの企業間のすべての関係を見つけようとします。

アプリケーションA、B、およびCがサブスクライブされる文にトピックを使用できます。ただし、アプリケーションAがメッセージを非常に迅速に処理できることは簡単にわかりますが、アプリケーションBとCには時間がかかる場合があります。利用可能なソリューションは、アプリケーションBの共有サブスクリプションとアプリケーションCの共有サブスクリプションを作成することで構成されるため、複数のスレッドがそれぞれに同時に作用する可能性があります...

...もちろん、他の解決策もあります。たとえば、非共有トピック(つまり通常のトピック)を使用して、受信したすべてのメッセージをに投稿し、ArrayBlockingQueueしばらくしてからスレッドのプールによって処理されるようにすることができます。そのような決定では、開発者がキューの処理について心配することになります。

これがお役に立てば幸いです。

この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。

侵害の場合は、連絡してください[email protected]

編集
0

コメントを追加

0

関連記事

Related 関連記事

ホットタグ

アーカイブ