問題タブ [tibco-rv]

TIBCO RV .NET API（TIBCO.Rendezvous.dll）を使用しています。

パフォーマンスの観点から、 C＃のRVチャネルからメッセージを受信して​​読み取るためのより良い方法があるかどうか知っていますか？Messageタイプ（RVメッセージの論理ラッパー）が非常に重いことがわかりました。名前またはインデックスによるフィールドの取得は、特にそれを反復/高頻度の操作と見なす場合、かなり遅くなる可能性があります。

何か案は？

TIBCORendezvousとMSMQの違いを教えてください。

TIBCO-RV を使用して送信されたパケットをデコードし、ヘッダーからフィールドを引き出して、メッセージ本文をスキップする必要があります。例やドキュメントを作成できませんでした。これを行う可能性のあるオープンソースアプリケーションを知っている人はいますか?

これら 2 つのテクノロジの主な違いは何ですか? 一方には他方よりも明らかな利点がありますか?

次のコード スニペットはDaemonManager、特定の rvd に接続する Tib を作成し、その rvd のサービスを照会しようとします。

このrvd の Web インターフェイスに複数の利用可能なサービスがリストされていても、これはゼロを出力します。なぜこれが起こるのでしょうか？

私が接続しているデーモンはソフトウェアの v 7.5.1 を実行しておりrvconfig.jar、私が使用しているデーモンも v 7.5.1 のものです。

Tibco の DaemonManager を使用しているときに、問題が発生する原因はありますか?

ローカルRVDに接続すると、送信アプリケーションはネットワークの中断から保護され、メッセージ送信メソッドは、メッセージがローカルRVDプロセスに到達するのにかかる時間だけブロックします。

リモートRVDを使用すると、送信アプリケーションはネットワークの中断から保護されなくなり、メッセージ送信メソッドは、ネットワークをホップしてリモートRVDプロセスに到達するまでの時間をブロックします。

私の理解は正しいですか？リモートデーモンに関するドキュメントはあいまいです。

私は主に、送信アプリケーションの観点から、送信メッセージの信頼性とパフォーマンスがどれほど高くなるかを懸念しています。メッセージの送信（特にネットワークホップ）のためにクライアント側に不要なブロッキングを導入することは、このアプリケーションでは大したことではありません。メッセージがコンシューマーに到達する速度は、最も重要ではありません。これを念頭に置いて、リモートRVDは問題外ですか？

Java アプリケーションの場合、パフォーマンスの点で Tibco rv と Hessian を比較したいと考えています。

私が始めるための指針は高く評価されています。ありがとう。

シリアライゼーションを使用してファイルにメッセージを書き込もうとしています。メッセージは、日付とTibrvMsg(TibrvMsgは Tibco による独自のメッセージであり、このクラスはドキュメントに従ってシリアル化できません) の 2 つのフィールドで構成されています。したがって、私のカスタム メッセージは次のとおりです。

問題は、宣言していますMessage Serializableが、シリアライズできないため、シリアライズできTibrvMsgません。だから私はjava.io.NotSerializableException: com.tibco.tibrv.TibrvMsg例外を取得します。

私は、低遅延のメッセージングを必要とするアプリケーションでTIBCORVを使用しました。RVが提供する速度よりも速くメッセージを取得するために、チームが独自のソケットコードを展開する必要があるプロジェクトについて聞いたことがあります。

TIBCO RVに近いか、それよりも優れている可能性のあるツール、おそらくオープンソースはありますか？