この章では、Sun Java System Application Server Enterprise Edition 8.2 ソフトウェアに関する既知の問題とそれに関連する回避策について説明します。問題の説明にプラットフォームが明記されていない場合、その問題はすべてのプラットフォームに当てはまります。この節は次の項目から構成されています。
ここでは、管理上の既知の問題とその解決方法を示します。
Application Server の「インストール時に自動的に設定」オプションでは、ロードバランサ機能はサポートされていません。
対処方法:ロードバランサ機能は Application Server のインストール後に設定できます。
ロードバランサ機能を設定するには、Application Server と Web Server をシステムにインストールしておく必要があります。
ロードバランサ機能を設定するには、次の手順を実行します。
レジストリ HKEY_LOCAL_MACHINE -> Sun Microsystem -> EntSys -> Installer -> Application Server で、IS_LB の値を true 、Cfgr_LB の値を false に設定します。
setup ディレクトリに移動します。
cd JavaES-Install-Dir\setup\
|
ASConfigure.bat バッチファイルを実行します。
指示に従って、適切な値を指定します。
AS_LB プラグインの場合、Sun Java System Web Server [必須] と入力します。これが Java ES 5 でサポートされている唯一のプラグインであるためです。
システムをリブートします。
デフォルトでは、 asenv.conf によって参照される domain1 の AS_ACC_CONFIG 変数のハードコードされた値が JavaES-Install-Dir \lib\lib\package-appclient.xml にあります。 domain1 を削除して新たなドメインを作成した場合、AS_ACC_CONFIG 変数は新たなドメイン名で更新されません。その結果、package-appclient スクリプトの処理が失敗します。
次のいずれかの操作を行います。
domain1 はそのままにしておき、その前後に別のドメインを作成します。
domain1 を削除し、JavaES-Install-Dir \lib\lib\package-appclient.xml で domain1 用にハードコードされた値を、新たなドメイン名で置き換えます。domain1 がない場合、新たなドメインが作成されるたびにこの手順を行う必要があります。
7.1EE などからすでにロードバランサプラグインがインストールされている Application Server のインストールに対して負荷分散プラグインをインストールすると、プラグインを実行する新しいサーバーインスタンスを作成しても、メッセージの表示なしで既存のロードバランサが 8.2EE プラグインに置き換えられます。
プラグインファイルは、デフォルトで install_dir /plugins/lbplugin ディレクトリの下にインストールされるため、1 つの Application Server インストールで使用できるプラグインは 1 つのバージョンだけになります。コンソールインストーラはアンインストールが実行されていることを示すメッセージを表示しますが、このメッセージは見逃しやすいことに注意してください。
だれもがこの問題を経験するわけではありません。この問題が発生した場合は、古い Application Server インストールを削除して、アップグレードインストールではなく新規インストールを実行してください。
Application Server 7 および互換バージョンと比較して、Application Server 8.2 では asadmin コマンドにいくつかの変更が加えられました。たとえば、Application Server 7 および互換バージョンでは、サーバーインスタンスを起動するコマンドは次のようになります。
asadmin start-instance |
バージョン 8.2 では、次のコマンドを使用します。
asadmin start-domain --user admin domain1 |
最新の asadmin コマンド構文の詳細については、次のマニュアルを参照してください。
『Sun Java System Application Server Enterprise Edition 8.2 管理ガイド』
『Sun Java System Application Server Enterprise Edition 8.2 Reference Manual』
『Sun Java System Application Server Enterprise Edition 8.2 アップグレードと移行』
Java ES 2 Application Server 7 および互換バージョンから Java ES 5 Application Server 8.2 にアップグレードする場合、デフォルトポートが変更されているために、非互換性に関する問題またはエラーが発生することがあります。
同一の Application Server インストール上では、backup-domain コマンドと restore-domain コマンドを使用してドメインをミラーリングできません。これは、asadmin restore-domain コマンドにドメイン名を変更するオプションがあるにもかかわらず、元の名前ではない別の名前でドメインを復元できないからです。バックアップされたドメインの名前を正常に変更したように見えても、名前を変更されたドメインの起動は失敗します。ドメイン設定のエントリは変更されておらず、startserv および stopserv は元のドメイン名を使用してパスを設定するからです。
restore-domain で使用するドメイン名は、元の backup-domain コマンドで使用したドメイン名と同じである必要があります。Application Server 8.2 の backup-domain コマンドと restore-domain コマンドが動作するのは、同一マシンで同一ドメインをバックアップおよび復元する場合だけです。
J2SE 1.4.x、5.0 および互換バージョンを Application Server で設定できます。J2SE 5.0 プラットフォームの重要な特徴は、JMX エージェントを起動できることです。サーバーの起動時にシステムプロパティーを明示的に設定すると、JMX エージェントがアクティブになります。
以下に値の例を示します。
name="com.sun.management.jmxremote" value="true" name="com.sun.management.jmxremote.port" value="9999" name="com.sun.management.jmxremote.authenticate" value="false" name="com.sun.management.jmxremote.ssl" value="false"
JMX プロパティーを設定してサーバーを起動すると、Application Server VM 内で新しい jmx-connector サーバーが起動します。この場合は、望ましくない副作用の 1 つとして、管理機能が悪影響を受け、Application Server の管理 GUI や CLI で予期しない結果が発生することがあります。組み込みの jmx-connector サーバーと新たな jmx-connector サーバーとの間で衝突が発生することが原因です。
jconsole または何らかの JMX 互換クライアントを使用する場合には、Application Server とともに起動する標準の JMX コネクタサーバーを再利用することを検討してください。
サーバーの起動時に、次に示すような行が server.log に作成されます。ここで指定されている JMXServiceURL に接続し、資格を正常に指定した後、同様の管理および設定操作を実行することができます。次に例を示します。
[#|2004-11-24T17:49:08.203-0800|INFO|sun-appserver-ee8.1|javax.enterprise. system.tools.admin|_ThreadID=10;|ADM1501: Here is the JMXServiceURL for the JMXConnectorServer: [service:jmx:rmi:///jndi/rmi://hostname:8686/management/ rmi-jmx-connector]. This is where the remote administrative clients should connect using the JSR 160 JMX Connectors.|#]
詳細については、『 Sun Java System Application Server 8.2 管理ガイド』を参照してください。
Web サービスの URL をエクスポートする EJB モジュールを含むアプリケーションを使用してロードバランサを設定しても、作成された loadbalancer.xml ファイルに、その Web サービスのコンテキストルートが存在しません。
loadbalancer.xml ファイルを編集して、作成されなかった Web モジュールを次のように追加します。
<web-module context-root="context-root-name" disable-timeout-in-minutes="30" enabled="true"/> |
context-root-name 値を、EJB として公開された Web サービスのコンテキストルート名に置き換えます。
Application Server のドメインまたはサーバーが、関連付けられた設定の java-config 要素の java-home 属性によってポイントされる JDK を使用しません。
該当のサーバーインストール内のすべてのドメインに対して Application Server プロセスが使用する JDK は、appserver-installation-dir /config/asenv.conf ファイルによって決まります。使用される JDK は、このファイル内のプロパティー AS_JAVA によって決まります。これはインストール時に設定されます。インストール後に別の JDK を Application Server プロセスが使用するようにするには、別の JDK をポイントするようにこの値を編集します。この変更によって、このインストール内のすべてのドメインが影響を受けることに注意してください。
asenv.conf ファイルを手動で変更する場合は有効性がチェックされないため、変更時には注意が必要です。AS_JAVA の値を修正する場合は、製品のマニュアルで JDK のバージョンの最低限の要件を確認してください。
この問題は %CONFIG_HOME% の間違った値によって発生します。
既存の名前 asant を asant.bak に変更します。
as_install /lib/install/templates/ee にある SE/EE バージョンの asant.template ファイルを as_install /bin/ ディレクトリにコピーし、このファイルの名前を asant に変更します。
新しくコピーされた as_install/bin/asant ファイルを編集して、%CONFIG_HOME% トークンを as_install /config 値に置き換えます。
元の asant.bak ファイルに対して行なった手作業の変更がある場合は、それを新しい asant ファイルに結合します。
このファイルがサーバー管理者の home ディレクトリに存在しないと、そのサーバー上にホストされている特定のアプリケーションをアップグレードしたときに重大なバグが発生する場合があります。
可能であれば、そのサーバーをインストールしたユーザーが asadmin start-domain domain1 コマンドを実行してください。
そのユーザーがこのコマンドを実行できない場合は、.asadmintruststore を、インストールしたユーザーの home ディレクトリから実行中のユーザーの home ディレクトリに移動またはコピーしてください。
このファイルをインストールユーザーの home ディレクトリから実行中のユーザーの home ディレクトリに (コピーではなく) 移動した場合は、アップグレードまたはインストールしたユーザーの home ディレクトリに .asadminstruststore ファイルが存在しなくなるため、バグ 6309079、6310428、および 6312869 で説明されているようなアプリケーションのアップグレードに関する問題が発生する可能性があることに注意してください。
ドメインのマスターパスワードにパーセント文字 (%) が含まれるときにドメインが起動しません。
ドメインのマスターパスワードにパーセント文字 (%) を含めないようにしてください。これは、新しいドメインを作成するとき、および既存のドメインのマスターパスワードを変更するときに適用されます。
セキュリティー保護された http-listener を作成し、lbplugin をインストールしたあとで、webserver_instance_dir/config ディレクトリの下の magnus.conf および obj.conf ファイルが変更され、lbplugin の内容が削除されます。
インストーラは、ロードバランサプラグインのインストールの一部として、Application Server の magnus.conf および obj.conf 設定ファイルを変更します。Application Server 管理コンソールにログインし、ロードバランサがインストールされたインスタンスのインスタンス設定を管理しようとすると、Application Server は、設定の手動編集を検出したことを示す警告メッセージを表示します。この警告は、実際にはインストーラによって加えられた変更を示しています。
インストーラによって加えられた変更が上書きされていないことを確認します。
ここでは、アプリケーションクライアントに関する既知の問題とその解決方法を示します。
クライアント JAR (この場合は reporter.jar) 内に最上位レベルの JAR ファイルがある場合、クライアント JAR を配備すると、その JAR の MANIFEST ファイルがクライアント JAR の MANIFEST ファイルを上書きします。
ありません。
CGI-bin や SHTML などの動的コンテンツ技術はサポートされなくなりました。
JSP および Web サービス技術を代わりに使用します。
ここでは、Sun の JDBC ドライバに関する既知の問題とその解決方法を示します。
この問題は、2 つの並行トランザクションが実行中で、そのうちの 1 つがロールバックされた場合、準備済みの更新文を使ったときに発生することがあります。
接続の遮断レベルを設定するには、対応する接続プールを同じ遮断レベルで作成します。接続プールの設定の詳細については、『Sun Java System Application Server Enterprise Edition 8.2 管理ガイド』を参照してください。
1 つのトランザクションで 3000 を超える PreparedStatement オブジェクトを生成する場合、DB2 では次のエラーが発生する可能性があります。
[sunm][DB2 JDBC Driver] No more available statements. Please recreate your package with a larger dynamicSections value.
次のプロパティーを接続プール定義に追加して、ドライバが DB2 パッケージをより大きな動的セクション値に再バインドするようにします。
createDefaultPackage=true replacePackage=true dynamicSections=1000
接続プールの設定については、『Sun Java System Application Server Enterprise Edition 8.2 管理ガイド』を参照してください。
PrepardStatement エラーに関連して、次のエラーメッセージがスローされることがあります。
[sunm][DB2 JDBC Driver][DB2]Virtual storage or database resource is not available.
DB2 サーバー設定パラメータ APPLHEAPSZ の値を増やします。たとえば、4096 を使用します。
遮断レベル TRANSACTION_SERIALIZABLE。アプリケーションが遮断レベル TRANSACTION_SERIALIZABLE を採用し、前述したパラメータの 1 つを使用している場合、そのアプリケーションは接続を取得するときにハングアップすることがあります。
遮断レベルを接続に対して設定するには、対応する接続プールをその遮断レベルで作成する必要があります。手順については、『Sun Java System Application Server Enterprise Edition 8.2 管理ガイド』を参照してください。
この節では、J2EE のコネクタアーキテクチャーに関する既知の問題とその解決方法を示します。
このシナリオでは、スタンドアロンまたは埋め込みのコネクタモジュールが DAS とコネクタ接続プールに配備され、その配備済みモジュール用にリソースが作成されます。DAS インスタンスを再起動したあと、cascade が false に設定されている場合にコネクタモジュールの配備取り消しが次の例外で失敗します。
[#|2004-10-31T19:52:23.049-0800|INFO|sun-appserver-ee8.1|javax.enterprise.system .core|_ThreadID=14;|CORE5023:Error while unloading application [foo]|#]
DAS インスタンスを再起動します。スタンドアロンまたは埋め込みのコネクタの配備を取り消すために、カスケード式配備取り消しを使用 (cascade オプションを true に設定) します。
コマンド行から asadmin create-jms-resource コマンドで新しい JMS リソースを作成するときは最小プールサイズと最大プールサイズを指定できないため、asadmin コマンドがデフォルトのプールサイズ値 (最小が 8、最大が 32) を使用してリソースを作成すべきです。代わりに、コマンド行からリソースを作成すると、デフォルトの最小プールサイズと最大プールサイズがそれぞれ 1 と 250 になります。
コマンド行から JMS リソースを作成したあとで、管理コンソールを使用して最小プールサイズ値と最大プールサイズ値を変更します。
ここでは、マニュアル上の既知の問題とその解決方法を示します。
いくつかの AMX インタフェースおよびメソッドについて、Javadoc が欠けているか間違っています。
NumConnAcquired および NumConnReleased 統計情報の取得メソッドが ConnectorConnectionPoolStats および AltJDBCConnectionPoolStats から抜けている。
EJBCacheStats 内でメソッド getPassivationSuccesses()、getExpiredSessionsRemoved()、getPassivationErrors()、getPassivations() を呼び出すと、例外がスローされる。
サーバーを起動したあと、すべての AMX MBeans が登録されて利用できるようになるまでに数秒を要することがある。
定数 XTypes.CONNNECTOR_CONNECTION_POOL_MONITOR のスペルが間違っている ("NNN" の部分)。
スレッド「main」で java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher の例外がスローされます。
付属の ANT を Application Server 外部のタスクの実行に使用することはお勧めできません。
『Sun Java System Application Server Enterprise Edition 8.2 パフォーマンスチューニングガイド』で、ログオプションについて次のように記述されていますが、これは誤りです。
The Administration GUI provides the following two logging options: (Administration GUI は次の 2 つのログオプションを提供します。)
Option 1 – Log stdout ( System.out.print) content to the event log (オプション 1 – stdout (System.out.print) コンテンツをイベントログに記録する)
Option 2 – Log stderr ( System.err.print) content to the event log (オプション 2 – stderr (System.err.print) コンテンツをイベントログに記録する)
これらのログオプションは、Application Server Enterprise Edition 8.2 では存在しなくなりました。
Application Server Enterprise Edition 8.2 のマニュアルでは、「HTTP File Cache」 in 『Sun Java System Application Server Enterprise Edition 8.2 Performance Tuning Guide』で HTTP ファイルキャッシュ機能について説明しています。しかし、この機能は Application Server Enterprise Edition 8.2 に含まれていませんでした。この機能は Application Server 9.0 で再導入されたことに注意してください。
ここでは、高可用性データベース (HADB) に関する既知の問題とその解決方法を示します。
hadbm set を使用してデバイスまたはバッファーのサイズを増やす場合、管理システムは、データベースを作成したり、ノードを追加したりする際にはリソースが利用可能かどうかをチェックします。 しかし、デバイスまたはメインメモリーのバッファーサイズを変更するときには利用可能なリソースが十分にあるかどうかをチェックしません。
設定属性 devicesize または buffersize を増やす前に、すべてのホスト上にディスクおよびメモリーの空きスペースが十分にあることを確認してください。
同一のソフトウェアパッケージを、異なるホストの別の場所に同じ名前で登録することはできません。次に例を示します。
hadbm registerpackage test --packagepath=/var/install1 --hosts europa11 Package successfully registered. hadbm registerpackage test --packagepath=/var/install2 --hosts europa12 hadbm:Error 22171: A software package has already been registered with the package name test. |
HADB は、データベースクラスタ内のノードをまたがる混在パスをサポートしません。HADB サーバーのインストールディレクトリ (---packagepath) は、すべての参加ホストについて同一にしてください。
複数のネットワークインタフェースを備えたホスト上で管理エージェントを実行している場合に、すべてのネットワークインタフェースが同じサブネット上に存在しないと、createdomain コマンドが失敗することがあります。
hadbm:Error 22020: The management agents could not establish a domain, please check that the hosts can communicate with UDP multicast. |
管理エージェントは、特に設定されていないかぎり、UDP マルチキャスト用の「最初の」インタフェース (この「最初」は、java.net. NetworkInterface.getNetworkInterfaces() の結果によって定義される) を使用します。
もっとも良い解決法は、使用するサブネットを管理エージェントに通知することです (たとえば、設定ファイル内の ma.server.mainternal.interfaces をma.server.mainternal.interfaces=10.11.100.0 に設定します)。あるいは、サブネット間のルーターを、マルチキャストパケットをルーティングするように設定することもできます。このとき、管理エージェントはマルチキャストアドレス 228.8.8.8 を使用します。
管理エージェントの新しい設定を再試行する前に、管理エージェントリポジトリのクリーンアップが必要になる場合があります。ドメイン内のすべてのエージェントを停止し、リポジトリディレクトリ (管理エージェント設定ファイル内の repository.dr.path で識別される) 内のすべてのファイルとディレクトリを削除します。このクリーンアップは、新しい設定ファイルを使用してエージェントを再起動する前に、すべてのホスト上で実行する必要があります。
HADB インスタンスの削除に続いて configure-ha-cluster コマンドで新しいインスタンスを作成しようとすると、失敗します。問題は、元の HADB インスタンスの古いディレクトリが ha_install_dir/rep/* と ha_install_dir/config/hadb/instance_name に残ることにあります。
HADB インスタンスの削除後に、手動でこれらのディレクトリを削除するようにしてください。
Red Hat Enterprise Linux 3.0 の 64 ビットバージョンには、非同期入出力の実行中に clu_trans_srv プロセスを中断不可能なモードに陥らせるバグが存在します。つまり、kill -9 コマンドが機能せず、オペレーティングシステムの再起動が必要になります。
Red Hat Enterprise Linux 3.0 の 32 ビットバージョンを使用します。
パスワードが hadb に格納されるときに、パスワード内の大文字は小文字に変換されます。
大文字を含むパスワードは使用しないでください。
場合によっては、サーバー上のリソース競合の問題によって管理クライアントが切断されることがあります。再接続時、「hadbm:Error 22184:A password is required to connect to the management agent」という紛らわしいエラーメッセージが返されることがあります。
サーバー上にリソースに関する問題があるかどうかを確認し、適切な処置 (たとえば、リソースの追加) を取ってから、操作を再試行します。
0.0.0.0 のような IP アドレスを含む特殊用途のインタフェースを、管理エージェント内の HADB ノードが使用する有効なインタフェースとして登録するべきではありません。このようなインタフェースを登録すると、IP アドレスの代わりにホスト名を使用して hadbm create コマンドを発行するユーザーによってこのインタフェース上に HADB ノードが設定された場合に、問題が発生する場合があります。その場合、これらのノードは通信できなくなり、create コマンドはハングアップします。
複数のインタフェースを備えたホスト上で hadbm create を使用する場合は、DDN 形式を使用して IP アドレスを常に明示的に指定します。
Windows プラットフォームでは、特定の設定および負荷の下で、オペレーティングシステム内で多数の再構築の失敗が発生する場合があります。この問題は、20 を超えるノードが設定されている状況で、複数のテーブルスキャン (select *) を並列に実行している場合に発生しています。症状としては、トランザクションが頻繁に中断し、修復またはリカバリの完了に長い時間がかかるため、システムのさまざまな場所で頻繁にタイムアウトが発生していることが考えられます。
この問題を修正するには、Windows レジストリ変数 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters をデフォルトの 100 より大きい値に設定します。この値を 0x1000 ( 4096) に増やすことをお勧めします。詳細は、Microsoft サポートページの記事 811003 を参照してください。
マシンに負荷がかかっていると、マスク機構が機能せず、入力したパスワードの一部が表示されることがあります。パスワードが表示されることにより、軽度のセキュリティーリスクが生じます。パスワードは常にマスクされる必要があります。
パスワードを独自のパスワードファイルに入れて (Application Server 8.1 以降推奨されている方法)、--adminpassword または --dbpasswordfile オプションでこれらのファイルを参照します。
ここでは、インストール上の既知の問題とその解決方法を示します。
Apache および IIS は Java ES 5 インストーラでは設定できません。Apache および IIS は Windows プラットフォーム上で手動で設定する必要があります。
ロードバランサ Apache または IIS を設定するには、次の手順を実行します。
Apache 2.x を設定するには
Apache 2.x をインストールします。
Apache は APDIR=C:\Apache2\Apache2 ディレクトリにインストールされます。
JES5 を最小インストールでインストールします。
ロードバランサ以外のすべてのコンポーネントを選択解除します。Java ES 5 は JES5DIR=C:\Program Files\Sun\JavaES5 ディレクトリにインストールされます。
Apache2 ディレクトリに resource および errorpages ディレクトリを作成します。
mkdir %APDIR%\modules\resource
mkdir %APDIR%\modules\errorpages
リソースファイルを resource ディレクトリにコピーします。
cd %APDIR%\modules\resource
copy %JES5DIR%\appserver\lib\webserver-plugin\windows\apache2\LBPlugin*.res .
ロードバランサ DLL を modules ディレクトリにコピーします。
cd %APDIR%\modules
copy %JES5DIR%\appserver\lib\webserver-plugin\windows\apache2\mod_loadbalancer.dll .
テンプレート errorpages を errorpages ディレクトリにコピーします。
cd %APDIR%\modules\errprpages
copy %JES5DIR%appserver\lib\webserver-plugin\windows\iws\errorpages .
ロードバランサテンプレートとその他の DTD を Apache config ディレクトリにコピーします。
cd %APDIR%\config
copy %JES5DIR%\appserver\lib\install\templates\loadbalancer.xml.template .
copy %JES5DIR%\appserver\lib\dtds\sun-loadbalancer* .
httpd.conf ファイルのバックアップを作成します。
cd %APDIR%\config
copy httpd.conf httpd.conf.orig
httpd.conf ファイルを編集します。
httpd.conf ファイルに次の行を追加します。
##BEGIN EE LB Plugin Parameters LoadModule apachelbplugin_module modules/mod_loadbalancer.dll <IfModule mod_apache2lbplugin.cpp> config-file "C:\Apache2\Apache2/conf/loadbalancer.xml" locale en </IfModule> <VirtualHost 10.12.8.107> DocumentRoot "C:\Apache2\Apache2/htdocs" ServerName vm07 </VirtualHost> ##END EE LB Plugin Parameters
C:\Apache2\Apache2 を実際の %APDIR% ディレクトリに置き換えます。
IP、ServerName、および DocumentRoot ディレクトリも置き換えます。
%APDIR% に新しい sec_db_files ディレクトリを作成します。
cd %APDIR%
mkdir sec_db_files
NSS キーストアを %APDIR%\sec_db_files ディレクトリにコピーします。
cd %APDIR%\sec_db_files
copy %JES5DIR%\appserver\lib\webserver-plugin\windows\iis\*.db .
必要なライブラリが含まれるように PATH を設定します。
以下の追加パスを先頭に付加します。
PATH %JES5DIR%\share\lib;%JES5DIR%\appserver\lib;%JES5DIR%\appserver\bin
%JES5DIR% を実際の Java ES 5 ディレクトリに置き換えます。
システム環境変数に、値 1 の NSPR_NATIVE_THREADS_ONLY 変数を追加します。
リブートして Apache 2 をテストします (loadbalancer.xml の設定後)。
IIS LBPlugin を設定するには
c:\inetpub\wwwroot ディレクトリに sun-passthrough ディレクトリを作成します。
cd c:\inetpub\wwwroot
mkdir sun-passthrough
c:\inetpub\wwwroot\sun-passthrough ディレクトリに errorpages、resource および sec_db_files ディレクトリを作成します。
cd c:\inetpub\wwwroot\sun-passthrough
mkdir errorpages
mkdir resources
mkdir sec_db_files
DLL ファイルを sun-passthrough ディレクトリにコピーします。
copy <as_install_dir>/appserver/lib/webserver-plugin/iis/*.dll c:\inetpub\wwwroot\sun-passthrough\
DTD を sun-passthrough ディレクトリにコピーします。
copy <as_install_dir>/appserver/lib/dtds/sun-loadbalancer*.dtd c:\inetpub\wwwroot\sun-passthrough\
sun-passthrough.properties ファイルを sun-passthrough ディレクトリにコピーします。
copy <as_install_dir>/appserver/lib/webserver-plugin/iis c:\inetpub\wwwroot\sun-passthrough\
セキュリティー DB ファイルを sun-passthrough ディレクトリにコピーします。
copy <as_install_dir>/appserver/lib/webserver-plugin/iis/*.db c:\inetpub\wwwroot\sun-passthrough\sec_db_files\
リソースファイルを sun-passthrough ディレクトリにコピーします。
copy <as_install_dir>/appserver/lib/webserver-plugin/iws/*.res c:\inetpub\wwwroot\sun-passthrough\resource\
エラーページを sun-passthrough ディレクトリにコピーします。
copy <as_install_dir>/appserver/lib/webserver-plugin/iws/errorpages/*.html c:\inetpub\wwwroot\sun-passthrough\errorpages\
loadbalancer.xml.example テンプレートを sun-passthrough ディレクトリにコピーします。
copy <as_install_dir>/appserver/lib/install/templates/loadbalancer.xml.example c:\inetpub\wwwroot\sun-passthrough\
sun-passthrough.properties ファイルを編集します。
##BEGIN EE LB Plugin Parameters log-file = C:\InetPub\wwwroot\sun-passthrough\lb.log ### The valid options for different logging levels are FATAL, SEVERE, WARNING, INFO and FINE. log-level = INFO lb-config-file = C:\InetPub\wwwroot\sun-passthrough\loadbalancer.xml ##END EE LB Plugin Parameters
IIS6 を構成している場合、必ず AS82 マニュアルの説明に従って権限を設定し追加手順を実行してください。また、IIS6 遮断モードを IIS5 互換に設定する必要があります。
Windows プラットフォームでは、Application Server Enterprise Edition をインストールした直後に、Message Queue ブローカが起動に失敗します。ディレクトリ drive:\as\domains\domain1\imq が存在しないことを示すメッセージが表示されます。
domain1 を起動してからブローカを起動した場合には、Application Server によってディレクトリが作成され、この問題は発生しません。
ブローカを作成する前に var_home_dir_location を作成します。次のようにします。
$imqbrokerd -varhome var_home_dir_location |
次に例を示します。
$imqbrokerd -varhome D:\as\domains\domain1\imq |
Sun Java System Application Server Enterprise Edition 8.2 で J2EE 1.4 Tutorial を実行するには、次の作業を実行します。
「About this Tutorial」の章の「About the Examples」で説明されているファイル例 /common/build.properties を編集する場合には、ポート 4848 を 4849 に変更します。
deploytool を使用する場合、例を配備する前にサーバー localhost:4849 を追加します。
管理コンソールを使用して何らかのリソースを作成する場合には、「ターゲット」タブを使用してサーバーをターゲットとして指定します。コマンド行または asant ターゲットを使用する場合、サーバーがデフォルトのターゲットになるため、特別な処置は必要ありません。
ここでは、ライフサイクル管理に関する既知の問題とその解決方法を示します。
ejb-timer-service プロパティー minimum-delivery-interval を 9000 に設定したあとで、ejb-timer-service プロパティー redelivery-interval-in-mills を 7000 に設定しようとすると、set コマンドが失敗します。次のエラーメッセージが表示されます。
[echo] Doing admin task set [exec] [Attribute(id=redelivery-interval-internal-in-millis) : Redelivery- Interval (7,000) should be greater than or equal to Minimum-delivery- interval-in-millis (9,000)] [exec] CLI137 Command set failed.
minimum-delivery-interval は、同一の周期タイマーの最小発生間隔。
redelivery-interval-in-mills は、失敗した ejbTimeout のあとに再発生を試みるまでタイマーサービスが待機する時間。
これは、再発生間隔のプロパティを最小発生間隔のプロパティと関連付けるロジックが間違っていて、GUI または CLI を使って再発生間隔よりも最小発生間隔が大きくなるような値を設定できないという問題です。
minimum-delivery-interval-in-millis を、ejb-timer-service プロパティーの redelivery-interval-in-millis 以上の値に設定する必要があります。問題は、redelivery-interval-in-millis の値が minimum-delivery-interval-in-millis の値よりも大きいことを検証するための Application Server の処理にエラーがあることです。
次のように、これらプロパティーのデフォルト値を使用します。
minimum-delivery-interval(default)=7000 redelivery-interval-in-millis(default)=5000
これらデフォルト以外の値を指定するとエラーが発生します。
この節では、ログに関する既知の問題とその解決方法を示します。
JVM の java.security.debug オプションを設定すると、サーバーインスタンスの起動がデッドロックで動かなくなります。たとえば、domain.xml で次の設定を行うと、この問題が発生します。
<jvm-options\>-Djava.security.debug=access,failure</jvm-options\>
ありません。このフラグは設定しないでください。
Sun Java System 8.2 では、バージョン 7 および互換バージョンと比べて、デフォルトのログの場所やサーバーインスタンスの場所が変更されています。
詳細については、『Sun Java System Application Server Enterprise Edition 8.2 管理ガイド』または『Sun Java System Application Server Enterprise Edition 8.2 アップグレードと移行』を参照してください。
ここでは、Java メッセージキューに関する既知の問題とその解決方法を示します。
タイミングに依存する場面での再接続の失敗は、さまざまな問題によって引き起こされます。
これらの問題は、次の方法で回避できます。
関連するブローカを再起動する
関連する Application Server インスタンスを再起動する
最新の変更により、非同期メッセージリスナーが app-client コンテナの唯一の稼働しているスレッドである場合、残っている appclient 仮想マシンはデーモンとして存在します。この動作は、ACC で非同期受信を実行する過去のアプリケーションの影響です。この問題は、JMS メッセージリスナーを設定してメインスレッドを終了するアプリケーションクライアントに影響します。
メインスレッドを終了しないでください。メッセージリスナーがメインスレッドに通知するのを待ってから、メインスレッドを終了します。
ここでは、監視上の既知の問題とその解決方法を示します。
Application Server のベータリリースにおいては、デフォルトでは監視フレームワークはサポートされていません。
解決方法
監視フレームワークを Application Server に統合するには、次の手順を実行します。
<Install_dir>\appserver\lib\install\templates\ee\com.sun.cmm.as.xml ファイルを編集します。
${InstalledDate} を Application Server のインストール場所で更新して、${InstalledDate} を現在日付にします。
<Install_dir>\appserver\lib\install\templates\ee\com.sun.cmm.as.xml ファイルを <Install_dir>\appserver\lib にコピーします。
<MFWK_Install_location>\bin\mfwksetup.bat -r <Install_dir>\appserver\lib\com.sun.cmm.as.xml コマンドを実行します。
${InstalledLocation} の値は Application Server インストールの場所、c:\Sun\JavaES5\appserver です。$InstalledDate にはミリ秒で時間を入力する必要があります (1970 年から現在時間 (ミリ秒) を計算)。
ここでは、Application Server 8.2 製品に付属するサンプルコードに関する既知の問題とその解決方法を示します。
Windows プラットフォームでは、mqfailover コマンドが表示されたら Ctrl+C を押してハングアップしたプロセスを終了させて、setup-one-machine-cluster プロセスを再実行する必要があります。
install_dir\samples\ee-samples\failover\apps\mqfailover\docs\index.html を参照してから、次のコマンドを実行します。
コンソール 1
cd install_dir\samples\ee-samples asant start-mq-master-broker1 |
コンソール 2
cd install_dir\samples\ee-samples asant start-mq-cluster-broker1 |
コンソール 3
cd install_dir\samples\ee-samples asant start-mq-cluster-broker2 |
コンソール 4
cd install_dir\samples\ee-samples asadmin start-domain domain1 |
ほかの Enterprise Edition サンプルで asant setup-one-machine-cluster-without-ha または asant setup-one-machine-cluster-with-ha を実行済みであれば、asant configure-mq を実行します。そうでない場合には asant setup-one-machine-cluster-and-configure-mq を実行します。この場合、次に示すように、コマンドが正常に実行されたように見えます。
start_nodeagent: [echo] Start the node agent cluster1-nodeagent [exec] Command start-node-agent executed successfully. |
しかし、このあとシステムはハングアップします。
ありません。この問題は、Windows でこの ant ターゲットを使用するすべての Enterprise Edition サンプルに同様に影響します。回避策は、ハングアップしたプロセスを Ctrl+C で終了してから再実行することです。
asadmin の配備手順を終了して、Message Queue フェイルオーバーのサンプルアプリケーションを実行後、次のエラーメッセージが表示されます。
/opt/SUNWappserver/domains/domain1/config/sun-acc.xml -name MQFailoverTestClient -textauth -user j2ee -password j2ee Nov 18, 2004 10:50:17 PM com.sun.enterprise.naming.NamingManagerImpl bindObjects SEVERE: NAM0006: JMS Destination object not found: jms/durable/TopicA Nov 18, 2004 10:50:18 PM com.sun.enterprise.naming.NamingManagerImpl bindObjects SEVERE: javax.naming.NameNotFoundException javax.naming.NameNotFoundException |
asadmin deploy コマンドを使用して手動配備を行う場合に JMS リソースを手動で作成する必要があることが、マニュアルに明記されていません。サンプルアプリケーションを配備するために用意されている ant ターゲットを使用する必要があることも明記されていません。
build.xml スクリプト用に asant deploy ターゲットを使用します。これにより、アプリケーションを実行するために必要とされる JMS リソースが作成されます。
ここでは、Application Server と Web アプリケーションのセキュリティーおよび証明書に関する既知の問題とその解決方法を示します。
WebServiceSecurity アプリケーションは、次の理由から J2SE 5.0 で実行できません。
J2SE 5.0 の PKCS11 は、UNWRAP モードをサポートしない
J2SE 5.0 の PKCS11 は、PKCS11 による RSA/ECB/OAEPWithSHA1AndMGF1Padding をサポートしない
J2SE 1.4.2 で別の JCE プロバイダ (デフォルトで含まれているもの以外) を使用します。この構成では、ハードウェアアクセラレータはサポートされません。
ロードバランサ (ハードウェア) を SSL 終了用に設定すると、リダイレクト中に Application Server がプロトコルを https から http に変更します。
ハードウェアロードバランサと Application Server の間にソフトウェアロードバランサを追加します。
この節では、アップグレードユーティリティーに関する既知の問題とその解決方法を示します。
このバグには、次の 2 つの面があります。
Derby データベースを使用するサンプルアプリケーション設定スクリプトを実行すると、Derby データベースが現在のディレクトリまたは <install_root>/bin に作成されます。
サンプル build Ant スクリプトによって、管理パスワードファイルを保存する password.txt ファイルが現在のディレクトリの下に作成されますが、このディレクトリはルート以外の疎ゾーンシナリオでは書き込み可能ではありません。
Derby データベースの場所 – start-database コマンドで --dbhome オプションを使用して、--dbhome に指定された値の場所にデータベースを作成します。たとえば、次の例は、start-database 用の asadmin コマンドの構文です。
start-database [--dbhost 0.0.0.0] [--dbport 1527] [--dbhome db_directory] [--echo=false] [--verbose=false] |
password.txt ファイルの場所 – 設計上、サンプルディレクトリは書き込み可能であると想定されています。これは、すべてのビルドコマンドにそのディレクトリでの password.txt ファイルの作成が含まれているためです。書き込み可能な場所にサンプルの作業用コピーをインストールするようにしてください。
Application Server Enterprise Edition 8.2 インストールでは、管理ユーザー名に特殊文字は使用できません。特殊文字を使用すると、ドメインの作成は失敗します。ただし、管理パスワードには特殊文字を使用できます。
Application Server 7 から Application Server 8.2 にアップグレードするときに、管理ユーザー名に特殊文字が含まれていないことを確認してください。
ここでは、Web コンテナに関する既知の問題とその解決方法を示します。
Sun Java ES 5 Application Server ではロードバランサプラグインで Apache および IIS (Sun 以外の Web コンテナ) がサポートされていません。Sun Java ES ではロードバランサプラグインの設定用に Sun Java System Web Server がインストールされます。
Windows プラットフォームで Microsoft Windows 上のアプリケーションを配備するときに JSP のプリコンパイルを要求すると、それ以降、そのアプリケーションの配備取り消しや、そのアプリケーション (または同一モジュール ID を持つ任意のアプリケーション) の再配備を試みても、予期したとおりに動作しません。JSP のプリコンパイル処理でアプリケーションの JAR ファイルが開かれたまま閉じられないため、これらのファイルを配備取り消しで削除することや、これらのファイルを再配備で上書きすることが Microsoft Windows によって許可されません。
配備取り消しは、Application Server からアプリケーションが論理的に削除されるという点では成功します。また、asadmin ユーティリティーからエラーメッセージは返されませんが、そのアプリケーションのディレクトリとロックされた jar ファイルはサーバー上に残っています。サーバーのログファイルには、ファイルとアプリケーションディレクトリの削除に失敗した旨のメッセージが出力されます。
配備取り消し後のアプリケーションの再配備が失敗するのは、既存のファイルとディレクトリをサーバーが削除しようとして失敗するからです。これは、最初に配備されたアプリケーションと同じモジュール ID を持つアプリケーションを配備しようとしたときにも発生します。アプリケーションのファイルを保持するディレクトリの名前を、サーバーはモジュール ID から決定するからです。
同様の理由から、配備取り消しをせずにアプリケーションを再配備しようとすると失敗します。
診断
アプリケーションを再配備しようとすると、または、配備取り消しを行なってから配備しようとすると、asadmin ユーティリティーは次のようなエラーを返します。
An exception occurred while running the command. The exception message is: CLI171 Command deploy failed : Deploying application in domain failed; Cannot deploy. Module directory is locked and can't be deleted. |
アプリケーションを配備するときに --precompilejsps=false (デフォルトの設定) を指定すると、この問題は発生しません。そのアプリケーションを最初に使用するときに JSP コンパイルが起動されるため、最初の要求に対する応答時間は、その後の要求に比べて長くなります。
また、プリコンパイルを行う場合には、そのアプリケーションを配備取り消しまたは再配備する前に、サーバーを終了して再起動する必要があります。シャットダウンすると、ロックされている JAR ファイルが解放されるため、再起動後の配備取り消しや再配備が成功します。
web.xml ファイルのオプションの load-on-startup 要素は、サーブレットを宣言する Web アプリケーションの起動の一環として、そのサーブレットをロードおよび初期化すべきことを示します。
この要素のオプションの内容は、Web アプリケーションのその他のサーブレットとの関係で、そのサーブレットをロードおよび初期化する順序を示す整数です。空の <load-on-startup> 要素は、そのサーブレットを含む Web アプリケーションの起動時にそのサーブレットがロードおよび初期化される場合、その順序は意味を持たないことを表します。
web.xml の Servlet 2.4 スキーマでは、空の <load-on-startup> はサポートされなくなりました。つまり、Servlet 2.4 ベースの web.xml ファイルを使用する場合は整数値を指定する必要があります。<load-on-startup/> の場合と同様に、空の <load-on-startup> を指定すると、web.xml が web.xml の Servlet 2.4 スキーマに対する妥当性検証に失敗するため、Web アプリケーションの配備も失敗します。
下位互換性の問題もあります。空の <load-on-startup> は、Servlet 2.3 ベースの web.xml では有効です。
Servlet 2.4 ベースの web.xml を使用する場合は、<load-on-startup>0</load-on-startup> を指定して、サーブレットの読み込み順序が問題にならないことを示します。
JSP ページにアクセスしてもコンパイルに失敗し、サーバーログには「Unable to execute command」というエラーメッセージと次のスタックトレースが記録されます。
at org.apache.tools.ant.taskdefs.Execute$Java13CommandLauncher. exec(Execute.java:655) at org.apache.tools.ant.taskdefs.Execute. launch(Execute.java:416) at org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:427) at org.apache.tools.ant.taskdefs.compilers.DefaultCompilerAdapter. executeExternalCompile(DefaultCompilerAdapter.java:448) at org.apache.tools.ant.taskdefs.compilers.JavacExternal.execute (JavacExternal.java:81) at org.apache.tools.ant.taskdefs.Javac.compile(Javac.java:842) at org.apache.tools.ant.taskdefs.Javac.execute(Javac.java:682) at org.apache.jasper.compiler.Compiler.generateClass(Compiler.java:396) |
JSP のコンパイルスイッチを「fork」から「false」に設定します。
次のいずれかの方法でこの設定を行うことができます。
グローバルに行うには、次のように、${S1AS_HOME}/domains/domain1/config/default-web.xml 内の JspServlet の fork init パラメータを false に設定します。
<servlet> <servlet-name>jsp</servlet-name> <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class> .... <init-param> <param-name>fork</param-name> <param-value>false</param-value> </init-param> .... </servlet> |
Web アプリケーションごとに、sun-web.xml の JSP 設定プロパティー fork を false に設定します。次のようにします。
<sun-web-app> <jsp-config> <property name="fork" value="false" /> </jsp-config> </sun-web-app> |
これらのいずれかを設定することにより、Ant が javac コンパイルのための新規プロセスを生成することが防止されます。
Sun Java System Application Server Enterprise Edition 8.2 では、Sun Java System Application Server Enterprise Edition 7.1 で使用できる auth-passthrough プラグイン機能が提供する機能に対するサポートが追加されています。ただし、Application Server Enterprise Edition 8.2 での auth-passthrough プラグイン機能の設定方法は異なります。
Application Server Enterprise Edition 7.1 での auth-passthrough プラグイン関数は、次の制約のある 2 層配備のシナリオで有効でした。
Application Server インスタンスは、企業ファイアウォールの内側にある 2 番目のファイアウォールによって保護される。
Application Server インスタンスへの直接のクライアント接続は許可されない。
このようなネットワークアーキテクチャーの場合、クライアントは、service-passthrough プラグイン関数で設定されたフロントエンド Web サーバーに接続し、HTTP 要求を、プロキシされた Application Server インスタンスに転送して処理します。Application Server インスタンスは、要求をクライアントホストから直接にではなく、Web サーバープロキシからしか受信できません。その結果、プロキシされた Application Server インスタンス上に配備され、クライアントの IP アドレスなどのクライアント情報を照会する任意のアプリケーションは、中継された要求の実際の発信元ホストであるプロキシホストの IP を受信します。
Application Server Enterprise Edition 7.1 では、プロキシされた Application Server インスタンス上で、そのインスタンス上に配備された任意のアプリケーションがリモートクライアントの情報を直接使用するように auth-passthrough プラグイン関数を設定できました。その場合は、プロキシされた Application Server インスタンスが、service-passthrough プラグインを実行している中間の Web サーバー経由ではなく、要求を直接受信したかのように見えます。
Application Server Enterprise Edition 8.2 では、domain.xml 内の <http-service> 要素の authPassthroughEnabled プロパティーを TRUE に設定することにより、auth-passthrough 機能を有効にすることができます。次に例を示します。
<property name="authPassthroughEnabled" value="true"/> |
Application Server Enterprise Edition 7.1 にある auth-passthrough プラグイン関数のセキュリティーに関する同じ注意点が、Application Server Enterprise Edition 8.2 にある authPassthroughEnabled プロパティーにも適用されます。authPassthroughEnabled によって、認証目的に使用される可能性のある情報 (要求発信元の IP アドレスや SSL クライアント証明書など) を上書きすることが可能になるため、authPassthroughEnabled を TRUE に設定して、Application Server Enterprise Edition 8.2 インスタンスへの接続を許可する場合は、その対象を信頼できるクライアントまたはサーバーだけに限定する必要があります。予防措置として、authPassthroughEnabled を TRUE に設定するのは、企業ファイアウォールの内側にあるサーバーだけにすることをお勧めします。インターネット経由でアクセス可能なサーバーでは、決して authPassthroughEnabled を TRUE に設定しないでください。
プロキシ Web サーバーが service-passthrough プラグインを使用して設定されており、要求を authPassthroughEnabled が TRUE に設定された Application Server 8.1 Update 2 インスタンスに転送するシナリオでは、SSL クライアント認証は Web サーバープロキシ上で有効になり、プロキシされた Application Server 8.1 Update 2 インスタンス上で無効になる可能性があることに注意してください。この場合、プロキシされた Application Server 8.1 Update 2 インスタンスは、SSL 経由で認証されたかのように引き続き要求を処理し、クライアントの SSL 証明書を、それを要求している任意の配備されたアプリケーションに提供します。
--enabled=false フラグで httplistener を作成すると、リスナーは無効になりません。フラグ --enabled は、リスナーの作成と同時に使用すると効果がありません。
リスナーを使用可能状態で作成して、あとで手動で無効にしてください。