以下のトラブルについて対処方法を説明します。
GlassFish Serverクラスター起動時、および運用時にアプリケーションでエラーが発生した場合
GlassFish Serverクラスター起動時、および運用時にアプリケーションでエラーが発生した場合、アプリケーションがJakarta EE規約に準拠していない可能性があります。
アプリケーションの再配備時、または配備解除時の不整合
アプリケーションの再配備時、または配備解除時に、以下が出力された場合、DASの内部情報に不整合が発生している可能性があります。
Failure removing policy context directory: ディレクトリ
Failure removing policy file: ファイル
本問題が発生した場合は以下の手順でリカバリーをしてください。
アプリケーションを配備
アプリケーションを配備解除
再配備の場合:アプリケーションを配備
運用時にアプリケーションの応答がない場合、遅延が発生した場合
Enterprise Beanごとのスレッドプール設定をせず、デフォルトスレッドプールを使用している場合、EJBアプリケーションの呼出しが多くなると、応答がない現象や処理遅延が発生することがあります。
IIOP通信によるリモートアクセスが行われるEJBアプリケーションについては、必ずデフォルトスレッドプールとは別のスレッドプールを作成し、使用するEJBアプリケーションのdeployment descriptorでEnterprise Beanごとのスレッドプール設定を行ってください。GlassFishのスレッドプール設定については、「10.9.16 スレッドプールの定義項目」の「■スレッドプール」を参照してください。Enterprise Beanごとのスレッドプール設定については、Eclipse GlassFishドキュメント「Application Deployment Guide」の「The glassfish-ejb-jar.xml File」に記載されている<use-thread-pool-id>タグを参照してください。
また、データベース連携をしている場合、JDBC接続プールの最大プールサイズを超えたリクエストが同時に実行され、データベース処理が待たされている可能性があります。データベースの処理時間およびJDBC接続プールの最大プールサイズを見直してください。最大プールサイズの定義については「10.7.1 JDBC接続プールの定義項目」を参照してください。なお、最大プールサイズを大きくすると、データベースサーバーへの接続が増えるため、データベースサーバー側の接続数の上限に達して接続エラーとなる可能性があります。データベースサーバー側の接続数の上限を確認してください。
アプリケーション内のクラスファイルやリソースファイルの参照に失敗する場合
アプリケーションがロードされたクラスローダからクラスファイルやリソースファイルが参照できない可能性があります。「4.6 クラスローダ」を参照し、アプリケーションがロードされたクラスローダからクラスファイルやリソースファイルが参照できるか確認してください。
アプリケーション内のクラスファイルが参照されずGlassFishが内包しているクラスファイルが参照されている場合、「4.6.3 Webクラスローダの委譲モデルの変更」を参考にWebクラスローダの委譲モデルの変更を検討してください。
ロードに失敗するクラスが「4.6.3 Webクラスローダの委譲モデルの変更」の「委譲の例外」に当たる場合、GlassFishが内包しているクラスファイルで動作するようにアプリケーションを改修してください。
参考
ロードされたクラスを確認するにはJava VMオプションに-verbose:classを指定してください。ロードされたクラスの情報はJava VMログ（console.log）に出力されます。
オートリロード機能が有効な状態でアプリケーションを配備した時に、サーバーログにNullPointerExceptionが出力された場合
NullPointerExceptionのメッセージに以下の文字列が含まれている場合は対処の必要がありません。
"_ThreadName=DynamicReloader;"
メッセージに上記の文字列が含まれていないときは、アプリケーションが原因の可能性があります。前後のエラーメッセージを参照し対処してください。
アプリケーションのオートリロードを実行した時にコンソールログにOutOfMemoryErrorが出力された場合
オートリロードをしたときに、DASでメタスペースが足りなくなりOutOfMemoryErrorが発生した場合は、以下の対処をしてください。
DASが停止している場合は起動させてください。
オートリロードの対象となっているアプリケーションを配備しなおしてください。
また、「JVMオプション」を参照し、メタスペースサイズを大きくしてください。
アプリケーションの実行に失敗する場合
要求を受け付けるバーチャルホストを設定後、Webブラウザーにステータスコード「404 Not Found」が通知される
要求を受け付けるバーチャルホストを設定後、Webブラウザーにステータスコード「404 Not Found」が通知される場合、設定した値が正しくない可能性があります。要求を受け付けるバーチャルホストに、以下のような値が設定されていないか確認してください。
ホスト名にスラッシュ（/）が含まれる。
設定されていた場合、一度Webサーバーとの連携を解除し、再度連携する際に正しい形式で要求を受け付けるバーチャルホストを設定してください。
HTTPリスナーのポート番号やシステムプロパティHTTP_LISTENER_PORTの変更後、Webブラウザーにステータスコード「500 Internal Server Error」や「404 Not Found」が通知される、または接続できない旨が表示される
システムプロパティHTTP_LISTENER_PORTを変更した場合、GlassFish ServerクラスターまたはGlassFish Serverインスタンスを再起動することにより、ポート番号の変更が反映されます。アプリケーションの実行に失敗する場合は、GlassFish ServerクラスターまたはGlassFish Serverインスタンスを再起動してください。
システムプロパティHTTP_LISTENER_PORTと他のシステムプロパティを同時に変更して保存した場合、Webサーバーとの連携設定が正常に更新されない場合があります。詳細は「システムプロパティHTTP_LISTENER_PORTの変更について」を参照してください。
java.lang.NoSuchMethodErrorやjava.lang.AbstractMethodErrorが出力される場合
アプリケーション内に含まれているライブラリと、GlassFishが内部動作のため使用するライブラリが競合する場合、以下のような例外が出力されアプリケーションが正しく動作しないことがあります。
java.lang.NoSuchMethodError
java.lang.AbstractMethodError
例えば、アプリケーションがJAX-RS 2.1規約に準拠しない古いバージョンのjerseyを含んでいる場合などに発生することがあります。
そのような場合は、アプリケーションに含まれる当該ライブラリを削除するか、Jakarta EEの規約に準拠したライブラリに置き換えてください。
ロケールの変更に起因して、配備済みのアプリケーションが消える現象が発生した場合
「7.7 ロケールの設定」時にアプリケーションが配備されていた可能性があります。
本問題が発生した場合は以下の手順でリカバリーをしてください。
配備済みのアプリケーションを配備解除します。配備解除した後、下記のディレクトリーを手動で削除してください。
＜運用資産格納ディレクトリー＞/domains/domain1/applications/＜アプリケーション名＞
運用資産格納ディレクトリー配下にお客様が独自にファイルを配置し、そのファイル名がマルチバイト文字を含む場合、ファイル名のエンコードを変更後のロケールに合わせてください。
手順1で配備解除したアプリケーションを配備しなおしてください。
DASや起動状態のGlassFish Serverクラスターをターゲットに指定したアプリケーションの配備解除時に、サーバーログにエラーメッセージが出力された場合
出力されたエラーメッセージのエラー種別がSEVEREでメッセージ内容が下記の場合は、アプリケーションの配備解除をしたターゲットを再起動してください。再起動後、再度配備解除をする必要はありません。
The web application [<アプリケーション名>] created a ThreadLocal with key of type <詳細情報> and a value of type <詳細情報> but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. |
上記以外の場合は、メッセージの内容に従い対処してください。
アプリケーションの配備に失敗する場合
「ERROR: No response from Domain Admin Server after 600 seconds.」が出力されアプリケーションの配備に失敗する
アプリケーション内でJPAを使用している場合で、以下のどれかの条件にあてはまる場合、配備処理中のデータベースへの接続が遅延またはハングアップしている可能性があります。
以下の条件を満たす場合
deployment descriptor (persistence.xml)の<persistence-unit>に<jta-data-source>、または<non-jta-data-source>を指定している。かつ、
アプリケーション内で@PersistenceUnitを使用しEntityManagerFactoryインスタンスを取得している。
プライマリーキー値の自動生成機能を使用している場合
データベーステーブル自動生成機能を使用している場合
データベース側で問題が発生していないか確認し、発生している場合は、問題を取り除いた後、DASを再起動し、アプリケーションの配備をやり直してください。
なお、DASを停止する際にメッセージNCLS-CORE-00025が出力されることがありますが、対処は不要です。
server.logに「OutOfMemoryError」が出力されアプリケーションの配備に失敗する
Javaヒープ領域が不足している場合に発生します。「13.18 OutOfMemoryErrorがログに出力された場合」を参照し、Javaヒープのサイズを大きくした後に、アプリケーションを配備してください。
リソースを使用するアプリケーションの配備に失敗する
リソースを使用するアプリケーションを配備する際、AS-DEPLOYMENT-00026あるいはNCLS-CORE-00026というメッセージが出力され、配備に失敗する場合があります。
この場合、deployment.resource.validationプロパティをfalseに設定することにより回避できることがあります。
詳細は「リソース検証の注意事項」を参照してください。
