1

私が取り組んでいる JMS 1.1 (TibcoJms 4.4.1) を使用するレガシー システムでは、JMS キュー (トピックではない) がサーバー側に確立されています。これは、PTP モードの通信用です。メッセージ項目は、サーバーによって常にキューに入れられます。

私が達成したいのは、クライアント側の複数のスレッドでこれらのデータをポーリングすることです。各スレッドは、特定の属性値を持つメッセージを処理する必要があります。

これを行う 1 つの方法は、そのキューをリッスンする MessageListener を実装することです。これは、受信したメッセージをクライアント側の各スレッドに配布 (PUSH) して処理する「スイッチ」として機能します。または、サーバー上のそのキューでリッスンする MessageListener を実装し、受信したメッセージをクライアントの新しいキューに入れると、各スレッドがクライアント側のキューに対して POLL を実行できます。

いずれにせよ、スレッド間で共有されるクライアント側で追加のデータ構造セットを使用する必要があると思います。

私の質問は、クライアント側のプロセッサ スレッドとサーバー上のそのキューの間の直接通信を含む、より直接的なアプローチがあるかどうかです。これは、トピックへの複数のサブスクライバーに似ています(ただし、各サブスクライバーは実際には「負荷を共有」するのではなく、同じ負荷を取得します。それは私の目的には受け入れられます)。

この状況で誰もが提案できる良い一般的な慣行はありますか?

4

1 に答える 1

2

直接接続の概念は、JMS 実装が実際にどのようにコーディングされているかによって異なります。パブサブまたはポイントツーポイントについて、本質的により直接的な接続はありません。それは本当に実装に依存します。

使用する API の選択に追加します。複数のスレッドがある場合は、これらが割り込み駆動型であるかどうかを検討し、それぞれにセレクターを持つ複数のメッセージ リスナーを使用できるようにします。または、セレクターを使用して再度同期受信を使用します。

ただし、JMS プロバイダーはデータベースではないため、セレクターを頻繁に使用することはお勧めできません。すべてのプロパティにインデックスがないだけです。これが懸念される場合は、ローカル分散データ構造が必要になります。

あなたが言ったことに基づいて、パブサブモデルが役立つかどうかわかりません。各インストール メッセージを取得する必要があるのは 1 つのコンシューマーだけのようです。

于 2014-09-21T09:47:17.670 に答える