Sun Java System Application Server Enterprise Edition 8.2 リリースノート (Windows 版)

第 3 章 既知の問題点と制限事項

この章では、Sun Java System Application Server Enterprise Edition 8.2 ソフトウェアに関する既知の問題とそれに関連する回避策について説明します。問題の説明にプラットフォームが明記されていない場合、その問題はすべてのプラットフォームに当てはまります。この節は次の項目から構成されています。

管理

ここでは、管理上の既知の問題とその解決方法を示します。

Application Server の「インストール時に自動的に設定」オプションでロードバランサ機能がサポートされていない (6463858)

Application Server の「インストール時に自動的に設定」オプションでは、ロードバランサ機能はサポートされていません。

対処方法:ロードバランサ機能は Application Server のインストール後に設定できます。


注 –

ロードバランサ機能を設定するには、Application Server と Web Server をシステムにインストールしておく必要があります。


    ロードバランサ機能を設定するには、次の手順を実行します。

  1. レジストリ HKEY_LOCAL_MACHINE -> Sun Microsystem -> EntSys -> Installer -> Application Server で、IS_LB の値を true 、Cfgr_LB の値を false に設定します。

  2. setup ディレクトリに移動します。

    cd JavaES-Install-Dir\setup\


    
    
  3. ASConfigure.bat バッチファイルを実行します。

  4. 指示に従って、適切な値を指定します。


    注 –

    AS_LB プラグインの場合、Sun Java System Web Server [必須] と入力します。これが Java ES 5 でサポートされている唯一のプラグインであるためです。


  5. システムをリブートします。

domain1 が存在しない場合、package-appclient スクリプトが動作しない (ID 6171458)

デフォルトでは、 asenv.conf によって参照される domain1AS_ACC_CONFIG 変数のハードコードされた値が JavaES-Install-Dir \lib\lib\package-appclient.xml にあります。 domain1 を削除して新たなドメインを作成した場合、AS_ACC_CONFIG 変数は新たなドメイン名で更新されません。その結果、package-appclient スクリプトの処理が失敗します。

解決方法

次のいずれかの操作を行います。

負荷分散プラグインをインストールすると、既存のプラグインが上書きされる (ID 6172977)

7.1EE などからすでにロードバランサプラグインがインストールされている Application Server のインストールに対して負荷分散プラグインをインストールすると、プラグインを実行する新しいサーバーインスタンスを作成しても、メッセージの表示なしで既存のロードバランサが 8.2EE プラグインに置き換えられます。

プラグインファイルは、デフォルトで install_dir /plugins/lbplugin ディレクトリの下にインストールされるため、1 つの Application Server インストールで使用できるプラグインは 1 つのバージョンだけになります。コンソールインストーラはアンインストールが実行されていることを示すメッセージを表示しますが、このメッセージは見逃しやすいことに注意してください。

解決方法

だれもがこの問題を経験するわけではありません。この問題が発生した場合は、古い Application Server インストールを削除して、アップグレードインストールではなく新規インストールを実行してください。

Java ES 2 Application Server 7 と比べると、Java ES 3 Application Server 8.2 の asadmin スクリプトにいくつかの変更がある (ID 6189433、6189436)

Application Server 7 および互換バージョンと比較して、Application Server 8.2 では asadmin コマンドにいくつかの変更が加えられました。たとえば、Application Server 7 および互換バージョンでは、サーバーインスタンスを起動するコマンドは次のようになります。


asadmin start-instance

バージョン 8.2 では、次のコマンドを使用します。


asadmin start-domain --user admin domain1

最新の asadmin コマンド構文の詳細については、次のマニュアルを参照してください。

Application Server のデフォルトポートが変更される (ID 6198555)

Java ES 2 Application Server 7 および互換バージョンから Java ES 5 Application Server 8.2 にアップグレードする場合、デフォルトポートが変更されているために、非互換性に関する問題またはエラーが発生することがあります。

バックアップしたドメインを別の名前で復元できない (ID 6196993)

同一の Application Server インストール上では、backup-domain コマンドと restore-domain コマンドを使用してドメインをミラーリングできません。これは、asadmin restore-domain コマンドにドメイン名を変更するオプションがあるにもかかわらず、元の名前ではない別の名前でドメインを復元できないからです。バックアップされたドメインの名前を正常に変更したように見えても、名前を変更されたドメインの起動は失敗します。ドメイン設定のエントリは変更されておらず、startserv および stopserv は元のドメイン名を使用してパスを設定するからです。

解決方法

restore-domain で使用するドメイン名は、元の backup-domain コマンドで使用したドメイン名と同じである必要があります。Application Server 8.2 の backup-domain コマンドと restore-domain コマンドが動作するのは、同一マシンで同一ドメインをバックアップおよび復元する場合だけです。

JMX エージェントを追加した Application Server の起動はサポートされていない (ID 6200011)

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 を使用しても、ロードバランサの設定ファイルが作成されない (ID 6236544、6275436)

Web サービスの URL をエクスポートする EJB モジュールを含むアプリケーションを使用してロードバランサを設定しても、作成された loadbalancer.xml ファイルに、その Web サービスのコンテキストルートが存在しません。

解決方法

  1. loadbalancer.xml ファイルを編集して、作成されなかった Web モジュールを次のように追加します。


    <web-module context-root="context-root-name"
    disable-timeout-in-minutes="30" enabled="true"/>
  2. context-root-name 値を、EJB として公開された Web サービスのコンテキストルート名に置き換えます。

設定内の Java ホームの設定が反映されない (ID 6240672)

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 のバージョンの最低限の要件を確認してください。


sun-appserv-admin を使用して Application Server を再起動すると、LoginException エラーが発生する (ID 6288893)

この問題は %CONFIG_HOME% の間違った値によって発生します。

解決方法

  1. 既存の名前 asantasant.bak に変更します。

  2. as_install /lib/install/templates/ee にある SE/EE バージョンの asant.template ファイルを as_install /bin/ ディレクトリにコピーし、このファイルの名前を asant に変更します。

  3. 新しくコピーされた as_install/bin/asant ファイルを編集して、%CONFIG_HOME% トークンを as_install /config 値に置き換えます。

  4. 元の asant.bak ファイルに対して行なった手作業の変更がある場合は、それを新しい asant ファイルに結合します。

Application Server のマニュアルに .asadmintruststore ファイルが記述されていない (ID 6315957)

このファイルがサーバー管理者の home ディレクトリに存在しないと、そのサーバー上にホストされている特定のアプリケーションをアップグレードしたときに重大なバグが発生する場合があります。

解決方法

create-domain マスターパスワードに特殊文字が含まれる場合、ドメインの起動が失敗する (ID 6345947)

ドメインのマスターパスワードにパーセント文字 (%) が含まれるときにドメインが起動しません。

解決方法

ドメインのマスターパスワードにパーセント文字 (%) を含めないようにしてください。これは、新しいドメインを作成するとき、および既存のドメインのマスターパスワードを変更するときに適用されます。

magnus.conf および obj.conf でのロードバランサの設定変更が上書きされる (ID 6394181)

セキュリティー保護された http-listener を作成し、lbplugin をインストールしたあとで、webserver_instance_dir/config ディレクトリの下の magnus.conf および obj.conf ファイルが変更され、lbplugin の内容が削除されます。

インストーラは、ロードバランサプラグインのインストールの一部として、Application Server の magnus.conf および obj.conf 設定ファイルを変更します。Application Server 管理コンソールにログインし、ロードバランサがインストールされたインスタンスのインスタンス設定を管理しようとすると、Application Server は、設定の手動編集を検出したことを示す警告メッセージを表示します。この警告は、実際にはインストーラによって加えられた変更を示しています。

解決方法

インストーラによって加えられた変更が上書きされていないことを確認します。

アプリケーションクライアント

ここでは、アプリケーションクライアントに関する既知の問題とその解決方法を示します。

アプリケーションクライアントアーカイブのライブラリ JAR が MANIFEST ファイルを上書きする (ID 6193556)

クライアント JAR (この場合は reporter.jar) 内に最上位レベルの JAR ファイルがある場合、クライアント JAR を配備すると、その JAR の MANIFEST ファイルがクライアント JAR の MANIFEST ファイルを上書きします。

解決方法

ありません。

CGI-bin や SHTML 機能などの動的コンテンツ技術がサポートされていない (ID 6373043)

CGI-bin や SHTML などの動的コンテンツ技術はサポートされなくなりました。

解決方法

JSP および Web サービス技術を代わりに使用します。

付属の Sun JDBC ドライバ

ここでは、Sun の JDBC ドライバに関する既知の問題とその解決方法を示します。

TRANSACTION_SERIALIZABLE 遮断レベルを Microsoft SQL Server 向けの付属の Sun ドライバとともに使用するアプリケーションがハングアップする (ID 6165970)

この問題は、2 つの並行トランザクションが実行中で、そのうちの 1 つがロールバックされた場合、準備済みの更新文を使ったときに発生することがあります。

解決方法

接続の遮断レベルを設定するには、対応する接続プールを同じ遮断レベルで作成します。接続プールの設定の詳細については、『Sun Java System Application Server Enterprise Edition 8.2 管理ガイド』を参照してください。

PreparedStatement エラーが発生する (ID 6170432)

説明 1

1 つのトランザクションで 3000 を超える PreparedStatement オブジェクトを生成する場合、DB2 では次のエラーが発生する可能性があります。

[sunm][DB2 JDBC Driver] No more available statements. Please recreate your package with a larger dynamicSections value.

解決法 1

次のプロパティーを接続プール定義に追加して、ドライバが DB2 パッケージをより大きな動的セクション値に再バインドするようにします。

createDefaultPackage=true replacePackage=true dynamicSections=1000

接続プールの設定については、『Sun Java System Application Server Enterprise Edition 8.2 管理ガイド』を参照してください。

説明 2

PrepardStatement エラーに関連して、次のエラーメッセージがスローされることがあります。

[sunm][DB2 JDBC Driver][DB2]Virtual storage or database resource is not available.

解決法 2

DB2 サーバー設定パラメータ APPLHEAPSZ の値を増やします。たとえば、4096 を使用します。

説明 3

遮断レベル TRANSACTION_SERIALIZABLE。アプリケーションが遮断レベル TRANSACTION_SERIALIZABLE を採用し、前述したパラメータの 1 つを使用している場合、そのアプリケーションは接続を取得するときにハングアップすることがあります。

解決法 3

遮断レベルを接続に対して設定するには、対応する接続プールをその遮断レベルで作成する必要があります。手順については、『Sun Java System Application Server Enterprise Edition 8.2 管理ガイド』を参照してください。

コネクタ

この節では、J2EE のコネクタアーキテクチャーに関する既知の問題とその解決方法を示します。

DAS インスタンスを再起動したあと、cascade が false に設定されている場合にコネクタモジュールの配備取り消しが失敗する (ID 6188343)

このシナリオでは、スタンドアロンまたは埋め込みのコネクタモジュールが 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 に設定) します。

JMS create-jms-resource: CLI によってデフォルト値が正しく設定されない (ID 6294018)

コマンド行から asadmin create-jms-resource コマンドで新しい JMS リソースを作成するときは最小プールサイズと最大プールサイズを指定できないため、asadmin コマンドがデフォルトのプールサイズ値 (最小が 8、最大が 32) を使用してリソースを作成すべきです。代わりに、コマンド行からリソースを作成すると、デフォルトの最小プールサイズと最大プールサイズがそれぞれ 1250 になります。

解決方法

コマンド行から JMS リソースを作成したあとで、管理コンソールを使用して最小プールサイズ値と最大プールサイズ値を変更します。

関連文書

ここでは、マニュアル上の既知の問題とその解決方法を示します。

Javadoc に不整合がある

いくつかの AMX インタフェースおよびメソッドについて、Javadoc が欠けているか間違っています。

付属の ANT によって java.lang.NoClassDefFoundError 例外がスローされる (ID 6265624)

スレッド「main」で java.lang.NoClassDefFoundError: org/apache/tools/ant/launch/Launcher の例外がスローされます。

解決方法

付属の ANT を Application Server 外部のタスクの実行に使用することはお勧めできません。

ログオプションのマニュアルに誤りがある (ID 6463965)

『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 (オプション 1stdout (System.out.print) コンテンツをイベントログに記録する)

  • Option 2 – Log stderr ( System.err.print) content to the event log (オプション 2stderr (System.err.print) コンテンツをイベントログに記録する)

これらのログオプションは、Application Server Enterprise Edition 8.2 では存在しなくなりました。

Application Server 8.2 の HTTP ファイルキャッシュ機能に関して相反する情報がある (ID 6474799)

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 がチェックしない (ID 5091280)

hadbm set を使用してデバイスまたはバッファーのサイズを増やす場合、管理システムは、データベースを作成したり、ノードを追加したりする際にはリソースが利用可能かどうかをチェックします。 しかし、デバイスまたはメインメモリーのバッファーサイズを変更するときには利用可能なリソースが十分にあるかどうかをチェックしません。

解決方法

設定属性 devicesize または buffersize を増やす前に、すべてのホスト上にディスクおよびメモリーの空きスペースが十分にあることを確認してください。

packagepath の混在パスがサポートされない (ID 5091349)

同一のソフトウェアパッケージを、異なるホストの別の場所に同じ名前で登録することはできません。次に例を示します。


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 が失敗することがある (ID 6173886、6253132)

複数のネットワークインタフェースを備えたホスト上で管理エージェントを実行している場合に、すべてのネットワークインタフェースが同じサブネット上に存在しないと、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.interfacesma.server.mainternal.interfaces=10.11.100.0 に設定します)。あるいは、サブネット間のルーターを、マルチキャストパケットをルーティングするように設定することもできます。このとき、管理エージェントはマルチキャストアドレス 228.8.8.8 を使用します。

管理エージェントの新しい設定を再試行する前に、管理エージェントリポジトリのクリーンアップが必要になる場合があります。ドメイン内のすべてのエージェントを停止し、リポジトリディレクトリ (管理エージェント設定ファイル内の repository.dr.path で識別される) 内のすべてのファイルとディレクトリを削除します。このクリーンアップは、新しい設定ファイルを使用してエージェントを再起動する前に、すべてのホスト上で実行する必要があります。

HADB インスタンスの削除後にディレクトリをクリーンアップする必要がある (ID 6190878)

HADB インスタンスの削除に続いて configure-ha-cluster コマンドで新しいインスタンスを作成しようとすると、失敗します。問題は、元の HADB インスタンスの古いディレクトリが ha_install_dir/rep/* ha_install_dir/config/hadb/instance_name に残ることにあります。

解決方法

HADB インスタンスの削除後に、手動でこれらのディレクトリを削除するようにしてください。

clu_trans_srv を中断できない (ID 6249685)

Red Hat Enterprise Linux 3.0 の 64 ビットバージョンには、非同期入出力の実行中に clu_trans_srv プロセスを中断不可能なモードに陥らせるバグが存在します。つまり、kill -9 コマンドが機能せず、オペレーティングシステムの再起動が必要になります。

解決方法

Red Hat Enterprise Linux 3.0 の 32 ビットバージョンを使用します。

hadbm が大文字を含むパスワードをサポートしていない (ID 6262824)

パスワードが hadb に格納されるときに、パスワード内の大文字は小文字に変換されます。

解決方法

大文字を含むパスワードは使用しないでください。

セッションオブジェクトがタイムアウトし、管理エージェントで削除されたとき、hadbm/ma は不正なエラーメッセージを出力する (ID 6275103)

場合によっては、サーバー上のリソース競合の問題によって管理クライアントが切断されることがあります。再接続時、「hadbm:Error 22184:A password is required to connect to the management agent」という紛らわしいエラーメッセージが返されることがあります。

解決方法

サーバー上にリソースに関する問題があるかどうかを確認し、適切な処置 (たとえば、リソースの追加) を取ってから、操作を再試行します。

管理エージェントは特殊用途のインタフェースを使用するべきではない (ID 6293912)

0.0.0.0 のような IP アドレスを含む特殊用途のインタフェースを、管理エージェント内の HADB ノードが使用する有効なインタフェースとして登録するべきではありません。このようなインタフェースを登録すると、IP アドレスの代わりにホスト名を使用して hadbm create コマンドを発行するユーザーによってこのインタフェース上に HADB ノードが設定された場合に、問題が発生する場合があります。その場合、これらのノードは通信できなくなり、create コマンドはハングアップします。

解決方法

複数のインタフェースを備えたホスト上で hadbm create を使用する場合は、DDN 形式を使用して IP アドレスを常に明示的に指定します。

Windows 上で再構築が失敗する (ID 6291562)

Windows プラットフォームでは、特定の設定および負荷の下で、オペレーティングシステム内で多数の再構築の失敗が発生する場合があります。この問題は、20 を超えるノードが設定されている状況で、複数のテーブルスキャン (select *) を並列に実行している場合に発生しています。症状としては、トランザクションが頻繁に中断し、修復またはリカバリの完了に長い時間がかかるため、システムのさまざまな場所で頻繁にタイムアウトが発生していることが考えられます。

解決方法

この問題を修正するには、Windows レジストリ変数 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters をデフォルトの 100 より大きい値に設定します。この値を 0x1000 ( 4096) に増やすことをお勧めします。詳細は、Microsoft サポートページの記事 811003 を参照してください。

hadbm start db_name を実行すると、入力したパスワードの一部がマスクされずに表示される (ID 6303581、6346059、6307497)

マシンに負荷がかかっていると、マスク機構が機能せず、入力したパスワードの一部が表示されることがあります。パスワードが表示されることにより、軽度のセキュリティーリスクが生じます。パスワードは常にマスクされる必要があります。

解決方法

パスワードを独自のパスワードファイルに入れて (Application Server 8.1 以降推奨されている方法)、--adminpassword または --dbpasswordfile オプションでこれらのファイルを参照します。

インストール

ここでは、インストール上の既知の問題とその解決方法を示します。

Java Enterprise System 5 インストーラによる Application Server 8.x ロードバランサの最小インストールが適切でない (ID 6478047)

Apache および IIS は Java ES 5 インストーラでは設定できません。Apache および IIS は Windows プラットフォーム上で手動で設定する必要があります。

解決方法

ロードバランサ Apache または IIS を設定するには、次の手順を実行します。

     Apache 2.x を設定するには

  1. Apache 2.x をインストールします。

    Apache は APDIR=C:\Apache2\Apache2 ディレクトリにインストールされます。

  2. JES5 を最小インストールでインストールします。

    ロードバランサ以外のすべてのコンポーネントを選択解除します。Java ES 5 は JES5DIR=C:\Program Files\Sun\JavaES5 ディレクトリにインストールされます。

  3. Apache2 ディレクトリに resource および errorpages ディレクトリを作成します。

    mkdir %APDIR%\modules\resource

    mkdir %APDIR%\modules\errorpages

  4. リソースファイルを resource ディレクトリにコピーします。

    cd %APDIR%\modules\resource

    copy %JES5DIR%\appserver\lib\webserver-plugin\windows\apache2\LBPlugin*.res .

  5. ロードバランサ DLL を modules ディレクトリにコピーします。

    cd %APDIR%\modules

    copy %JES5DIR%\appserver\lib\webserver-plugin\windows\apache2\mod_loadbalancer.dll .

  6. テンプレート errorpageserrorpages ディレクトリにコピーします。

    cd %APDIR%\modules\errprpages

    copy %JES5DIR%appserver\lib\webserver-plugin\windows\iws\errorpages .

  7. ロードバランサテンプレートとその他の DTD を Apache config ディレクトリにコピーします。

    cd %APDIR%\config

    copy %JES5DIR%\appserver\lib\install\templates\loadbalancer.xml.template .

    copy %JES5DIR%\appserver\lib\dtds\sun-loadbalancer* .

  8. httpd.conf ファイルのバックアップを作成します。

    cd %APDIR%\config

    copy httpd.conf httpd.conf.orig

  9. 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
  10. C:\Apache2\Apache2 を実際の %APDIR% ディレクトリに置き換えます。

    IP、ServerName、および DocumentRoot ディレクトリも置き換えます。

  11. %APDIR% に新しい sec_db_files ディレクトリを作成します。

    cd %APDIR%

    mkdir sec_db_files

  12. NSS キーストアを %APDIR%\sec_db_files ディレクトリにコピーします。

    cd %APDIR%\sec_db_files

    copy %JES5DIR%\appserver\lib\webserver-plugin\windows\iis\*.db .

  13. 必要なライブラリが含まれるように PATH を設定します。

    以下の追加パスを先頭に付加します。

    PATH %JES5DIR%\share\lib;%JES5DIR%\appserver\lib;%JES5DIR%\appserver\bin

  14. %JES5DIR% を実際の Java ES 5 ディレクトリに置き換えます。

  15. システム環境変数に、値 1 の NSPR_NATIVE_THREADS_ONLY 変数を追加します。

  16. リブートして Apache 2 をテストします (loadbalancer.xml の設定後)。

    IIS LBPlugin を設定するには

  1. c:\inetpub\wwwroot ディレクトリに sun-passthrough ディレクトリを作成します。

    cd c:\inetpub\wwwroot

    mkdir sun-passthrough

  2. c:\inetpub\wwwroot\sun-passthrough ディレクトリに errorpagesresource および sec_db_files ディレクトリを作成します。

    cd c:\inetpub\wwwroot\sun-passthrough

    mkdir errorpages

    mkdir resources

    mkdir sec_db_files

  3. DLL ファイルを sun-passthrough ディレクトリにコピーします。

    copy <as_install_dir>/appserver/lib/webserver-plugin/iis/*.dll c:\inetpub\wwwroot\sun-passthrough\

  4. DTD を sun-passthrough ディレクトリにコピーします。

    copy <as_install_dir>/appserver/lib/dtds/sun-loadbalancer*.dtd c:\inetpub\wwwroot\sun-passthrough\

  5. sun-passthrough.properties ファイルを sun-passthrough ディレクトリにコピーします。

    copy <as_install_dir>/appserver/lib/webserver-plugin/iis c:\inetpub\wwwroot\sun-passthrough\

  6. セキュリティー DB ファイルを sun-passthrough ディレクトリにコピーします。

    copy <as_install_dir>/appserver/lib/webserver-plugin/iis/*.db c:\inetpub\wwwroot\sun-passthrough\sec_db_files\

  7. リソースファイルを sun-passthrough ディレクトリにコピーします。

    copy <as_install_dir>/appserver/lib/webserver-plugin/iws/*.res c:\inetpub\wwwroot\sun-passthrough\resource\

  8. エラーページを sun-passthrough ディレクトリにコピーします。

    copy <as_install_dir>/appserver/lib/webserver-plugin/iws/errorpages/*.html c:\inetpub\wwwroot\sun-passthrough\errorpages\

  9. loadbalancer.xml.example テンプレートを sun-passthrough ディレクトリにコピーします。

    copy <as_install_dir>/appserver/lib/install/templates/loadbalancer.xml.example c:\inetpub\wwwroot\sun-passthrough\

  10. 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 互換に設定する必要があります。


インストール中に imq ディレクトリを作成する必要がある (ID 6199697)

Windows プラットフォームでは、Application Server Enterprise Edition をインストールした直後に、Message Queue ブローカが起動に失敗します。ディレクトリ drive:\as\domains\domain1\imq が存在しないことを示すメッセージが表示されます。

domain1 を起動してからブローカを起動した場合には、Application Server によってディレクトリが作成され、この問題は発生しません。

解決方法

  1. ブローカを作成する前に var_home_dir_location を作成します。次のようにします。


    $imqbrokerd -varhome var_home_dir_location
    

    次に例を示します。


    $imqbrokerd -varhome D:\as\domains\domain1\imq

J2EE Tutorial

Sun Java System Application Server Enterprise Edition 8.2 で J2EE 1.4 Tutorial を実行するには、次の作業を実行します。

ライフサイクル管理

ここでは、ライフサイクル管理に関する既知の問題とその解決方法を示します。

ejb-timer-service プロパティーを変更するとエラーが発生する (ID 6193449)

ejb-timer-service プロパティー minimum-delivery-interval9000 に設定したあとで、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(default)=7000
redelivery-interval-in-millis(default)=5000

これらデフォルト以外の値を指定するとエラーが発生します。

ロギング

この節では、ログに関する既知の問題とその解決方法を示します。

access.failure のデバッグ文を設定すると、Application Server の起動時にハングする (ID 6180095)

JVM の java.security.debug オプションを設定すると、サーバーインスタンスの起動がデッドロックで動かなくなります。たとえば、domain.xml で次の設定を行うと、この問題が発生します。

<jvm-options\>-Djava.security.debug=access,failure</jvm-options\>

解決方法

ありません。このフラグは設定しないでください。

Java ES 3 Application Server 以降ログの場所やインスタンスの場所が変更されている (ID 6189409)

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 メッセージキューに関する既知の問題とその解決方法を示します。

タイミングに依存する特定の場合に、JMS 再接続が正常に完了しない (ID 6173308、6189645、6198481、6199510、6208728)

タイミングに依存する場面での再接続の失敗は、さまざまな問題によって引き起こされます。

解決方法

これらの問題は、次の方法で回避できます。

非同期メッセージリスナーの動作が、appclient で 8.0 から 8.1 Update 2 に変更された (ID 6198465)

最新の変更により、非同期メッセージリスナーが app-client コンテナの唯一の稼働しているスレッドである場合、残っている appclient 仮想マシンはデーモンとして存在します。この動作は、ACC で非同期受信を実行する過去のアプリケーションの影響です。この問題は、JMS メッセージリスナーを設定してメインスレッドを終了するアプリケーションクライアントに影響します。

解決方法

メインスレッドを終了しないでください。メッセージリスナーがメインスレッドに通知するのを待ってから、メインスレッドを終了します。

監視

ここでは、監視上の既知の問題とその解決方法を示します。

Application Server への監視フレームワーク統合 (6469302)

Application Server のベータリリースにおいては、デフォルトでは監視フレームワークはサポートされていません。

解決方法

    監視フレームワークを Application Server に統合するには、次の手順を実行します。

  1. <Install_dir>\appserver\lib\install\templates\ee\com.sun.cmm.as.xml ファイルを編集します。

    ${InstalledDate} を Application Server のインストール場所で更新して、${InstalledDate} を現在日付にします。

  2. <Install_dir>\appserver\lib\install\templates\ee\com.sun.cmm.as.xml ファイルを <Install_dir>\appserver\lib にコピーします。

  3. <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 製品に付属するサンプルコードに関する既知の問題とその解決方法を示します。

setup-one-machine-cluster がハングアップする (ID 6195092)

Windows プラットフォームでは、mqfailover コマンドが表示されたら Ctrl+C を押してハングアップしたプロセスを終了させて、setup-one-machine-cluster プロセスを再実行する必要があります。

install_dir\samples\ee-samples\failover\apps\mqfailover\docs\index.html を参照してから、次のコマンドを実行します。

ほかの 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 で終了してから再実行することです。

Message Queue フェイルオーバーのサンプルアプリケーションを実行する前に、JMS リソースを作成する必要があることが、マニュアルに明記されていない (ID 6198003)

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 アプリケーションのセキュリティーおよび証明書に関する既知の問題とその解決方法を示します。

Enterprise Edition 上で J2SE 5.0 を使用して WebServiceSecurity アプリケーションを実行できない (ID 6183318)

WebServiceSecurity アプリケーションは、次の理由から J2SE 5.0 で実行できません。

解決方法

J2SE 1.4.2 で別の JCE プロバイダ (デフォルトで含まれているもの以外) を使用します。この構成では、ハードウェアアクセラレータはサポートされません。

SSL 終了が機能しない (ID 6269102)

ロードバランサ (ハードウェア) を SSL 終了用に設定すると、リダイレクト中に Application Server がプロトコルを https から http に変更します。

解決方法

ハードウェアロードバランサと Application Server の間にソフトウェアロードバランサを追加します。

アップグレードユーティリティー

この節では、アップグレードユーティリティーに関する既知の問題とその解決方法を示します。

サンプルスクリプトで使用する Derby データベースが間違った場所に作成される (ID 6377804)

このバグには、次の 2 つの面があります。

  1. Derby データベースを使用するサンプルアプリケーション設定スクリプトを実行すると、Derby データベースが現在のディレクトリまたは <install_root>/bin に作成されます。

  2. サンプル build Ant スクリプトによって、管理パスワードファイルを保存する password.txt ファイルが現在のディレクトリの下に作成されますが、このディレクトリはルート以外の疎ゾーンシナリオでは書き込み可能ではありません。

解決方法

  1. Derby データベースの場所start-database コマンドで --dbhome オプションを使用して、--dbhome に指定された値の場所にデータベースを作成します。たとえば、次の例は、start-database 用の asadmin コマンドの構文です。


    start-database [--dbhost 0.0.0.0] [--dbport 1527] [--dbhome db_directory] [--echo=false] 
    [--verbose=false]
  2. password.txt ファイルの場所 – 設計上、サンプルディレクトリは書き込み可能であると想定されています。これは、すべてのビルドコマンドにそのディレクトリでの password.txt ファイルの作成が含まれているためです。書き込み可能な場所にサンプルの作業用コピーをインストールするようにしてください。

管理ユーザー名またはパスワードでセミコロン (;) 文字を無効化できない (ID 6473341)

Application Server Enterprise Edition 8.2 インストールでは、管理ユーザー名に特殊文字は使用できません。特殊文字を使用すると、ドメインの作成は失敗します。ただし、管理パスワードには特殊文字を使用できます。

解決方法

Application Server 7 から Application Server 8.2 にアップグレードするときに、管理ユーザー名に特殊文字が含まれていないことを確認してください。

Web コンテナ

ここでは、Web コンテナに関する既知の問題とその解決方法を示します。

ロードバランサプラグインで Apache および IIS がサポートされていない

Sun Java ES 5 Application Server ではロードバランサプラグインで Apache および IIS (Sun 以外の Web コンテナ) がサポートされていません。Sun Java ES ではロードバランサプラグインの設定用に Sun Java System Web Server がインストールされます。

--precompilejsp=true を使用してアプリケーションを配備すると JAR ファイルがロックされることがある (ID 5004315)

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 ファイルが解放されるため、再起動後の配備取り消しや再配備が成功します。

空の <load-on-startup> 要素を持つ Servlet 2.4 ベースの web.xml を含んだ WAR ファイルを配備できない (ID 6172006)

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.xmlweb.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 ページをコンパイルできない (ID 6184122)

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」に設定します。

次のいずれかの方法でこの設定を行うことができます。

これらのいずれかを設定することにより、Antjavac コンパイルのための新規プロセスを生成することが防止されます。

Application Server で、auth-passthrough Web Server 6.1 アドオンがサポートされない (ID 6188932)

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 層配備のシナリオで有効でした。

このようなネットワークアーキテクチャーの場合、クライアントは、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 クライアント証明書など) を上書きすることが可能になるため、authPassthroughEnabledTRUE に設定して、Application Server Enterprise Edition 8.2 インスタンスへの接続を許可する場合は、その対象を信頼できるクライアントまたはサーバーだけに限定する必要があります。予防措置として、authPassthroughEnabledTRUE に設定するのは、企業ファイアウォールの内側にあるサーバーだけにすることをお勧めします。インターネット経由でアクセス可能なサーバーでは、決して authPassthroughEnabledTRUE に設定しないでください。

プロキシ Web サーバーが service-passthrough プラグインを使用して設定されており、要求を authPassthroughEnabledTRUE に設定された Application Server 8.1 Update 2 インスタンスに転送するシナリオでは、SSL クライアント認証は Web サーバープロキシ上で有効になり、プロキシされた Application Server 8.1 Update 2 インスタンス上で無効になる可能性があることに注意してください。この場合、プロキシされた Application Server 8.1 Update 2 インスタンスは、SSL 経由で認証されたかのように引き続き要求を処理し、クライアントの SSL 証明書を、それを要求している任意の配備されたアプリケーションに提供します。

--enabled=false で作成された HTTP リスナーが無効にならない (ID 6190900)

--enabled=false フラグで httplistener を作成すると、リスナーは無効になりません。フラグ --enabled は、リスナーの作成と同時に使用すると効果がありません。

解決方法

リスナーを使用可能状態で作成して、あとで手動で無効にしてください。