ORB アプリケーションのハング

クライアントまたはサーバー、あるいはその両方がハングした場合は、最悪の状態です。 ハングが発生した場合に最も考えられる (および最も解決しにくい) 状態は、スレッドのデッドロックです。 この状態で重要なのは、実行中のワークステーションに複数の CPU があるかどうか、および CPU で同時マルチスレッド (SMT) を使用しているかどうかを認識することです。

実行できる簡単なテストは、CPU を 1 つだけ実行したままにし、SMT を使用不可にして、問題が解決するかどうかを確認することです。 これで問題が解決した場合は、アプリケーションに同期問題があることが分かります。

また、ハング時のアプリケーションの動作内容を把握する必要があります。 アプリケーションは待機 (CPU 使用率が低い) 状態、または無限にループしている (CPU 使用率がほとんど 100% の) 状態でしょうか。 ほとんどの場合は待機の問題です。

スタンバイ状態の例として、クライアントがサーバーに要求を送信し、その応答を待機している間に停止するなどの状態があります。 ORB のデフォルトの動作は、無期限に待機することです。

com.ibm.CORBA.enableLocateRequest プロパティーを true (デフォルトは false) に設定すると、ORB は最初に短いメッセージをサーバーに送信して、アクセスする必要のあるオブジェクトを見つけます。 この最初の接続は位置指定要求です。 ここでは、LocateRequestTimeout を 0 以外の値 (無限大と同等) に設定する必要があります。 5000 ミリ秒程度の値で十分と思われます。

また、請求タイムアウトを0以外の値に設定します。 多くの場合、請求への応答は大きいため、応答に10,000ミリ秒などの時間を確保してください。これらの値は提案であり、低速の接続には低すぎる可能性があります。 要求がタイムアウトになると、クライアントは説明付きの CORBA 例外を受け取ります。

アプリケーションがハングした場合は、com.ibm.CORBA.FragmentTimeout という別のプロパティーも考慮してください。 このプロパティーは、パフォーマンスを向上させるためにフラグメント化の概念が実装されたときに、 IBM® ORB 1.3.1で導入されました。 これで、長いメッセージを複数の小さなチャンクまたはフラグメントに分けて、ネット上で順番に送信することができます。 ORB は、例外をスローする前に、次のフラグメントを 30 秒間 (デフォルト値) 待機します。 このプロパティーを設定する場合、このタイムアウトを使用不可にすると、スレッドの待機の問題が発生する可能性があります。

問題がデッドロックまたはハングと思われる場合は、Javadump 情報を収集してください。 情報を収集してから 1 分ほど待ち、再実行します。 2 つのスナップショットを比較すれば、スレッドの状態が変化したかどうかが分かります。 この操作を行う方法については、 J9 VM リファレンスの「 Javadump の使用 」を参照してください。

通常は、アプリケーションを停止し、orb トレースを使用可能にしてからアプリケーションを再始動します。 ハングが再現されると、取得できる部分的なトレースを IBM ORB サービス・チームが使用して、問題の場所を理解することができます。