問題タブ [rmi]

Java で記述された RMI クライアント アプリケーションがあり、サーバー アプリケーションに定期的に "stay alive" メッセージを送信する必要があります。これを別のハートビート スレッドとして実装しました。このスレッドは、Stay Alive メッセージをサーバーに送信し、Thread.sleep() を使用して 15 秒間スリープします。

スレッドは高優先度に設定されています。

ただし、クライアントが実行されているボックスが大量の CPU を使用している場合、ハートビートが欠落していることがわかります。これにより、サーバーはクライアント アプリケーションが停止したと見なします。

メインスレッドに Thread.yield() 呼び出しを追加しましたが、これで問題が解決したわけではありません。

アプリケーションの実行中にハートビートが時間どおりに送信されることを保証する方法はありますか?

動的プロキシ スタブの実装が実際に舞台裏でどのように行われているかを理解したいと思います。私が読んだところによると、事前に生成されたスタブ クラスが見つからない場合、リモート オブジェクトがエクスポートされるまでに、RMI ランタイムはスタブとして機能する動的プロキシを生成します。そのスタブは RMI レジストリにバインドされ、後で RMI クライアントからアクセスできます。

問題は、スタブは実際には動的に生成されたプロキシであるため、そのクラス定義はクライアント側では利用できないのに、なぜクライアントは RMI レジストリからスタブを取得できるのでしょうか? バックグラウンドである種の動的なクラスローディングが行われているのでしょうか、それとも RMI はこれを回避するために別の手法を使用していますか?

私はマスターのキャップストーンコースを早期に受講し、C# で自分のプロジェクトを行っていますが、他の人は Java で自分のプロジェクトを行っています。このプロジェクトには 4 つのサービスがあり、サービス名をソケットにマップするネーム サーバーが必要です。インストラクターは、R​​MI を使用してこのレジストリを作成するよう学生に勧めています。私は Java にあまり詳しくなく、インストラクターも .NET にあまり詳しくないため、C# で同等のものを見つけることができませんでした。知っている人はいますか？

アップデート：

ソケットを明示的に知らなくても WCF サービスを検出する方法を探しています。

更新 2:

VS 2008/WebDev サーバーを使用して、XP ラップトップでプロジェクトのデモを行います。

私は、顧客データを本社と社内の移動中の営業担当者の間で共有できるようにするクライアント/サーバーを作成しています。

サーバーは、顧客データをダウンロードしてXMLファイルに書き込みますが、データをメモリに保持して、ローカルクライアントとして機能できるようにします。

顧客データをインターネット経由で簡単に送信できるように、ArrayListをシリアル化することを計画しています。これはどれくらい安全ですか？シリアル化されたオブジェクトを送信する前に、フォームの暗号化を調べる必要がありますか？

カスタムJVMの動作は少し異なる可能性があることを知っており、観察された動作が実際のJVMと同じであるかどうかを確認しようとしています。また、私はこのようなものを一貫して機能させる方法を探しています。

私が見た中で最悪の部分は、例外がJVMによって完全に食べられていることです。例えば：

「test」にnullを渡すことに対するコード内の2つの応答を見てきました。1つは、「NullPointerException」をログに記録することです。他には何もありません、その文字列だけです。

もう1つは、何もログに記録されないことです。コードの実行は停止するだけで、このコードが実行された後は何も実行されません（呼び出し元のメソッドの周りにtry / catchがある場合でも）

また、例外の後、呼び出しスレッドは継続しないようです（このようなバグを追跡するのは驚くほど困難です）。

このメソッドの周りにtry/catchをスローしてエラーをログに記録すると、正常に機能します。

確かに、私はカスタムコードを使用して古いJVMに取り組んでいるので、あまり助けは期待していませんが、誰かがこのような動作を見たことがありますか？たぶん古いJVMで？例外をネットワーク経由でスローすることになっていますか、それともリモートシステムにスタックトレースを出力することになっていますか？

例外をRemoteExceptionでラップし、それを再スローすることは合理的な解決策ですか？

助言がありますか？（新しいJVMの仕様は別として、これは可能性の領域からはほど遠いため、面白くありません）

RMI を介した J2EE サービスへの接続を確認するための簡単なテストを実装したいと考えています。次のプロパティが設定されたプロパティ ファイルを指定できるように、汎用的である必要があります。

他のアプリケーションがサーバーに正常にデプロイされる可能性があるため、ポートを確認するだけでは不十分です。私たちの環境内のすべてのアプリケーションに、デフォルト メソッド (ping メソッドなど) を備えたデフォルト サービスがあるとは限りません。これにより、はるかに簡単になります。

java.naming.provider.url を使用して実行できる標準的なテストはありますか?

私は現在、RMIサーバーと通信するRMIクライアントに取り組んでいます（私が働いている会社の別の部門によって開発されました）。他のチームがインターフェースを所有していますが、IMO は非常に複雑で、多くの異なる型が前後に渡され、不必要に (IMO) 複雑な例外階層が渡されます。

私は何度も、これが一種の不必要な複雑さであり、後で統合するときに問題の確実な原因になるという懸念を表明してきましたが、あまり注目されていません。IMO では、不必要に大量のコードが共有されることにつながります。さらに、共有するすべての異なるクラスは、監視が必要なバージョン管理要件の余分なセットです。

私の議論を補強するために使用できるリソース/議論を知っている人はいますか.

または、私が間違ったツリーを吠えていると誰かが納得させることができますか?

私が理解しているように、2つのシステム間にRMI通信リンクを設定すると、「リモート」を実装するオブジェクトを、そのタイプのオブジェクトを取得するリモートメソッドの1つに渡すことができ、遠端は取得します。新しいオブジェクトのリモートインターフェイス（つまり、オブジェクトをシリアル化するだけでなく、新しいリモート接続になります）。

これは正しいです？

もしそうなら、これはメソッドのシグネチャと関係があると思いますが、オブジェクト全体を単にシリアル化するのではなく、新しいリモートオブジェクトを作成する必要があると判断する方法を正確に知りたいと思います。

これを言葉にするのは本当に難しいです。これを試してみましょう：

クライアントとサーバーシステムがあるとしましょう。サーバーシステムでは、RMIオブジェクトを作成して公開し、クライアントシステムでは、インターフェイスを取得して、サーバーシステムと対話できます。

ここまでは順調ですね。クライアントでは、Object1.remoteMethod（）がサーバー上で実行されます（パラメーターをシリアル化した後）。

さて、ここに質問があります。クライアントで次のようなコードを実行します。

私が理解しているように、その時点で、私のシステムには新しい通信メカニズムがあります。

この時点で、サーバーがObject2のメソッドを呼び出すと、そのメソッドは実際にはクライアントで実行されます。

システムが（リモート以外のオブジェクトの場合のように）単にシリアル化するのではなく、どの時点でこれを実行することを決定するのか疑問に思っています。

または、私は完全に間違っていて、それをシリアル化するだけで、実際にリモート呼び出しを作成するには、ある種の「getRemoteInterface（）」メソッド呼び出しが必要ですか？

クライアントサーバーアーキテクチャに基づいて構築された製品があります。使用されているテクノロジースタックに関する詳細。

• クライアント-JavaSwing
• サーバー-RMI
• Javaデータベース-Oracle

クライアントは世界のさまざまな場所にありますが、JavaサーバーとOracleデータベースはスウェーデンの同じマシンにあります。このため、多くのネットワーク遅延があります。離れた場所にいるクライアントのパフォーマンスはひどいです。このアプリケーションは、50MBを超えるサイズのファイルを処理するために使用されます。一般に、各操作には約1000を超えるネットワーク呼び出しが必要です。

あなたの経験に基づいて、この問題にどのように取り組み、パフォーマンスを向上させますか？

編集：いくつかの質問に答える

1. ファイルには、処理およびデータベースへの更新が必要な実際のビジネスデータが含まれており、一部を送信することはできません。
2. 一部のネットワーク呼び出しはバッチ処理できますが、コードの大幅なリファクタリングが必要になります。これは2001年に作成された非常に古いアプリケーションです。アプリケーションの設計は、サーバーがすべてのサービスを保持し、コード全体で再利用可能になり、ビジネスロジックがクライアント側で作成されるようになっています。したがって、このビジネスロジックはサーバーを何度も呼び出すため、天文学的な数字になります。

-Snehal