目次 前 次
16.2 アプレットのトラブルシューティング
タブをサポートする最新のブラウザでは、各タブがそれぞれ独立したブラウザ・プロセスである可能性があります。Javaアプレットがブラウザ・ページに埋め込まれていて、次世代プラグインが使用されている場合、通常、そのブラウザ・タブに関連付けられたプロセスが、そのプロセスの内部にJVMを作成します(ブラウザVM)。このブラウザVMは、アプレットの実行やアプレットのライフ・サイクルの管理を行う、別のJVMプロセス(クライアントVM)を作成します。クライアントVMは1つのJavaプロセスです(Windowsではjava.exe、Oracle Solaris/Linuxプラットフォームではjava)。
次に、アプレットの問題およびトラブルシューティング手法を示します。
16.2.1 アプレットを起動するためのプラグインのチート・シート
アプレットが起動しない場合は、前述したように、必ずトレースとJavaコンソールを有効にしてください。次のヒントを使用してアプレットが動作しない理由を調べます。
トレース・ファイルが生成されたり、Javaコンソールが表示されたりしますか。
-
-
いいえ、トレース・ファイルを得られません
Javaテクノロジが検出されているかどうかを確認します。
-
はい
JVMブラウザの問題を調べます
-
いいえ
これはおそらく構成の問題です。一般的な構成の問題を調べ、まだ解決しない場合は、JVMブラウザの問題を調べます
-
-
はい、トレース・ファイルがあります
これは(次世代プラグインを無効にしていないかぎり)、おそらく構成の問題ではありません。この問題はおそらくこのアプレットに固有のものです。確認のため、ほかのアプレットもいくつか起動してみてください。JVMブラウザの問題を調べます
-
16.2.2 ブラウザまたはJavaプロセスのクラッシュ
クラッシュは、プラットフォームの問題かアプリケーションの問題によって発生する可能性があります。
通常、JVMでクラッシュが発生すると、現在の作業ディレクトリにhs_err_*logファイルが作成されるはずです(Windowsの場合、これはしばしばデスクトップ上に配置されます)。これは、スタンドアロン・アプリケーションと同じクラッシュ・レポート・ファイルです。レポート・ファイルの詳細は、付録Aを参照してください。
配備キャッシュ・ディレクトリからロードされたネイティブ・ライブラリが見つかった場合、特にそれらのライブラリのコードがクラッシュ・スタックに含まれている場合、アプリケーションのバグである可能性が非常に高くなります。
それ以外の場合は、JREのバグであり、バグ・データベースに報告する必要があります。
プラットフォームまたはアプリケーションの問題によるクラッシュの場合に考慮すべき2つのシナリオを次に示します。
-
JVMブラウザの問題: ブラウザ・プロセスで実行されているJVMの詳細を取得してください。ブラウザを起動する前に、次の2つの環境変数を設定します:
JPI_PLUGIN2_DEBUG=1 JPI_PLUGIN2_VERBOSE=1
Windowsの場合、ブラウザ・プロセスに関連付けられたコマンド・ウィンドウが存在するはずです。ブラウザVMのデバッグ出力はすべて、コマンド・ウィンドウに表示されます。そこに例外が表示されていないかチェックします。Javaスレッド・ダンプを取得するには、コマンド・ウィンドウで[Ctrl]+[Break]キー・シーケンスを使用します。
Oracle SolarisまたはLinuxプラットフォームの場合、前述の変数を設定した後、同じセッションからブラウザを起動します。ブラウザVMのデバッグ出力はすべて、端末ウィンドウに表示されます。Javaスレッド・ダンプを取得するには、別の端末から
kill -3pidまたはkill -SIGQUITpidを使用します(pidはブラウザ・プロセスのプロセスID)。クライアントVMとブラウザVM間では「ハートビート」メッセージが送信されます。この「ハートビート」メッセージをオフにするには、
JPI_PLUGIN2_NO_HEARTBEAT環境変数を1に設定します。これは、問題が「ハートビート」関連かどうかを区別するのに役立ちます。ログが開かれず、ブラウザ・プロセス内で環境変数が設定されている場合、JREが正しくインストールされていないか、Javaが無効になっている可能性があります。ほかに何をやっても解決できない場合は、構成エラーがないかチェックし、JREの再インストールを試みてください。
-
JVMクライアントの問題: 最新のトレース・ファイルをチェックしてヒントを得ます。
注意: 同じクライアントJVMを複数のアプレットで共有することができます。共有JVMで、使用可能なリソース(ヒープ・サイズなど)が不足したために、間欠的な失敗が発生する場合があります。この場合は、ページを再ロードすると問題が解決することがあります。
アプリケーションがメモリー不足(
Out of memory)エラーで失敗する場合は、ヒープ・サイズを増やす必要があります。これは、アプリケーション配備記述子(JNLPファイル)で行うことも、Javaコントロール・パネルで、使用するJREの「ランタイム・パラメータ」を使って行うこともできます。アプリケーションが署名付きであり、ユーザーがセキュリティ・ダイアログで拒否した場合、アプリケーションが失敗する可能性があります。ユーザーが行なった決定は、JVMが再起動するまで記憶されます。セキュリティ・ダイアログをふたたび表示させるには、ユーザーがブラウザを再起動する必要がある場合があります。
注意: アプレットは、他のアプレットの影響を受けるリスクを低減してアプレットのニーズに合わせて実行環境を調整するようにデプロイできます。JDKドキュメントの「アプレット配備」を参照してください。特に、
separate_jvm parameter引数の使用を検討してください。
16.2.3 応答のないWebページ
応答のないWebページが生じる可能性があるシナリオを次に示します。
-
アプレットの起動または実行時にアプレットがフリーズする:
アプレットの起動時または実行時にアプレットがフリーズする原因は、Liveconnectの呼出しである可能性があります。
起動時にJavaScriptからJavaアプレットにアクセスしようとすると、アプレットの初期化が完了するまでJavaScriptエンジンがブロックされる可能性があります。アプレットの準備が整うまでJavaScriptアクセスを延期し、
enableStatusEventsパラメータを使ってアプレット・ステータス・チェックへの非ブロック・アクセスのロックを解除することをお薦めします。詳細や例については、「アプレットのステータスとイベント・ハンドラ」を参照してください。実行時にLiveConnectを使用するには、JavaScriptの呼出しをすばやく復帰させることで、シングル・スレッドのJavaScriptエンジンがブロックされないようにすることをお薦めします。
-
アプレットまたはブラウザがハングする:
この場合の最良の情報源は、クライアントJVMとブラウザJVMの両方のスタック状態です。
jstackを使用してブラウザJVM (
jstack browser-pidを実行)とクライアントJVMのJVMスタック・ステータスを収集します。注意: これらのいずれかのVMのコンテキストでデッドロックが発生した場合、jstackはデッドロックをハイライトできますが、デッドロックに両方のプロセスが含まれる場合にはこれを行うことができません。この場合、スレッド・スタックを手動で調べる必要があります。詳細は、を参照してください。その他のアプローチの詳細。