ここでは、Sun Java System Application Server 9.1 ソフトウェアに関する既知の問題とそれに関連する回避方法について説明します。問題の説明にプラットフォームが明記されていない場合、その問題はすべてのプラットフォームに当てはまります。この内容は次の項目から構成されています。
ここでは、管理上の既知の問題とその解決方法を示します。
デフォルトでは、$INSTALL/lib/package-appclient.xml に、asenv.conf によってポイントされる domain1 の AS_ACC_CONFIG 変数用にハードコードされた値があります。domain1 を削除して新たなドメインを作成した場合、AS_ACC_CONFIG 変数は新たなドメイン名で更新されません。その結果、package-appclient スクリプトの処理が失敗します。
次のいずれかを実行します。
domain1 はそのままにしておき、その前後に別のドメインを作成します。
domain1 を削除し、$INSTALL/lib/package-appclient.xml で domain1 用にハードコードされた値を、新たなドメイン名で置き換えます。
domain1 がない場合、新たなドメインが作成されるたびにこれを行う必要があります。
同一の Application Server 上でのドメインのミラー化は、backup-domain および restore-domain コマンドでは行えません。asadmin restore-domain コマンドにはドメインをリネームするオプションがありますが、元の名前とは違う名前でドメインを復元することはできないからです。バックアップ取得したドメインのリネームは正常に行われたように見えますが、そのリネームされたドメインの起動は失敗します。ドメイン設定のエントリは変更されておらず、startserv および stopserv は元のドメイン名を使用してパスを設定するからです。
restore-domain で使用するドメイン名は、元の backup-domain コマンドで使用したドメイン名と同じである必要があります。Application Server 8.1 での backup-domain および restore-domain コマンドは、同一マシン上の同一ドメインのバックアップおよび復元についてだけ有効です。
Application Server では、J2SE 1.4.x または 5.0 以降を設定できます。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 の管理コンソールやコマンド行インタフェースで予期しない結果が発生することがあります。問題は、組み込みの jmx-connector サーバーと新たな jmx-connector サーバーとの間で衝突が発生することにあります。
jconsole または何らかの JMX 互換クライアントを使用する場合には、Application Server とともに起動する標準の JMX コネクタサーバーを再利用することを検討してください。
サーバーの起動時に、次に示すような行が server.log に作成されます。ここで指定されている JMXService の URL に接続し、資格を正常に指定したあと、同様の管理および設定操作を実行することができます。次に例を示します。
[#|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 9.1 Administration Guide 』を参照してください。
ユーザー「A」としてログインして asadmin restore-domain コマンドを実行すると、そのスクリプトのアクセス権は 744 (rwxr--r--
) になります。そのあとでユーザー「B」としてドメインを起動または停止しようとすると、たとえ「B」が root であっても、その試みは失敗します。ユーザー「A」についてだけスクリプトが実行可能だからです。
スクリプトのアクセス権を次のようにして変更します。
chmod 755 appserv/domains/domain-name/bin/* |
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 サービスのコンテキストルート名に置き換えます。
既存の <as_install>/bin/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 スクリプトに結合します。
Application Server のマニュアルに .asadmintruststore ファイルが記述されていません。このファイルがサーバー管理者の home ディレクトリに存在しないと、そのサーバー上にホストされている特定のアプリケーションをアップグレードしたときに重大なバグが発生する場合があります。
可能であれば、そのサーバーをインストールしたユーザーが asadmin start-domain domain1 コマンドを実行してください。
そのユーザーがこのコマンドを実行できない場合は、.asadmintruststore を、インストールしたユーザーの home ディレクトリから実行中のユーザーの home ディレクトリに移動またはコピーしてください。
このファイルをインストールユーザーの home ディレクトリから実行中のユーザーの home ディレクトリに (コピーではなく) 移動した場合は、アップグレードまたはインストールしたユーザーのホームディレクトリ (Java ES では、通常 root) に .asadminstruststore ファイルが存在しなくなるため、バグ 6309079、6310428、および 6312869 で説明されているようなアプリケーションのアップグレードに関する問題が発生する可能性があることに注意してください。
Application Server クラスタインスタンスのデフォルト MQ 統合モードは LOCAL です。Application Server がインストールされている場所の PATH が長い、つまり短くない場合、クラスタインスタンス起動時に imqbrokerscv.exe で障害が発生します。imqbrokersvc のメモリー割り当てに問題があります。
クラスタインスタンスの JMS サービスタイプを、デフォルトの LOCAL から REMOTE に変更する必要があります。この設定では、すべてのインスタンスは DAS ブローカを指します。次の手順に従って、REMOTE モードでクラスタを設定してください。
REMOTE モード使用時には、すべてのインスタンスが 1 つのブローカ (DAS) を使用しているため、Application Server クラスタが起動してもブローカクラスタは作成されません。詳細については、http://www.glassfishwiki.org/gfwiki/attach/OnePagersOrFunctionalSpecs/as-mq-integration-gfv2.txt にある One Pager の 4.1 節、iii 項「Auto-clustering」を参照してください。それによると、上記の機能は将来使用できなくなります。
ご使用の環境に合わせて、ポートおよびパスワードファイルを変更してください。次に示す手順では、クラスタ名が racluster、DAS 管理ポートが 5858、および DAS JMS ポートが 7676 になっています。
JMS タイプを REMOTE に変更して、クラスタ設定を変更します。
$AS91_HOME/bin/asadmin.bat set --port 5858 --user admin --passwordfile \ $AS91_HOME/bin/password_file racluster.jms-service.type=REMOTE |
DAS JMS ホストに対応する JMS ホストを作成します。
$AS91_HOME/bin/asadmin.bat create-jms-host --port 5858 --user admin --passwordfile \ $AS91_HOME/bin/ password_file --target racluster --mqhost localhost --mqport 7676 \ --mquser admin --mqpassword admin dashost |
デフォルトの JMS ホストが前のステップで作成した DAS JMS ホストになるように設定します。
$AS91_HOME/bin/asadmin.bat set --port 5858 --user admin --passwordfile \ $AS91_HOME/bin/password_file racluster.jms-service.default-jms-host=dashost |
「設定」->「cluster_name-config」->「Java メッセージサービス」->「JMS ホスト」の順に移動します。
「新規」をクリックして新規 JMS ホストを作成し、dashost という名前を付けます。
DAS の JMS サービスに対応する設定を入力します。デフォルト設定は次のとおりです。
ホスト名: localhost
ポート: 7676
管理者ユーザー: admin
パスワード: admin
これらの設定をご使用の DAS JMS サービスに適した値に変更してください。
「Java メッセージサービス」タブに戻って、JMS サービスタイプを REMOTE に変更します (デフォルトは LOCAL)。
default-jms-host ドロップダウンリストから dashost を選択します。
変更を保存してから、ノードエージェントまたはクラスタを起動します。
「ログ統計の監視」ページから一部のサポートされていないブラウザを使用してチャートを表示しようとすると、次のエラーがスローされます。
Error loading jmaki.widgets.jmaki.charting.line.Widget : id=form1:jmaki_chart11 Script: http://easqelx5. red.iplanet.com:4848/resources/jmaki/charting/ \ line/component.js (line:5437). Message: area.initialize is not a function |
サポートされているブラウザを使用します。Application Server 9.1 でサポートされているブラウザについては、「ブラウザ」を参照してください。
Application Server の過去 3 回のメジャーリリースのたびに、デフォルト管理ポートが変わっていました。具体的には、7.x、8. x、および 9.x のデフォルト管理ポートは次のようになっていました。
AS 7.x: 4848
AS 8.x: 4849
AS 9.x: 4848
これはバグではありませんが、このことに注意してください。デフォルト管理ポートは推奨値に過ぎません。今後の Application Server リリースでは、デフォルトに 4848 ポートが継続して使用されます。
ここでは、Apache Web Server およびロードバランサプラグインに関する既知の問題と、それに関連する解決法を示します。
openssl のコンパイルと作成を行う場合は、次のコマンドを実行します。
cd openssl-0.9.7e
config
make
また、Apache 1.3 では、mod_ssl ソースのディレクトリ名も、使用している Apache のリリースに応じて変わります。たとえば、Apache 1.3.33 の場合、この名前は mod_ssl-2.8.22-1.3.33 になります。
Apache のセキュリティーを実行するには、証明書を使用する必要があります。認証局から証明書を取得するための手順については、modssl FAQ にある証明書に関する情報を参照してください。
Solaris では、Application Server がルートの下にインストールされている場合、Apache Web Server をルートとして起動する必要があります。Java Enterprise System は、ルートとしてインストールされます。Apache 2.0 の場合、ルートとして起動されたあと、Apache はユーザーが指定した別のユーザーに切り替えて動作します。そのユーザーは、/conf/httpd.conf ファイルで指定します。多くのシステムでは、ルートとして起動するには、httpd.conf ファイルを編集して正しいグループを指定する必要があります。次の行を
Group #-1
次の行に置き換えます。
Group nobody
ユーザーおよびグループの使用に関する詳細情報は、httpd.conf ファイルに記載されています。
ここでは、アプリケーションクライアントに関する既知の問題とその解決方法を示します。
クライアント JAR (たとえば reporter.jar) 内に最上位レベルの JAR ファイルがある場合、クライアント JAR を配備すると、その JAR の MANIFEST ファイルがクライアント JAR の MANIFEST ファイルを上書きします。
現時点ではありません。
アプリケーションクライアントが常に localhost:3700 に接続しようとします。問題は、クライアントノードを呼び出す前に、一部のシステムプロパティーが読み取られていなければならないことにあります。
次をシステムプロパティーとして ( JAVA_CMD に -D を指定して) 設定します。これらを appclient コードで設定しないでください。
org.omg.CORBA.ORBInitialHost = server_instance_host org.omg.CORBA.ORBInitialPort = server_instance_port |
64 ビット Linux 上で実行している場合、ドメイン開始時次の例外があります。問題は jdk1.5.0_11/jre/lib/ext/ の下に sunpkcs11.jar がないことです。
これは 64 ビット Linux で既知の JDK バグであり、JDK 1.5.0_13 で修正されます。
複数のセレクタに SocketChannel が登録されている場合、socketChannel.keyFor(lastRegisteredSelector) を実行すると SelectionKey の代わりに NULL が返されます。
これは JDK バグ 6562829 に関連しており、6.0 U3 で修正される予定です。回避方法は Application Server 9.1 に組み込まれており、keyFor API を読み込む前はセレクタがラップ解除されています。これにより、JDK バグが修正されるまで、keyFor の正常な動作が可能になっています。
ここでは、Sun の JDBC ドライバに関する既知の問題とその解決方法を示します。
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 9.1 Administration Guide』を参照してください。
前述の 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 9.1 Administration Guide』を参照してください。
ホストシステムまたは Solaris ゾーンのリブート後、または Application Server 起動後に、付属の Java DB データベースが自動的に再起動しません。これはバグではなく、付属または他社製のアプリケーションで所定の動作です。問題は、Application Server インスタンスの前に Java DB を起動する必要があるということです。
ホストマシンまたは Solaris ゾーンのリブート後、必ず Application Server が開始する前に Java DB が起動するようにしてください。一例として、次のようにします。
/opt/SUNWappserver/appserver/bin/asadmin start-database |
asadmin コマンドのオプションについては、『Sun Java System Application Server 9.1 Quick Start Guide 』 の 「Application Server Administration Tools」 を参照してください。
ここでは、マニュアル上の既知の問題とその解決方法を示します。
いくつかの AMX インタフェースおよびメソッドについて、Javadoc が欠けているか間違っています。
NumConnAcquired および NumConnReleased 統計情報の取得メソッドが ConnectorConnectionPoolStats および AltJDBCConnectionPoolStats から抜けている。これらの取得メソッドは、将来のリリースで getNumConnAcquired() および getNumConnReleased() として追加される予定。
EJBCacheStats 内でメソッド getPassivationSuccesses()、getExpiredSessionsRemoved()、getPassivationErrors()、getPassivations() を呼び出すと、例外がスローされる。これは将来のリリースで解決される予定。
サーバーを起動したあと、すべての AMX MBeans が登録されて利用できるようになるまでに数秒を要することがある。将来のリリースでは、AMX MBeans が完全にロードされたことを確認できるようになる予定。
定数 XTypes.CONNNECTOR_CONNECTION_POOL_MONITOR のスペルが間違っている ("NNN" の部分)。これは将来のリリースで訂正される予定。
スレッド「main」で java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher の例外がスローされます。
付属の ANT を Application Server の外部で使用することはお勧めできません。
ここでは、高可用性データベース (HADB) に関する既知の問題とその解決方法を示します。
2 つのサブネット上にダブルネットワークで設定された HADB は、Solaris SPARC 上では正常に動作します。しかし、一部のハードウェアプラットフォームでのオペレーティングシステムまたはネットワークドライバの問題が原因で、Solaris x86 および Linux プラットフォームではダブルネットワークを適切に処理できない場合があります。これにより、HADB について次の問題が発生します。
Linux では、メッセージ送信の際に HADB プロセスがブロックされることがある。これにより、HADB ノードが再起動し、ネットワークパーティションが発生する。
Solaris x86 では、ネットワーク障害が発生した場合、もう一方のネットワークインタフェースへの切り替えを妨げる問題が発生することがある。この問題は常に発生するとは限らないため、ネットワークが 1 つしかないよりも 2 つあった方が安全である。この問題は、Solaris 10 で部分的に解決されている。
トランキングがサポートされない。
Windows 2003 では、HADB はダブルネットワークをサポートしていない (ID 5103186)。
新しいデータベースを作成すると、使用可能な共有メモリーセグメントが少なすぎるという、次のエラーで失敗することがあります。
HADB-E-21054:System resource is unavailable:HADB-S-05512:Attaching shared memory segment with key "xxxxx" failed, OS status=24 OS error message:Too many open files.
共有メモリーが設定されており、その設定が機能していることを確認します。特に、Solaris 8 では、/etc/system ファイルを調べて、変数 shmsys:shminfo_shmseg の値がホストあたりのノード数の 6 倍以上になっていることを確認します。
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 で識別される) 内のすべてのファイルとディレクトリを削除します。この操作は、新しい設定ファイルを使用してエージェントを再起動する前に、すべてのホスト上で実行する必要があります。
Solaris 10 Opteron では、hadbm コマンドを使用して HADB を起動、停止、または再設定すると、次のいずれかのエラーで失敗またはハングアップする場合があります。
hadbm:Error 22009: The command issued had no progress in the last 300 seconds. HADB-E-21070: The operation did not complete within the time limit, but has not been cancelled and may complete at a later time. |
このエラーは、clu_noman_srv プロセスが使用するファイル (nomandevice) への読み取り/書き込みに不整合があった場合に発生することがあります。この問題は、HADB 履歴ファイルで次のメッセージを検索することにより検出できます。
n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Child process noman3 733 does not respond. n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Have not heard from it in 104.537454 sec. n:3 NSUP INF 2005-02-11 18:00:33.844 p:731 Child process noman3 733 did not start. |
問題を手動で再現できていないため、次の回避策はまだ検証されていません。ただし、影響を受けるノードに対してこのコマンドを実行すれば、問題は解決されます。
hadbm restartnode --level=clear nodeno dbname |
ノードのすべてのデバイスが再初期化されるわけではないことに注意してください。再初期化する前に、ノードの停止が必要になる場合があります。
複数の NIC カードが実装された、Solaris 8 を実行しているホスト上で起動されている場合、IPv6 と IPv4 が有効になったカードが混在していると、管理エージェントが例外「IPV6_MULTICAST_IF failed」で終了することがあります。
環境変数 JAVA_OPTIONS を -Djava.net.preferIPv4Stack=true に設定します。次に例を示します。
export JAVA_OPTIONS="-Djava.net.preferIPv4Stack=true" |
あるいは、この問題が発生しない Solaris 9 以降を使用します。
Red Hat Enterprise Linux 3.0 の 64 ビットバージョンには、非同期入出力の実行中に clu_trans_srv プロセスを中断不可能なモードに陥らせるバグが存在します。つまり、kill -9 が機能せず、オペレーティングシステムの再起動が必要になります。
Red Hat Enterprise Linux 3.0 の 32 ビットバージョンを使用します。
パスワードが hadb に格納されるときに、パスワード内の大文字は小文字に変換されます。
大文字を含むパスワードは使用しないでください。
以前の HADB バージョンにダウングレードすると、管理エージェントが各種のエラーコードで失敗する場合があります。
HADB データベースのダウングレードは可能ですが、リポジトリオブジェクトが変更されている場合は管理エージェントをダウングレードできません。ダウングレードのあとも、最新の HADB バージョンの管理エージェントを使用し続ける必要があります。
HADB c パッケージ (Solaris: SUNWhadbc、Linux: sun-hadb-c) バージョン <m.n.u-p> のインストールまたは削除に関しては、symlink /opt/SUNWhadb/<m> はいったん作成されると、そのあとは何も手を加えられません。そのため、切り離された symlink が存在することがあり得ます。
使用中の場合を除き、インストールの前またはアンインストールのあとに symlink を削除します。
Solaris 10 では、大域ゾーンで ma-initd スクリプトを使用して管理エージェントを停止すると、ローカルゾーンの管理エージェントも停止されます。
管理エージェントを大域ゾーンとローカルゾーンの両方にインストールしないでください。
場合によっては、サーバー上のリソース競合の問題によって管理クライアントが切断されることがあります。再接続時、「hadbm:Error 22184:A password is required to connect to the management agent」という紛らわしいエラーメッセージが返されることがあります。
場合によっては、サーバー上のリソース競合の問題によって管理クライアントが切断されることがあります。再接続時、「hadbm:Error 22184:A password is required to connect to the management agent」という紛らわしいエラーメッセージが返されることがあります。
サーバー上にリソースに関する問題があるかどうかを確認し、適切な処置 (たとえば、リソースの追加) を取ってから、操作を再試行します。
Java Enterprise System を使用して (ルートとして) インストールすると、ルート以外のユーザーは HADB を管理できなくなります。
HADB を管理するには、常にルートとしてログインします。
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 を参照してください。
cookie のパスが「/」と等価であった場合、持続タイプとしてインメモリーレプリケーションを使用する「/」以外のコンテキストルートに配備された高可用性 Web アプリケーションの cookie と干渉し、高可用性 Web アプリケーションが HTTP セッション状態をまったく保持できなくなります。この状況になる可能性のある 1 つの一般的なシナリオは、同じブラウザを使用して「/」に配備されている管理 GUI と高可用性 Web アプリケーションとの両方にアクセスしている場合です。
別のブラウザから「/」に配備されている Web アプリケーションにアクセスします。
ロードバランサが Windows IIS 6 と連動するには、SASL32.DLL と ZLIB.DLL のファイルが必要です。これらのファイルは現在 <appsrver-install> /lib に含まれていません。
この 2 つの DLL ファイルを手動で <appserver-install> /lib にコピーします。これらのファイルは次の場所からダウンロードできます。
http://download.java.net/javaee5/external/<OS>/aslb/jars/aslb-9.1-MS4-b5.jar |
<OS> は希望するプラットフォームを表し、次の値のいずれかになります。
SunOS
SunOS_X86
Linux
WINNT
大域ゾーンで Application Server を高可用性パッケージとともにインストールまたはアンインストールすると、次の 2 つの問題が起きます。
HA パッケージがすべてのゾーンにインストールされます。これは望ましくありません。
アンインストール時に、HA、MQ、JDK パッケージがすべてのゾーンから削除されます。これも望ましくありません。
ルートローカルゾーンからインストールまたはアンインストールする場合には、この問題は起きません。
グルーバルゾーンではなくローカルルートゾーンからインストールまたはアンインストールを実行します。
「/」に配備された高可用性 Web アプリケーションは、持続タイプとしてインメモリーレプリケーションを使用している場合、HTTP セッションを保持できません。
インメモリーレプリケーションを持続タイプとして使用する高可用性 Web アプリケーションを「/」以外のコンテキストルートに配備します。このような Web アプリケーションを「/」で利用できるようにするには、Web アプリケーションが配備されている仮想サーバーの default-web-module として指定します。
Solaris 上で Apache 用の Application Server ロードバランサをインストール中に、インストーラは apachectl スクリプトの LD_LIBRARY_PATH を更新します。しかし、インストーラは /usr/lib/mps パスを正しく書き込みません。Solaris の場合、LD_LIBRARY_PATH にこのパスがないと、Apache セキュリティーインスタンスは開始しません。
この問題は Solaris プラットフォームでのみ起きます。この問題を回避するために、LD_LIBRARY_PATH に /opt/SUNWappserver/appserver/lib/lbplugin/lib を追加します。
domain.xml に保存されている内容にかかわりなく、「クラスタ/インスタンス」一般情報ページで「ロードバランスの有効化」ボタンが常にオンになっています。
クラスタ化されたインスタンスの場合、「インスタンス」タブを選択し、表プルダウンから「休止」アクションをクリックします。
スタンドアロンインスタンスの場合、インスタンスが実行中であることを確認してから、インスタンスの「一般」画面で「休止」ボタンをクリックします。
(Solaris のみ) HADB 導入済みの SPARC Solaris 10 に Application Server 9.1 をインストール後に、Application Server を開始して JES 5 UR1 をレジストリサーバーとともにインストールしようとすると、次のエラーを受け取ることがあります。
Dependency Error: Installation can not proceed because the version of HA Session Store 4.4.3 detected on this host is incomplete , and a compatible version is required by Servervice Registry Deployment Support. |
Application Server 9.1 IFR が Solaris マシンにインストールされた状態で、JES 5 UR1 からレジストリサーバーをインストールすることは不可能です。次の JES5 UR1 配布ディレクトリから、pkgadd コマンドを使用して、手動でレジストリサーバーパッケージをインストールする必要があります。
<path>/<OS>/Products/registry-svr/Packages |
(Internet Explorer 6 のみ) ロードバランサ設定ファイル (loadbalancer.xml) を Internet Explorer 6 からエクスポートしようとすると、sun-loadbalancer_1_2.dtd DTD ファイルが見つからないことを示すエラーメッセージがブラウザに表示されます。
設定ファイルを保存するには、次の回避方法を使用します。
Internet Explorer の「ロードバランサ」ページで、「エクスポート」をクリックします。
「XML page cannot be displayed」メッセージが表示されます。
エラーフレームをクリックしてから、Internet Explorer で「ファイル」->「名前を付けて保存」を選択します。
loadbalancer.xml ファイルを選択したディレクトリに保存します。
ここでは、インストール上の既知の問題とその解決方法を示します。
この問題は、いくつかの Linux システム上で発生していました。これは Java Desktop System 2 でもっとも一般的に見られますが、Linux Red Hat ディストリビューションでも見られます。
インストールプログラムの最後の画面で「完了」ボタンをクリックすると、インストールプログラムは製品の「バージョン情報」ページまたは製品登録ページを表示するブラウザウィンドウの起動に失敗し、コマンドプロンプトに戻ることなくハングアップします。
インストールプログラムを起動した端末ウィンドウで Ctrl+C を押すことにより、インストールプログラムを終了します。そのあとで、製品の「バージョン情報」ページまたは登録ページを表示するブラウザウィンドウが起動することがあります。ブラウザウィンドウが現れない場合には、ブラウザを起動してから次の URL を入力して「バージョン情報」ページを確認してください。
file://install_dir/docs-ee/about.html |
製品を登録するインストールオプションを選択した場合には、「バージョン情報」ページ上の登録ページへのリンクをたどってください。
Windows では、Application Server Enterprise Edition をインストールした直後に、ディレクトリ drive:\as\domains\domain1\imq が存在しない旨のメッセージを出力して Message Queue ブローカが起動に失敗します。
domain1 を起動してからブローカを起動した場合には、Application Server によってディレクトリが作成され、この問題は発生しません。
ブローカを作成する前に var_home_dir_location を作成します。次のようにします。
$imqbrokerd -varhome var_home_dir_location |
例として以下があります。
$imqbrokerd -varhome D:\as\domains\domain1\imq |
Windows Vista で付属の SDK をインストール中に、エラー「Unsupported Installation Platform Detected.」が発生することがあります。しかし、インストールは何の問題もなく成功します。
これは実際には問題ではありません。Application Server は Windows Vista 上で実行するので、この誤ったメッセージは将来のバージョンで削除されます。
Application Server productregistry ファイルに共用コンポーネント設定が含まれている場合、Application Server のアンインストール処理で productregistry ファイルが正しく更新されないため、productregistry ファイルを名前変更または削除しないなら、それ以降のインストールでサイレントモードを使用できなくなります。productregistry ファイル内の共用コンポーネントエントリを変更せずに残しておくことは意図的ですが、そのためにそれ以後のインストールで混乱が生じます。
アンインストールが正常に完了したことがアンインストールログファイルによって報告されたあとに、続けてインストールを実行する前に productregistry ファイルを削除します。以前のアンインストールが正常に完了したことを確認するには、<install_dir>に appserv_uninstall.class ファイルがあるかどうかを調べます。アンインストールが正常に完了した場合には、このファイルはありません。
インストールが正常に完了していない場合は、productregistry ファイルを削除しないでください。
productregistry ファイルは、Solaris では /var/sadm/install に、Linux では /var/tmp にあります。
疎ローカルゾーンに Application Server をインストールする場合、Message Queue (MQ) が先にインストールされていないとインストールが失敗します。インストーラは MQ をインストールしようとしますが、インストール全体が失敗します。
Application Server を疎ローカルゾーンにインストールする前に、MQ をグローバルゾーンに手動でインストールする必要があります。この問題には 2 つの回避方法があります。
最新の MQ パッケージを入手するために、Application Server 9.1 IFR インストールが収録されている同一のメディアから、MQ 4.1 を手動でグローバルゾーンにインストールします。
ご使用のプラットフォームに対応するインストーラを使用してください。
mq4_1-installer-SunOS.zip mq4_1-installer-SunOS_X86.zip mq4_1-installer-Linux_X86.zip mq4_1-installer-WINNT.zip |
圧縮ファイルを解凍して、インストーラを実行します。
インストーラは mq4_1-installer ディレクトリにあります。
IFR インストールのすべてのコンポーネントをグローバルゾーンにインストールします。この処理で、GZ の MQ のバージョンをチェックし、必要に応じて Application Server 9.1 IFR に付属のバージョンにアップグレードします。サンプルアプリケーションコンポーネントを選択してインストールするだけでも、MQ は IFR バージョンにアップグレードされます。
グローバルゾーンで Application Server インストールを実行しますが、サンプルコンポーネントのみを選択します。
サンプルコンポーネントインストールでは、MQ と Application Server 共用コンポーネントもすべてのゾーンにインストールされます。
Application Server インストールを再度実行しますが、今回は疎ローカルゾーンで実行します。
何の問題もなくインストールが完了するはずです。
Application Server 9.1 IFR インストーラで —console オプションを選択して実行すると (コマンド行モード)、次のプロンプトが表示されます。
Do you want to upgrade from previous Application Server version? |
残念ながら、IFR インストーラではこのようなアップグレードをサポートしていないため、このプロンプトは誤りです。プロンプトに「yes」と応答すると、インストールは正常に続行しますが、アップグレードされないばかりか、インストールが完全に実行されたことが表示されません。
Application Server インストールのアップグレードを希望する場合は、アップグレードツールを使用してください。
Sun Java System Application Server 9.1 で J2EE 1.4 Tutorial を実行するには、次の作業を実行します。
「About this Tutorial」の章の「About the Examples」で説明されているファイル例 /common/build.properties を編集する場合には、ポート 4848 を 4849 に変更します。
Application Server 9.1 のデフォルト管理ポートは再び 4848 になっています。詳細は、「AS のメジャーリリースのたびに、デフォルトポートが変わっている (6566481)」を参照してください。
deploytool を使用する場合、例を配備する前にサーバー localhost:4849 を追加します。
管理コンソールを使用して何らかのリソースを作成する場合には、「ターゲット」タブを使用してサーバーをターゲットとして指定します。コマンド行または asant ターゲットを使用する場合、サーバーがデフォルトのターゲットになるため、特別な処置は必要ありません。
『The Java EE 5 Tutorial』の第 32 章「Java EE Examples Using the JMS API」に『The Java EE 5 Tutorial』の「An Application Example That Consumes Messages from a Remote Server」という節がありますが、この例は有効ではなくなっています。MDB はメッセージの受信に失敗します。2 つのシステムの間でメッセージを送信する他の 2 つの例 (『The Java EE 5 Tutorial』の「Running JMS Client Programs on Multiple Systems」および『The Java EE 5 Tutorial』の「An Application Example That Deploys a Message-Driven Bean on Two Servers」) は引き続き正しく動作します。
今後の Application Server ビルドで修正されます。
Object[] から Collection への変換に java.util.Arrays.asList() API を使用している場合、JDK はクローン可能ではない java.util.ArrayList の実装を返します。結果として次の例外が発生します。
The method invocation of the method [protected native java.lang.Object java.lang.Object.clone() throws java.lang.CloneNotSupportedException] on the object [[pkg.A id = xxx]], of class [class java.util.Arrays$ ArrayList], triggered an exception. Internal Exception: java.lang.reflect.InvocationTargetException Target Invocation Exception: java.lang.CloneNotSupportedException: java.util.Arrays$ArrayList |
この問題は https://glassfish.dev.java.net/issues/show_bug.cgi?id=556 で追跡されています。
別のコレクションをそのコンストラクタを使用して作成します。一例として、次のようにします。
myCollection = new ArrayList(java.util.Arrays.asList(a)) |
ここでは、ライフサイクル管理に関する既知の問題とその解決方法を示します。
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 |
これらデフォルト以外の値を指定するとエラーが発生します。
default-config を使用して JMS 物理送信先を表示しようとすると、エラーメッセージが表示されます。
これは予想どおりの動作です。Application Server 9.1 では、default-config は設定情報のテンプレートであるため、JMS 操作 (list や create など) を default-config に対して実行できません。しかし、これらの JMS 操作をクラスタまたはスタンドアロンインスタンスの設定に対して実行することは可能です。
(Windows 2003 のみ) Windows 2003 では、リッチアクセス機能実行時にメモリーリークが発生します。Win32 ページング不可能プールが増大し続け、ついには TCP/IP スタック全体が停止してしまうために起きる問題です。一度この障害が発生すると、TCP/IP スタックは回復可能状態のままになり、TCP/IP スタックを復元するには Windows 2003 システムをリブートするしかありません。
これは Microsoft の問題 (サポート案件番号: SRX070906600011) で、修正プログラムが利用可能です。詳細は、Microsoft サポートに連絡してください。
この問題にも、上記の修正プログラムに加えて、2 つの回避方法があります。
domain.xml http-listener 属性 blocking-enabled="true" を設定して Grizzly ブロックモードを使用するか、または次の http-listener プロパティーを追加します。
<property name="blocking" value="true"/> |
Windows Vista または Windows XP を使用します。
この節では、ログに関する既知の問題とその解決方法を示します。
JVM の java.security.debug オプションを設定すると、サーバーインスタンスの起動がデッドロックで動かなくなります。たとえば、domain.xml で次の設定を行うと、この問題が発生します。
<jvm-options>-Djava.security.debug=access,failure</jvm-options> |
現時点ではありません。このフラグは設定しないでください。
ここでは、Java メッセージキューに関する既知の問題とその解決方法を示します。
タイミングに依存する場面での再接続の失敗は、さまざまな問題によって引き起こされます。
これらの問題は、次の方法で回避できます。
関連するブローカを再起動する
関連する Application Server インスタンスを再起動する
ドメインを作成しクラスタプロファイルを Linux システム上に配置すると、java.lang.OutOfMemoryError: Java heap space エラーが発生する場合があり、MQ ブローカが起動しないためにサーバーインスタンスが再起動できないことがあります。この状況になったシステムが回復することはありません。問題は /etc/hosts ファイルの設定ミスです。特に、サーバーホスト名がループバックアドレス 127.0.0.1 を指している場合です。
設計上、ネットワークデバイスがループバックアドレスを指すように設定された状態で MQ ブローカクラスタが開始することはできません。これはバグではありません。回避方法は、Application Server ホストの /etc/hosts ファイルが 127.0.0.1 を指さないようにすることです。
ここでは、監視上の既知の問題とその解決方法を示します。
HTTP サービスの一部の要素の監視統計を参照した場合、示される値のいくつかは現在の値に対応していないか、または常に 0 になっています。特に、次の HTTP サービス統計は Application Server に適用できる情報を表していないため、無視すべきです。
http-service
load1MinuteAverage
load5MinuteAverage
load15MinuteAverage
rateBytesTransmitted
rateBytesReceived
pwc-thread-pool (要素)
これらの監視情報は将来のリリースで削除され、より適切な情報で置き換えられる予定です。
管理 GUI から JNDI ブラウザを開くと、多くの例外がスローされます。
現時点ではありません。
ここでは、Application Server 9.1 製品に付属するサンプルコードに関する既知の問題とその解決方法を示します。
asadmin の配備手順にしたがって、MQ フェイルオーバーのサンプルアプリケーションを実行する前に、JMS リソースを作成する必要があることが、マニュアルに明記されていない。
次のエラーがスローされます。
/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 リソースが作成されます。
Linux で install_dir/samples/webservices/security のサンプル (basicSSl) を配備するときに、証明書が作成されず、次のようなエラーがスローされます。
generate_certs: [echo] ***Exporting certificate from NSS database [exec] Result: 1 [echo] ***Generating Java Keystore from generated certificate [exec] keytool error: java.lang.Exception: Input not an X.509 certificate [exec] Result: 1 [echo] ***Generating Java trust store from generated certificate [exec] keytool error: java.lang. Exception: Input not an X.509 certificate [exec] Result: 1 . . . generate_certs: [echo] ***Exporting server certificate from NSS database to a PKCS12 certificate file [exec] /opt/sun/appserver/lib/pk12util: /usr/lib/ libnss3.so: version `NSS_3.9' not found (required by /opt/sun/appserver/lib/ pk12util) [exec] /opt/sun/appserver/lib/pk12util: /usr/lib/libnss3.so: version `NSS_3.6' not found (required by /opt/sun/appserver/lib/pk12util) [exec] /opt/sun/appserver/lib/pk12util: /usr/lib/libnss3.so: version `NSS_3.7' not found (required by /opt/sun/appserver/lib/pk12util) [exec] Result: 1 |
問題は、Linux での NSS ライブラリの場所が Solaris での場所と異なることにあります。Linux 上に配備する場合、LD_LIBRARY_PATH が適切な NSS ライブラリを指していることを確認する必要があります。LD_LIBRARY_PATH を環境に設定するか、install_dir/bin/asant シェルラッパースクリプトに設定します。
次のいずれかを実行します。
LD_LIBRARY_PATH=/opt/sun/private/lib を設定します。
次の行を install_dir/bin/asant スクリプトに追加します。
LD_LIBRARY_PATH=$AS_NSS:$LD_LIBRARY_PATH;export LD_LIBRARY_PATH |
Windows で、Application Server 9.1 にアップグレード後に、そのサンプルと JES5 ポータルサンプルが Derby ポート 1527 で競合します。特に、Application Server 9.1 は 0.0.0.0:1527 (APP:APP 設定) で自動的に JavaDB を起動しますが、JES5 ポータル JavaDB は hostnameIP:1527 ( portal:portal 設定) へのバインドを希望します。
このバグは JES 5 ですでに示されている問題 (バグ 6472173) を記述しています。バグ 6472173 の回避方法については、『Sun Java Enterprise System 5 Installation Guide for Microsoft Windows 』で説明されています。
次のコマンドを使用して Derby データベースを開始します。
<JES installation dir>\appserver\bin\asadmin start-database --dbhome <JES installation dir>\portal\data\derby |
ここでは、Application Server と Web アプリケーションのセキュリティーおよび証明書に関する既知の問題とその解決方法を示します。
SSL 終了が機能しません。ロードバランサ (ハードウェア) を SSL 終了用に設定すると、リダイレクト中に Application Server がプロトコルを https から http に変更します。
ハードウェアロードバランサと Application Server の間にソフトウェアロードバランサを追加します。
JVM バグのため、HTTP リスナで security-enabled を true に設定すると、一部の JDK バージョンでリークの問題が起きます。具体的には、このバグを再現する手順は次のようになります。
HTTP リスナで security-enabled を true に設定します。
<http-listener acceptor-threads="1" address="0.0.0.0" blocking-enabled="false" default-virtual-server= "server" enabled="true" family="inet" id=" http-listener-1" port="8080" security-enabled="true" server-name= "" xpowered-by="true"> |
クイックルックテストの末尾にあるドメイン停止をコメントにします。
クイックルックテストを実行します。
ソケット使用状況を確認します。
netstat -an | grep 8080 |
使用状況が次のように表示されます。
*.8080 *.* 0 0 49152 0 LISTEN *.8080 *.* 0 0 49152 0 BOUND |
この問題は Glassfish サイトの https://glassfish.dev.java.net/issues/show_bug.cgi?id=849 で追跡されています。
最新の JDK バージョンにアップグレードします。
この節では、アップグレードユーティリティーに関する既知の問題とその解決方法を示します。
Enterprise Edition 8 から Application Server Enterprise Edition 8.1 にアップグレードするときに、install_dir/domains ディレクトリ以外のカスタムパスに作成されたドメインが直接アップグレードされない。
アップグレードユーティリティーを実行しているときに、install_dir をソースインストールディレクトリとして指定すると、そのアップグレードプロセスは、install_dir/domains ディレクトリの下に作成されたドメインだけをアップグレードします。その他の場所に作成されたドメインはアップグレードされません。
アップグレードプロセスを起動する前に、すべてのドメインディレクトリを、それぞれの場所から install_dir/domains ディレクトリに移動します。
この問題はさまざまな Linux システムで発生しています。Java Desktop System 2 でもっとも一般的ですが、Red Hat ディストリビューションでも発生しています。
インストールプログラムの最後の画面で「アップグレードツールの起動」ボタンをクリックすると、そのインストールプログラムはアップグレード処理を完了するためのアップグレードツールの起動に失敗し、コマンドプロンプトに戻ることなくハングアップします。
この問題は、コマンド行インストールモードを使用して代替アップグレードを実行している場合には発生しません。
GUI モードで代替アップグレードを実行してこの問題が発生した場合には、インストールプログラムを起動した端末ウィンドウで Ctrl+C を押すことにより、そのインストールプログラムを終了します。
その端末ウィンドウから次のコマンドを使用してアップグレードツールを起動します。
install_dir/bin/asupgrade --source install_dir/domains --target install_dir --adminuser adminuser --adminpassword adminpassword --masterpassword changeit |
adminuser および adminpassword は、アップグレード中のインストールで使用されている値に一致する必要があります。
アップグレードツールがアップグレードプロセスを完了したあとは、ブラウザを起動して次の URL を入力することにより、「バージョン情報」ページを参照できます。
file://install_dir/docs-ee/about.html |
製品を登録するインストールオプションを選択した場合には、「バージョン情報」ページ上の登録ページへのリンクをたどってください。
アップグレード後、ターゲットの domain.xml から次のエントリを削除し、サーバーを再起動します。
<jvm-options>-Djavax.net.ssl.keyStore=${com.sun.aas.instanceRoot} /config/keystore.jks</jvm-options>- <jvm-options>Djavax.net.ssl.trustStore=${com.sun.aas.instanceRoot} /config/cacerts.jks</jvm-options>
アップグレードツールは、どのサーバーインスタンスのどの既存の index.html ファイルでも上書きします。
アップグレードツールを実行する前に既存の index.html ファイルのバックアップを取ってから、後でそれらのファイルを復元します。
Application Server 8.0PE から 9.1 へのアップグレード時に、サーバーに null という名前のシステムコネクタがないというエラーがスローされ、sbs-manual に示されているような無効なユーザー情報が表示されます。ハードコードされた値を変更しても、同じエラーメッセージが表示されます。この問題が起きるのは、8.0 と 9.1 で domain.xml が変更されているためです。
8.0 PE から 9.1 にアップグレードした場合にのみ、このバグに遭遇します。回避方法は、8.1、8.2、または 9.0 に一度アップグレードしてから、さらに 9.1 にアップグレードすることです。
インプレースアップグレード実行時に、ソースに複数のドメインがある場合、プロセスが中止になっても、インストーラはアップグレードツールを呼び出します。GUI モードで呼び出した場合にそうなります。
インプレースを CLI モードでインストールし、インストール処理の最後にインストーラがアップグレードツールを選択するプロンプトを表示したときに終了します。この操作を行っても、ドメインディレクトリにあるどのドメインも削除されません。アップグレードツールは bin ディレクトリから手動で呼び出す必要があります。
GUI モードでインプレースをインストールする場合は、処理中にドメインが失われることがないようにするために、ドメインルートにあるドメインのバックアップを取ります。インストール処理の最後に、インストーラがアップグレードツールを選択するプロンプトを表示したときに終了します。失われているドメインがあれば、ドメインバックアップしたドメインをドメインディレクトリにコピーします。アップグレードツールを起動して、手動でアップグレードを実行します。
AS8.2 から 9.1 へのアップグレード時に、8.2 インストール環境のマスタパスワードが 9.1 インストール環境に継承されない。これが原因となって、次の管理者ログイン時に認証エラーとなります。
Application Server 9.1 のデフォルト管理パスワードは changeit です。8.2 からのアップグレード後に 9.1 サーバーにログインするときの問題を回避するために、次の 3 つのどれか 1 つを行ってください。
アップグレードを実行する前に、8.2 管理者パスワードを changeit に変更する。
アップグレード処理時にデフォルトの管理者パスワードを受け入れず、使用するパスワードを明示的に入力する。
デフォルトパスワードで 9.1 にログインし、そのあと直ちにパスワードを変更する。
アップグレードツールはどのような形式のデータベースまたはテータベーステーブルのアップグレードを扱っておらず、将来サポートする予定もありません。リソース参照設定は転送されているので、Application Server が元のデータベースおよびテーブルを引き続き処理できるようにする必要があります。データベースを変更するか、またはデータベーステーブルを転送する場合、使用中のデータベースを処理するツールを使用します。
次のステップを行って、MQ ストアを移行します。
AS 8.2 をシャットダウンして、AS9.1 アップグレードツールを実行したあと、AS9.1 をはじめて起動する前に次のステップを行います。IFR インストール/アップグレード後にすでに AS9.1 を開始している場合は、MQ メッセージストアが不安定になる可能性があるので、次のステップを行わないでください。
domains/domain1/imq サブディレクトリ全体を AS 8.x domains ディレクトリから AS 9.1 domains ディレクトリにコピーします。
ディレクトリとファイルの所有者が Application Server を実行するユーザーと同じであることを確認してください。
上記のステップを実行したあと、Application Server 9.1 を開始することができ、MQ は Application Server 9.1 に格納します。domains ディレクトリ内の MQ ストアは JES5 U1 形式から MQ 4.1 形式に移行されます。この手順では、またはAS 9.1 による起動時に MQ4.1 によっては、AS 8.2 の下にある元の JES5 U1 MQ ストアは保存され変更されないことに注意してください。
JES5 (Application Server 8.2) から Application Server 9.1 にアップグレードすると、Portal Server コミュニティーサンプルは機能しなくなり、多数の javax.faces.application.ApplicationFactory エラーをスローします。
Application Server 8.2 が JES5 Portal Server とともにインストールされている場合、Application Server 8.2 から 9.1 へのアップグレードはサポートされていません。Application Server を 9.1 にアップグレードする前に、Portal Server を Java ES 5 Update 1 にアップグレードする必要があります。
Linux プラットフォーム上で IFR インストーラを使用し「JDK をインストール」オプションを選択して Application Server 8.2 から 9.1 にアップグレードすると、インストールは正常に完了しても、ほとんどの JES コンポーネントが動作を停止します。
この問題は、Linux プラットフォームでの Application Server 9.1 の IFR インストールにのみ、また「JDK をインストール 」オプションを選択した場合にのみ影響が出ます。この問題を回避するには、インストール直後に、/usr/jdk/entsys-j2se を /usr/java/jdk1.5.0_12 ディレクトリに手動でリンクします。
Windows 上で Application Server 9.1 IFR アップグレードを実行すると、インプレースバックアップは asupdate.bat フォーム値と正しく統合されません。具体的には、ASupdate.bat GUI 画面に間違った情報を入力してから「次へ」をクリックすると、アップグレードインストーラはインプレースアップグレードなのかどうかを検出しようとします。インプレースアップグレードである場合には、アップグレードの前に domain1 がバックアップディレクトリに移動されます。アップグレードが進行すると、間違った情報の結果としてエラーメッセージが表示されます。直ちにエラーを訂正しようとすると、domain1 がすでに移動しているので、パスエラーがスローされます。
ソースディレクトリを {current source path}/backup の domain1_ {timestamp} ディレクトリに変更するか、または「取消し」ボタンでインストーラを終了して再起動します。
(Windows のみ) 以前のバージョンの Application Server が特殊文字または DOS 形式のショートネームを使用してプログラムディレクトリパスにインストールされている場合、同じディレクトリパス名を使用すると、Application Server 9.1 へのインプレースアップグレードが失敗します。
たとえば、Application Server 8.2 が次のディレクトリのどちらかにインストールされているとします。
C:\Program Files (x86)\dirs\appserver c:\progra~2\dirs\appserver |
9.1 へのインプレースアップグレードを実行しようとすると、インストーラがショートネームまたは特殊文字を必須のロングネーム形式に変換できないために失敗します。
特殊文字や DOS 形式のショートネーム短縮形 (progra~2 など) は、以後のアップグレードインストールの妨げになるため、使用しないことが強く勧められています。このようなインストール環境が存在する場合、アップグレードする前に長いパス名を使用してそれを削除するか、または全く新しいディレクトリに新規バージョンの Application Server をインストールします。
Application Server アップグレード後に、<jsp:forward> タグが Authenticate.jsp で予期されているように機能しません。<jsp:forward> を呼び出すとサーバーログにエラーが生成され、Web UI に空白ページが表示されます。問題は、 Authenticate.jsp 内の <jsp:forward> に <jsp:forward page="${redirectPage}"/> のようなページ属性が必要なのに、渡される値が /registry/thin/{pagename}.jsp のような相対パスであるためで、この場合は Authenticate.jsp が純粋な JSP ページであっても機能しません。
Application Server アップグレードを完了したあと、asadmin ツールを使用して次のコマンドを実行し、 domain.xml に <auth-realm> を設定します。
<appserver9.1-install-dir>/bin に移動して、次のコマンドを実行します。
./asadmin delete-auth-realm --host localhost --port 6489 certificate |
これにより、古い auth-realm 証明書があれば削除されます。
次のコマンドを実行します。
./asadmin create-auth-realm --terse=false --echo=true --interactive=true \ --user admin --host localhost --port 6489 --classname \ com.sun.enterprise.security.auth.realm.certificate.CertificateRealm \ --property assign-groups=have.client.cert certificate |
これにより、新規の <auth-realm> が assign-groups プロパティーを指定して作成されます。
Application Server registry ドメインを停止して再起動します。
英語以外の言語で asupgrade GUI を実行すると、この GUI のオンラインヘルプが選択した英語以外の言語にローカライズされていません。
現時点ではありません。オンラインヘルプは英語以外のすべての目標言語にローカライズされる予定です。
ここでは、Web コンテナに関する既知の問題とその解決方法を示します。
Windows にアプリケーションを配備するときに JSP のプリコンパイルを要求すると、それ以降、そのアプリケーションの配備取り消しや、そのアプリケーション (または同一モジュール ID を持つ任意のアプリケーション) の再配備を試みても、予期したとおりに動作しません。この問題は、JSP のプリコンパイル処理でアプリケーションの JAR ファイルが開かれたまま閉じられないため、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(Default CompilerAdapter.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 9.1 では、Sun Java System Application Server Enterprise Edition 7.1 で使用できる auth-passthrough プラグイン機能が提供する機能に対するサポートが追加されています。ただし、ProductName; 9.1 での 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 9.1 では、domain.xml 内の <http-service> 要素の authPassthroughEnabled プロパティーを TRUE に設定することにより、auth-passthrough 機能を有効にすることができます。次に例を示します。
<property name="authPassthroughEnabled" value="true"/> |
Application Server Enterprise Edition 7.1 にある auth-passthrough プラグイン関数のセキュリティーに関する同じ注意点が、Application Server 9.1 にある authPassthroughEnabled プロパティーにも適用されます。authPassthroughEnabled によって、認証目的に使用される可能性のある情報 (要求発信元の IP アドレスや SSL クライアント証明書など) を上書きすることが可能になるため、authPassthroughEnabled を TRUE に設定して Application Server 9.1 インスタンスへの接続を許可する場合は、その対象を信頼できるクライアントまたはサーバーだけに限定することがきわめて重要です。予防措置として、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 証明書を、それを要求している任意の配備されたアプリケーションに提供します。
この問題は、Linux システムで Sun Java System Web Server を Application Server 9.1 およびロードバランサとともに使用している場合にのみ起きます。このような場合、Application Server とロードバランサのインストール後に、libicui18n.so.2 と libicuuc.so.2 が競合するため Web Server が起動に失敗することがあります。これらのライブラリは /opt/sun/private/lib と /opt/sun/appserver/lib の両方にあります。
使用すべき正しいライブラリは /opt/sun/appserver/lib にあるライブラリです。このライブラリに対して lbplugin が構築されているからです。/opt/sun/private/lib からこの 2 つのライブラリを削除すると、Web Server はエラーを出さずに起動します。
または、/opt/sun/private/lib からライブラリを削除したくない場合は、Web Server startserv スクリプトの LD_LIBRARY_PATH で /opt/sun/private/lib の前に /opt/sun/appserver/lib を配置することもできます。つまり、
# Add instance-specific information to LD_LIBRARY_PATH for Solaris and Linux LD_LIBRARY_PATH="${SERVER_LIB _PATH}:${SERVER_JVM_LIBPATH}:${LD_LIBRARY_PATH}: /opt/sun/appserver/lib:/opt/sun/appserver/lbplugin/lib"; export LD_LIBRARY_PATH |
これを、次の項目で置き換えます。
# Add instance-specific information to LD_LIBRARY_PATH for Solaris and Linux LD_LIBRARY_PATH="/opt/sun/ appserver/lib:/opt/sun/appserver/lbplugin/lib: ${SERVER_LIB_PATH}:${SERVER_JVM_LIBPATH}:${LD_LIBRARY_PATH} "; export LD_LIBRARY_PATH |
ここでは、Web コンテナに関する既知の問題とその解決方法を示します。
Java EE SDK b33d に組み込まれている JDK 1.6 で JAX—WS テストを実行中に問題に遭遇します。テストは次のメッセージを出して直ちに異常終了します。
[wsimport] Exception in thread "main" java.lang.NoClassDefFoundError: \ com/sun/tools/ws/WsImport |
webservices-tools.jar に com/sun/tools/ws/WsImport.class、com/sun/tools/ws/ant/WsImport.class、および com/sun/tools/ws/ant/WsImport2.class が含まれていても、このエラーは起きます。さらに、1.5.0-10 JDK を使用すると、同じテスト作業空間が問題なく機能します。
JAX-WS テストを実行する前に、webservices-api.jar を $JAVA_HOME/jre/lib/endorsed にコピーします。
JAXR は SAAJ を使用して SOAP メッセージをレジストリに送信します。IFR 以外では、SAAJ impl クラスは lib/webservices-rt.jar の下にあります。IFR の場合、SAAJ クラスは引き続き lib/webservices-rt.jar の下にあります。また、saaj-impl.jar は /usr/share/lib ディレクトリにあります。この jar ファイルは Application Server で格上げされ、webservices-rt.jar のクラスよりも優先されています。この jar ファイルには、SOAP メッセージを Web サービスレジストリに送信するために必要なセキュリティー権限がありません。/usr/share/lib ディレクトリの下の jar に権限を付与するか、または /usr/share/lib の jar に依存しないように、パッケージを変更する必要があります。
server.policy ファイルに次の内容を追加します。
grant codeBase "file:/usr/share/lib/saaj-impl.jar" { permission java.security.AllPermission; }; |