問題タブ [tibco-ems]

XAトランザクションで遊んでいます。現時点では、それらを JMS と統合しようとしています。しかし、代わりに、失敗したセマフォの取得に関する不可解な例外がいくつか発生します。

ここに私のMDBがあります:

アクティベーション構成:

キュー構成:

したがって、メッセージをキューに送信するたびに、次のような例外が発生します。

興味深いのは、MDB が呼び出されることです。メソッドにブレークポイントを設定しておりonMessage、メッセージが送信されるとonMessageメソッドで停止します。しかし同時に、server.log に上記のような例外が 7 つほど記録されています。

もう 1 つの興味深い点はonMessage、実行中に例外が発生しないにもかかわらず、2 回呼び出されることです。

この問題をググってみました。私が見つけた最も一般的な解決策は、ejb プール サイズを増やすことでした。これは、JMSプリフェッチ サイズが EJBプール サイズよりも小さい場合、すべてのメッセージを処理するのに十分な EJB がプールにない可能性があるというものでした。そのため、タイムアウト後に例外がスローされます。しかし、ご覧のとおり、これはまったく別のものです。例外のstrictTimeout値が -1なのはなぜですか? XAトランザクションと関係があると思います。

私は TIBCO の JMS キューの作業を始めたばかりで、次のことを知りたいです。

複数の部門を持つ会社を考えてみましょう

• 部門A
• 部門B
• 部門C

外部ソースから受信したメッセージは、さまざまな部門で使用する必要があります。各部門のクライアントには、tibco 静的ブリッジ キューまたはトピックに関する静的持続性が必要ですか?

それぞれの長所/短所は何ですか?

私が親しんでいるTIBCO EMSには、「デスティネーションブリッジ」という機能があります。

2 番目の宛先が最初の宛先のクライアントになるように、キューとトピックをブリッジ (リンク) できます。(キューからキューへ、トピックからキューへ、キューからトピックへ、トピックからトピックへ) たとえば、トピックをキューにブリッジすることができます。これは本質的に、トピックに送信されたメッセージの永続的なサブスクライバーになります。クライアントは、トピックにサブスクライブするか、キューから読み取ることができます。この例は、複数のクライアント (キューのリーダー) の pub/sub の読み取りの負荷を分散する方法です。この「ブリッジ」機能には、メッセージ セレクターと宛先名のワイルドカードも含まれます。

したがって、QUEUE X は、条件 CUST_ID (JMS 属性)>30 で TOPIC.* のクライアントになることができます。その場合、基準に適合する TOPIC.A または TOPIC.B に送信されたすべてのメッセージは、最終的に QUEUE X に送られます。これには、単純な EMS 構成だけが含まれます。

私は Websphere MQ について十分な知識がなく、同様の動作が必要です。MQ 以外で処理プログラムを開発する必要がありますか? それとも、製品内の機能で十分ですか?

注: 私はすでに MQ のドキュメントを調べて、「エイリアス キュー」機能を見つけました。この機能は実際には「ショートカット キュー」と呼ばれる必要があり、宛先が 2 つ含まれていないため、役に立たないと思います...

ありがとう！

編集：参考までに、MQでこれを有効にするコマンド（DEF SUB）はここに文書化されています

編集 2: 選択された回答は、TIBCO EMS の「Destination bridge」機能の「Topic -> Queue」パターンをカバーしています。「Q->Q」、「T->T」および「Q->T」パターンはここではカバーされていないことに注意してください。

tibco の学習に興味があります。YouTube でいくつかの優れたビデオを見つけましたが、それらはすべてチュートリアルにすぎません。tibco が組織で使用される理由と、組織にとってどのように役立つかについてのビデオはありません。Web サービスでいくつかのチュートリアルを見ましたが、はいJava を使用して同じことができます。

私は基本的にJavaのバックグラウンドから来ており、Webサービスでかなりの経験を持っています.Webサービスに関するいくつかのチュートリアルをtibcoで見ましたが、それらは石鹸パレットを使用しています.

Web サービスだけでなく、JDBC パレットのチュートリアルも見ました。同じ仕事をします。

一般的に、tibco が使用される理由と、組織でどのように役立つかを教えてください。

私はこのツールを初めて使用します

テスト メッセージを EMS トピックに発行したいと考えており、いくつかの指示を使用できます。これまでのところ、私はこれを行うことができました

以下を生成します。トピック「topic1」またはキュー「Q1」にメッセージを発行する方法

Tibco EMS は、サーバー側のホット バックアップ構成でフォールト トレランスを提供することを認識しています。詳しくは、ユーザー ガイド、この回答、およびこちらを参照してください。

しかし、クライアント側では、Tibco EMS はフォールト トレラントなクライアントにすぐに使用できるソリューションを提供しますか? 例: トピックでは、Sports.F1.PitStop2 つのクライアント (server1、server2) がパブリッシャーとして登録されます。server1 で何か問題が発生した場合 (つまり、server1 のパブリッシャーがダウンした場合)、server2 はトピックでシームレスにパブリッシュを続行するという考えです。問題は、Tibco EMS がそのようなクライアント側のフォールト トレランス機能を提供するかどうかです。