重要： ターゲット環境を事前に調査し、それがテストされていることを確認するか、または自分自身でテストしてください。 Java エージェントの問題のほとんどは、アプリケーションではなく、OS または JVM に起因しています。 このドキュメントの指示に従うようにしてください。 それが役に立たない場合に備えて、このトピックでは、最も一般的な問題について説明しています。
DevTest Java エージェントに関連する最も重大な問題は起動時に発生します（エージェントが見つからない、プロセスがクラッシュまたはハングアップするなど）。 一般に、起動時の問題を切り抜けたら、トラブルシューティングとしては快調です。 そこから、設定を調整したり、拡張を記述したりしていくことになります。
注：
起動時のエラー： VM の初期化中にエラーが発生する。 絶対パスにエージェント ライブラリが見つからない。
ライブラリが実際にそのパスにあり、Java と同じアーキテクチャを使用していることを確認してください（32 ビットと 64 ビットの両方）。
また、ライブラリの何からの依存関係が欠けていないことも確認してください。 たとえば、Win32 では depends.exe、Mac OS X では otool -L、Linux および UNIX では ldd -d を使用します。 ライブラリが欠けている場合は、LD_LIBRARY_PATH が、ライブラリが存在するディレクトリを含むように設定されていることを確認します。 コンテナが、その起動スクリプトで LD_LIBRARY_PATH を上書きする場合があります。 これをスクリプトやコンテナ固有の管理ツールからではなく、シェルで設定している場合は、正しく設定されていると思いこまないでください。
ldd が正常に返されない場合、エージェントは正しく実行されません。 そのため、ldd の確認は、解決するために行うべき最初のことです。 オペレーティング システムのエージェント バージョンが見つからない場合は、Pure Java エージェントの使用を検討してください。
エージェントが直ちに（または、プロセスを起動した後すぐに）終了する。
「LISA AGENT: VM terminated」というメッセージが表示される場合は、おそらくプロセスは正常に終了しています。 いくつかのコンテナはランチャ プロセスを含んでおり、それが直ちに終了することは正常な動作です。
このメッセージが表示されないか、または（ldd が正常に返された後に）クラッシュ ダンプが発生する場合は、エージェントのバグが存在する可能性があります。 サポートに連絡し、Pure Java エージェントを試してください。 依然としてクラッシュまたはダンプが発生する場合は、JVM のバグが存在する可能性があります。 このような状態は、一部のオペレーティング システム上の IBM JVM 1.5 の場合、スレッドをインスツルメントしようとして発生します。 その場合は、コマンドラインの JVM 引数 -Dlisa.debug=true を指定してみてください。
エージェントが「GetEnv on jvmdi returned -3 (JNI_EVERSION)」というメッセージで終了する。
JVM にそのデバッグ対応ライブラリを使用するよう指示するために、コマンドライン オプション -Xsov を指定してみてください。 それが機能しない（たとえば、無効なオプションのエラー メッセージが表示される）場合、このオペレーティング システムはサポートされていません。
エージェントが「UTF ERROR" ["../../../src/solaris/instrument/EncodingSupport_md.c":66]: ...」というメッセージで終了する。
このメッセージは、オペレーティング システムまたは JVM、あるいはその両方の正確なバージョンによって異なる場合があります。 このメッセージは通常、次の要素のいずれかを含んでいます： 「UTF ERROR ["../../../src/solaris/instrument/EncodingSupport_md.c":66]: Failed to complete iconv_open() setup」。
この問題は、いくつかの言語パックがインストールされていない場合、一部の Solaris JVM にあるバグのために発生します。 この問題を修正するには、最初に pkg install SUNWlang-enUS、次に export LANG=en_US.UTF-8 を実行することによって、en-US 言語パックをインストールします。 あるいは、ネイティブ エージェントを使用します。
起動時にエージェントがハングアップするか、または多数の例外をスローする（LinkageErrors、CircularityErrors など）。
Java を使用した Java バイトコードのインスツルメントの副作用は、最初の方のクラス（java.* など）のクラスロードの順番の一部がわずかに変更され、それによりデッドロックまたはバイトコード検証エラーが発生する場合があることです。
JVM とオペレーティング システムのすべての組み合わせについて、これらの問題の既知の発生のすべてを排除しています。 ただし、テストされていない組み合わせが発生している可能性があります。 この問題をサポートに連絡してください。 この問題がハングアップである場合は、サポートの問題にスレッド ダンプを含めてください。 Windows では Ctrl + Break、UNIX/Linux では Ctrl + \ または kill -3 <pid> を入力することによって、スレッド ダンプを生成します。 また、Java エージェントはクラスロードの順番が少し異なるため、それも試してみることができます。 あるクラスまたはパッケージがハング スレッドに常に含まれていると考えられる場合は、そのための exclude ディレクティブを rules.xml ファイルに追加してみてください。
エージェントが java.lang.VerifyErrors をスローするか、またはホット スワップが有効にならない。
一部の古い 1.4 JVM には、ホット スワップ（ロードされた後のクラスのインスツルメント）のサポートにバグがあります。
その場合、Enable hot instrumentation プロパティを無効にすることにより、ホット スワップをオフにします。
このプロパティは、DevTest ポータルの［エージェント］ウィンドウから設定できます。 プロパティは［設定］タブに表示されます。
インターセプトまたは仮想化するクラスまたはメソッド、あるいはその両方を前もって決定し、これらのクラスまたはメソッドのルールを rules.xml ファイルに追加して、サーバを再起動する必要があります。 このプロセスはライブ サーバ上での実行に比べて面倒ですが、これがこの問題を回避するためのわかっている唯一の方法です。
ログに java.lang.VerifyError が見られない場合もありますが、エージェントは、指定されたクラスがインスツルメントされていないかのように動作するか、またはランダムな結果（クラッシュなど）を生成します。
エージェントは起動するが、コンソールまたはブローカがエージェントを認識できない。
この原因は、通常はエージェントとブローカの間のファイアウォールまたはポートの問題です。
エージェント ログの先頭に、「Can't connect to broker at tcp://ip:port」という警告が含まれている場合があります。 エージェントが使用している IP アドレスとポートが正しいことを確認してください。 次に、ブローカが、指定された IP アドレスの指定されたポートでリスンしていることを確認してください。 netstat -ano | grep port によって、指定された IP または 0.0.0.0 でリスンしているポートが表示されるはずです。 最後に、エージェント コンピュータから telnet ip port を実行してブローカを認識できることを確認することにより、ファイアウォールの問題を見つけてください。 ブローカを認識できる場合は、ブローカが異常な状態にある可能性があります。 レジストリとブローカ ログを確認し、必要に応じてブローカを再起動します。
エージェントのために一部の操作がタイムアウトする。
一部の JVM （特に IBM JVM）は、その一部のネットワーク クラスがインスツルメントされた後、正しく動作しません。 その結果、ネットワーク呼び出しが、明確な理由なしで失敗またはタイムアウトする場合があります。
これらのクラスがインスツルメントされないようにするには、コマンドラインの JVM 引数 -Dlisa.debug=true を指定してみてください。
問題が解決されない場合は、rules.xml ファイルを編集して、以下のネットワーク パッケージを除外します。
<exclude class="java.net.**"/> <exclude class="java.nio.**"/> <exclude class="sun.nio.**"/>
com/itko/lisa/remote/transactions/TransactionDispatcher.class の java.lang.NoClassDefFoundError
LisaAgent.jar が使用可能で、読み取り権限を持ち、かつ破損していないことを確認してください。 最も簡単な確認方法は、java -jar LisaAgent.jar -v を実行することです。
アプリケーションが OSGi を使用しているかどうかを確認してください。 使用している（JBoss 7 でのように）場合は、システムまたはブートストラップ パッケージに com.itko を追加します。 com.itko を追加する方法はコンテナに依存するため、特定の手順を示すことは困難です。 ただし、これは通常、パッケージのリストまたは類似の JVM 引数を指定するプロパティを含む設定ファイルです。
エージェントを有効にすると、セキュリティ関連の例外がスローされる。
アプリケーションによってスローされた SecurityExceptions または PermissionExceptions が見られる可能性があるのは、セキュリティが有効な状態でエージェントを有効にした場合だけです。 この設定は現在、デフォルト設定になっています。
この理由と回避策については、「Java エージェントのセキュリティ」で説明しています。
異常なリソース消費（CPU、メモリ、ファイル ハンドルなど）。
CPU 使用率が異常に高いか、または定期的に急上昇する場合は、障害のある（1 つまたは複数の）スレッドの特定に役立つため、急上昇の期間に注意してください。 また、CAI と VSE も無効にしてみてください。
OutOfMemory エラーが発生する場合は、Java ヒープ使用率をモニタします それが -Xmx の制限を超えている場合は、その制限を増やします。 ただし、すでに高くなっており、エージェントなしでの通常のアプリケーション使用率を優に超えている場合、制限を増やすことは避けてください。 その場合は、ヒープ ダンプを生成します。 WebSphere 用の WAS HeapDump ユーティリティ、または古いバージョン用のフリーの Eclipse MAT ツールを使用できます。 エラーの時点でメモリ使用率が -Xmx の制限に達していない場合は、ネイティブ コード内のリークである可能性があります。 この場合は、サポートに連絡してください。
特に UNIX または Linux で不明な IOExceptions （ファイル ハンドルが多すぎるなど）が発生する場合は、ボックスの ulimit を確認してください（ulimit -n -H および ulimit -n -S）。 この値が低い場合は、ボックスの管理者に増やすよう依頼することを検討してください（最新の J2EE アプリケーションでは、4096 未満は低いと見なされます）。 その後、再起動することを忘れないでください。
エージェントは、制限に近づいたらガベージ コレクションをトリガすることによって、ファイル ハンドルの数を制限未満に維持しようとします。 起動時に制限を読み取ることができない場合、エージェントはデフォルト値の 1024 を使用します。 このデフォルト値を使用すると、過剰なガベージ コレクションや、ほぼランダムで、頻繁な CPU 使用率の急上昇が発生する場合があります。 この状況は、ログ内の以下のメッセージによって示されます。
Max (or preferred) handles limit approaching - triggering GC...
その場合、［ハンドルの最大数］プロパティの値が増加します。
このプロパティは、DevTest ポータルの［エージェント］ウィンドウから設定できます。 プロパティは［設定］タブに表示されます。
エージェントが起動したことは確認できるが、CAI データがないか、または完全ではない。
データ ライフサイクル プロセスには、以下の段階が含まれます。
欠落したデータや不完全なデータは、このいずれかの段階での問題の結果である場合があります。
キャプチャ例外がないかどうか、エージェント ログを確認してください。 転送または保存例外がないかどうか、ブローカ ログおよびコンソール ログを確認してください。
例外が存在せず、依然として欠落したデータを見つけることができない場合は、エージェントでの debug または dev ログを有効にしてください。 「Sent partial transaction」などのステートメントが表示されない場合は、CAI がおそらく有効になっていません。
これらのいずれの手順によっても最終的な結果が得られない場合は、サポートに連絡してください。
Java VSE のレコーディングまたは再生を有効にしたが、VSE がエージェントからの要求をまったく受信しない。
まず、エージェントが VSE のレコーディングまたは再生モードにあることを確認してください。 エージェント ログを開き、「Starting VSE record/playback...」を検索します。
次に、エージェント ログと VSE ログで例外を探します。 存在しない場合は、仮想化されていると考えているクラスが仮想化されていない可能性があります。 エージェント ログで「Virtualized com.xxx...」などのステートメントを探します。このステートメントがない場合は、アプリケーションがまだそのクラスをロードしていない可能性があります。 別の可能性として、Java 1.4 の古いバージョンを使用している場合は、一部の機能でホット スワップがサポートされていない場合があります。 Java VSE は、デフォルトでホット スワップを使用します。 その場合、エージェントの rules.xml ファイルで仮想化されたクラスを指定し、再起動します。
Java VSE のその他の問題。
Java VSE の実行中に何からの問題（機能的な問題、または異常なリソース使用率）が発生した場合は、エージェント側で CAI を無効にします。
［自動起動］プロパティを無効にすることにより、CAI をオフにできます。 次に、JVM を再起動します。
このプロパティは、DevTest ポータルの［エージェント］ウィンドウから設定できます。 プロパティは［設定］タブに表示されます。
ブローカ側で CAI を無効にしないでください。そうすると、Java VSE が完全に機能を停止します。
ケース機能が機能していない。
まず、エージェントがブローカに接続していることを確認してください。
エージェントがブローカに接続している場合は、問題が発生しているページの HTML ソースを確認します。 そのページの下部に、使用している変数名（com_itko_pathfinder_defectcapture_xxx など）で容易に識別できる JavaScript のブロックが存在することを確認してください。 このブロックがない場合は、エージェント ログに例外がないかどうかを確認します。 ブロックが存在しないその他の原因には、以下のものがあります。
ブロックが存在する場合は、Java コンテナの前にネイティブ Web サーバ（Apache など）またはロード バランサが存在するかどうかを確認してください。 その場合は、それを CAI JavaScript の要求とリソース ファイルを Java コンテナに転送するように設定します。 これにより、その URL の一部として defectcapture という単語が含まれます。 IT 管理者は一般的に、このタスクの実行方法を知っています。
DevTest は IBM DB2 データベースを使用するように設定されます。 DevTest ポータルで、パス グラフ内の JDBC ノードを選択しました。 ［Statements］および［接続 URL］列はブランクです。
JDBC 接続 URL にprogressiveStreaming=2 文字列を追加して、プログレッシブ ストリーミングを無効にします。 以下に例を示します。
lisadb.pool.common.url=jdbc:db2://myhostname:50000/dbname:progressiveStreaming=2;
|
Copyright © 2014 CA Technologies.
All rights reserved.
|
|