問題タブ [tibco-rv]

メッセージング システムとして、Unix と Windows の両方で Tibco RVRD を使用しています。Tibco から HAWK を購入する以外に、RVRD 圧縮の前後でネットワークの使用状況を測定する方法はありますか?

数年前、TIBCOメッセージングフレームワークでTIBCO Rendezvous Cache（rvcache）を使用するプロジェクトに取り組みました。トピック/サブジェクトをキャッシュし、要求されたときにキャッシュを送信します。私が現在取り組んでいるプロジェクトでは、TIBCOをメッセージングシステムとして再び使用することを検討しています。何年も前に使っていたrvcacheについて説明しようとしていましたが、今では多くの情報を見つけることができません。それがまだ使われているのか、それとも別の名前の新しいものに置き換えられているのか、誰かが知っているのかどうか、私は興味がありました。

こんにちは、Tibco RV は初めてです。Tibco Rendezvous Concept を読んだ後でも、トランスポート パラメータ (サービス、ネットワーク、デーモン) についてまだ混乱しています。

したがって、概念的には、各マシンで実行されるデーモンは 1 つだけです。したがって、tibrvsend を使用する場合:

myDaemonローカルホストのポート 2323 を使用して、デーモン(リモートにある可能性があります) を介してネットワークにメッセージを送信しているということですcomeIPAddressか?

tibrvlisten を使用する場合:

ネットワークmyDaemonに公開された「」のポート2323からのメッセージをリッスンするために、使用可能なポート、ローカルホストで使用可能なデーモンを使用してリッスンしていることを意味しますか?someIPAddress

もう 1 つの質問は、「Tibco RV コンセプト」という本に、同じサービスを 2 つのネットワークにバインドできないと記載されていることです。プロデューサー マシンにのみ適用されますか (リスナー マシンのポートを指定していないため)。したがって、次のようにするとエラーが発生します。

と

同時に（連続してやればOKですよね？）

しかしリスナーの場合：

と

完全に大丈夫なはずですか？(それ以外の場合は、競合を避けるためにプロデューサーが互いのポート番号を知る必要があることを意味します)

概念を完全に台無しにしてしまった場合は、例を挙げて説明していただけますか?

Java アプリケーションの 2 つのインスタンス (A & B) が同じマシンで実行されており、B はactivate()コールバックに対してブロックされています。

コールバックを登録する方法は次のとおりです。

アプリケーションが時間どおりであることを確認するために、100 ミリ秒ごとにハートビートを送信しています。

なんらかの理由 (GC / ガベージ コレクションなど) で、アクティブなアプリケーション "A" がハートビートの送信に遅れた場合、"A" がまだアクティブな間にパッシブ アプリケーション "B" がすぐにアクティブ化され、"A" で非アクティブ化が呼び出されません。 . そして、アプリケーション「A」がハートビートを送信した直後に、アプリケーション「B」で非アクティブ化が呼び出されます。これにより、両方のアプリケーションが同時にアクティブになるため、数秒間誤った動作が発生します。

上記はランダムな時間に発生し、予測できません。私たちのアプリケーションは重複したメッセージを同時に発行することはできないため、これは大きな影響をもたらします。

どうすればこの問題を克服できるか教えてください。

既存のプロトコルとその詳細について、短く簡潔でありながら完全で比較的最新のビューを提供する図またはデーブルを知っていますか? （つまり、ZeroMQ、Rendez-Vous、EMS、...それらすべて！:)）。

TibcoRV と台帳ファイルでメッセージングを有効にしていることを証明しましたが、これは絶えず大きくなり、最終的にアプリが停止する原因となっています。

ボックスの完全な制御 (TibRV Web インターフェイス、台帳ファイル自体へのアクセス) を使用して、メッセージを確認していない (つまり、ACK を待機している) アプリに接続されたクライアントを使用した CMName を特定できますか?

ありがとう

奇妙な質問があります。コードの一部から始めましょう。

ご覧のとおり、Tibco Listenerオブジェクトを作成し、それをリモートデーモンにサブスクライブしてから、作成した次のTibcoListenerオブジェクトに参照を移動します。

ガベージコレクターは、_listenerが参照するため、最後のオブジェクトを除くすべてのリスナーオブジェクトを収集することを期待しています。ただし、実行結果は、すべてのリスナーオブジェクトが機能していることを示しています。

なぜ？GCがリスナーオブジェクトを収集する時間がないほどアプリケーションを十分に長く実行していないという理由だけでしょうか、それとも「孤立しているはずの」リスナーオブジェクトを参照している固有のものがあるのでしょうか。

教えてください！ありがとう。

ここのコミュニティが、TibcoRV の「tibrvlisten」と同様のコマンド ラインを介して ActiveMQ ブローカーのトピックをリッスンする方法を知っているかどうか疑問に思っていました。

ありがとう

Visual Studio 2010 でカスタム パッケージを開発しています。このパッケージは、Oracle DB に接続できます (データの読み取り、書き込み)。この機能を使用するには、Oracle.Data.Access.dll (64 ビット) とインストールされている Oracle クライアントを参照する必要があります。C:\oracle\odp.net\bin\4\フォルダの下にありました。コンソール アプリケーションを開発すると、すべて正常に動作します。しかし、パッケージ ビルダーで拡張機能を検証して保存しようとすると、次のエラーが発生します。

ファイル C:...\Oracle.Data.Access.dll からアセンブリを作成できません。ファイルは有効な .NET アセンブリではありません。

JMSまたはメッセージングは​​、異種のアプリケーションを結び付け、多くのESBおよびSOAアーキテクチャーのインフラストラクチャーを形成するのに非常に優れています。

ただし、アプリケーションAがアプリケーションBのサービスからの即時応答を必要としているとします。たとえば、注文のプロビジョニングの詳細が必要であるか、更新の即時確認が必要です。パフォーマンスの観点から、メッセージングは​​そのための適切なソリューションですか？通常、クライアントはキュー上のMoMに接続します。その後、解放されている必要のあるリスナーがメッセージを取得してサーバー側のプロセッサに転送します。このプロセッサは、応答を処理して、キューまたはトピックと要求元に送り返します。クライアントは同じプロセスに従い、それを受け取ります。メッセージサイズが大きい場合、MoMはそれも考慮に入れる必要があります。

メッセージングルートを経由するのではなく、Httpがそのようなソリューションにアクセスするためのより良いソリューションであるかどうか疑問に思いますか？多くのアプリケーションがAMQやTIBCORvdなどのMoMを使用して、即時の要求/応答に実際に使用しているのを見てきましたが、それは悪い設計であるか、それをHttpと同じにする微調整または設定です。