問題タブ [tibco-ems]

Hermes JMS v1.4 を使用して TIBCO 8.0 EMS に接続し、キューの詳細を表示しようとしています。

同じことをすることは可能ですか？

必要な TIBCO EMS 8.0 JMS jar とその順序を教えてください。

8 つの TIBCO EMS JMS jar ファイルを追加し、設定タブで TIBCO EMS プラグインを選択しました。

プラグイン エラーが見つかりません。解決策を教えてください。

1 つの接続を介して tibco ems トピックからデータを取得する Java サーバー (jdk 1.6) があります。tibco からメッセージをプルできるというバック ログが表示され始めています。データを複数のトピックに分割し、各トピックがサーバーへの個別の接続 (同じ JMS サーバー) を取得する場合、tibco はどの程度スケールしますか。

また、サーバーを複数のサーバーに分割することもできません。

EMS WCF プラグイン (Net.Tems Listener Adapter) を使用した人はいますか?

キューまたはトピックへのリスナーの数、スレッド/最大ジョブ/フロー制御、およびキープアライブを構成するにはどうすればよいですか? WCF サービスの設定を教えてください。

IIS の WAS (Net.Tems Listener Adapter) でホストされている JMS バインディングを介して XML SOAP をリッスンする WCF サービスが動作しています。

私は最近、JMS、Spring (および TIBCO EMS) の接続、セッション、コンシューマー、プロデューサーに関するベスト プラクティスについて多くのことを読みました。

春の世界で働くとき、一般的な知恵は

• 消費/受信フローの場合- をAbstractMessageListenerContainer多数のコンシューマー/スレッドで使用します。
• フローの生成/公開用- のCachingConnectionFactory下にあるを使用JmsTemplateして、ブローカーへの単一の接続を維持し、セッションとプロデューサーをキャッシュします。

プロデュース/パブリッシュのために、これは私の（大規模な）サーバーアプリケーションが現在行っていることです。以前は、ローコネクションファクトリを使用しているため、パブリッシュするすべてのメッセージに対して新しい接続/セッション/プロデューサーを作成していました（悪い！）JmsTemplate. 以前の動作では、ブローカーで数千の接続が作成され、高ピーク時に短時間で閉じられ、結果としてソケット/ファイル ハンドルの制限に達することさえありました。

ただし、このモデルに切り替えると、ブローカーへの単一の TCP 接続を使用する場合のパフォーマンスの制限/考慮事項を理解するのに苦労します。JMS プロバイダーは、マルチスレッドの方法などで使用できるようにすることが期待されていることを理解していますが、実際的な観点からは

• それはただの 1 つの TCP 接続です
• JMS プロバイダーは、パイプの書き込みをある程度調整する必要があるため、内部プロトコルにチャンクが含まれていても、インターリーブされた寄せ集めにならないようにする必要があります。
• 確かにこれには、単一の接続を使用するスレッド/セッション間の競合が含まれます
• 特定のネットワーク セマンティクス (ブローカーへの待ち時間が長い? スループットが不安定?) では、単一の接続は理想的ではありませんか?

私がある程度正しい軌道に乗っているという前提で

• 基本的な接続がどのように機能し、JMS プロバイダーによって共有されるかを誤解しているのでしょうか?
• 接続を増やすことで問題が軽減されるのか、それとも単に競合をブローカーに移すだけなのか?
• 誰かが共有できるような限界に達した実際の経験がありますか? 特定のメッセージまたはネットワークのスループット、または接続を並行して共有するスレッド/セッションの数によって引き起こされる場合もあります
• 単一接続のシナリオで、非常に大きなメッセージを書き込むセッションが小さなメッセージを書き込む他のセッションをブロックすることに注意する必要がありますか?

他のブローカーとの経験や主題に関するより多くの読書への考えや指針をいただければ幸いです.

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

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

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

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

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

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