このページを使用して、アプリケーション・サーバー・インスタンスの設定を表示または変更します。アプリケーション・サーバーとは、エンタープライズ・アプリケーションを実行するのに必要なサービスを提供するサーバーです。
この管理コンソール・ページを表示するには、 「サーバー」>「アプリケーション・サーバー」>「サーバー名 」とクリックします。
「構成」タブで、フィールドを編集することができます。「ランタイム」タブに、 読み取り専用の情報を表示することができます。「ランタイム」タブは、サーバーが実行中の場合のみ使用可能です。
サーバーの論理名を指定します。サーバー名は、ノード内で固有でなければなりません。 ただし、クラスター内の複数のノードについて、 サーバーとノードのペアが固有であれば、同じサーバー名を持つ異なるサーバーがある場合があります。 このフィールドに表示される値を変更することはできません。
例えば、同じクラスター内で、node1 というノード内の server1 というサーバーと、 node2 というノード内の server1 というサーバーは許可されます。 同じノード内で server1 という 2 つのサーバーを構成することは許可されません。 WebSphere Application Server は、スクリプトでサーバーを参照するなどの管理アクションで、サーバー名を使用します。
z/OS プラットフォームでは、この名前をロング・ネームと呼ぶ場合があります。
データ型 | ストリング |
デフォルト | server1 |
サーバーのショート・ネームを指定します。この名前はセル内で固有でなければなりません。このフィールドは、z/OS プラットフォームにのみ適用されます。ショート・ネームは、 デフォルトの z/OS ジョブ名でもあり、Workload Manager (WLM)、自動リスタート・マネージャー、SAF (例えば RACF)、 および開始済みタスク制御などのオペレーティング・システム固有の機能に対してサーバーを識別します。
このフィールドはオプションです。ショート・ネーム・フィールドに対して値を指定しない場合、 ショート・ネームはデフォルトの BBOSnnn に設定されます。 この場合 nnn は、固有のショート・ネームの作成に使用可能なセル内の最初の空き番号です。 例えば、デフォルトのショート・ネームが既にセル内の他の 2 つのサーバーに割り当てられている場合に、 このサーバーの作成時にショート・ネームを指定しないと、 ショート・ネーム BBOS003 がこのサーバーに割り当てられます。 アプリケーション・サーバーの作成後、この生成済みショート・ネームは、 ご使用の命名規則に準拠した名前に変更することができます。
サーバントと付属のジョブ名のデフォルト値は、 このショート・ネームに S (サーバントの場合) または A (付属の場合) が付いたものです。 8 文字のサーバー・ショート・ネームを使用する必要がある場合、 サーバントと付属のジョブ名は 9 文字の名前になります。 したがって、新規の 8 文字のサーバー・ショート・ネームを使用するには、 サーバント定義と付属のプロセス定義用に、 開始コマンドの引数を更新する必要があります。 『7 文字のサーバー・ショート・ネームの 8 文字への変換』のトピックに、 この更新を行う方法についての説明があります。
サーバーの汎用ショート・ネームを指定します。 この名前はセル内で固有でなければなりません。 このフィールドは、z/OS プラットフォームにのみ適用されます。サーバーの汎用ショート・ネームは、 クラスター遷移名 (非クラスター・サーバーを作成する場合) またはクラスター・ショート・ネーム (クラスター・サーバーを作成する場合) のいずれかになります。
このフィールドはオプションです。汎用ショート・ネーム・フィールドに値を指定しない場合、 汎用ショート・ネームはデフォルトの BBOCnnn に設定されます。 この場合 nnn は、固有の汎用ショート・ネームの作成に使用可能なセル内の最初の空き番号です。 例えば、デフォルトの汎用ショート・ネームが既にセル内の他の 3 つのサーバーに割り当てられている場合に、 このサーバーの作成時に汎用ショート・ネームを指定しないと、 汎用ショート・ネーム BBOC004 がこのサーバーに割り当てられます。
このオプションを使用可能にすると、アプリケーション・サーバーの起動時間が短縮されることがあります。 これには、バイトコード検証の使用不可化や JIT コンパイル・コストの削減などの JVM 設定が含まれることがあります。 実働サーバーでは、 この設定を使用可能にしないでください。
開始時に JVM プロパティー -Xverify および -Xquickstart を使用することを指定します。 このオプションを選択する前に、-Xverify および -Xquickstart プロパティーを汎用引数として JVM 構成に追加します。
このオプションを選択した場合は、構成の変更が有効になる前に構成を保管し、サーバーを再始動する必要があります。
このオプションのデフォルト設定は false であり、 サーバーは開発モードでは始動しないことを示しています。 このオプションを true に設定すると、 サーバーが開発モードで始動するように指定されます (サーバー起動時間が短縮されます)。
データ型 | ブール |
デフォルト | false |
複数のスレッドでサーバーを始動する場合は、このフィールドを選択します。これにより、 起動時間を短縮できます。
サーバー・コンポーネント、サービス、およびアプリケーションが順次ではなく並列に開始されるように指定します。
このオプションのデフォルト設定は true であり、 サーバーはマルチスレッドを使用して始動することを示しています。 このオプションを false に設定すると、サーバーは 複数のスレッドを使用して始動されないことが指定されます (起動時間は長くなります)。
アプリケーションが開始される順序は、ユーザーがアプリケーションに割り当てた順番に従うことに注意してください。 ウェイトが同じアプリケーションは、同時に開始されます。
アプリケーションのウェイトを設定するには、 管理コンソールで「アプリケーション」>「エンタープライズ・アプリケーション」>「アプリケーション名 (application_name)」>「始動の動作」とクリックしてから、 「始動順序」フィールドに適切な値を指定します。 アプリケーションが重要であればあるほど、始動順序の値は低くなります。 例えば、最も重要なアプリケーションに始動順序の値 1 を指定し、次に重要なアプリケーションに値 2 を指定します。 また、次の 4 つのアプリケーションすべてを同時に開始させたい場合は、これら 4 つのアプリケーションに始動順序 3 を指定することができます。
データ型 | 整数 |
デフォルト | 1 |
範囲 | 0 - 2147483647 |
アプリケーション・サーバーを、デフォルトの 31 ビット・モードではなく、64 ビット・モードで実行するかどうかを指定します。 アプリケーション・サーバーを 31 ビット・モードで実行する場合、デプロイメント・マネージャー JVM の最大ヒープ・サイズは 2 ギガバイト (GB) 未満でなければなりません。カスタマー・アプリケーションの追加の仮想ストレージは、アプリケーション・サーバーを 64 ビット・モードに変換し、最大 JVM ヒープ・サイズを増やすことにより、獲得することができます。
このオプションを選択した場合は、最大 JVM ヒープ・サイズ設定を 64 ビット・プロセスに適切な値に変更する必要があります。 例えば、最初にコントローラーとサーバントの最大ヒープ・サイズを 1844m に変更します。
サーバーのモード間には相互依存性はありません。したがって、サーバーのいくつかを 31 ビット・モードで実行し、いくつかを 64 ビット・モードで実行することができます。 ただし、最終的にすべてのサーバーを 64 ビット・モードに変換する必要があります。
このオプションの選択について詳しくは、『64 ビット・モードでのサーバーの実行』のトピックを参照してください。
アプリケーションが多数のサーバー・インプリメンテーション・クラスにアクセスできるかどうかを指定します。
「Allow」を選択した場合、アプリケーションは、多数のサーバー・インプリメンテーション・クラスにアクセスできるようになります。 「Restrict」を選択した場合、アプリケーションは、多数のサーバー・インプリメンテーション・クラスにはアクセスできません。 アプリケーションは、これらのクラスへのアクセスを試みると、ClassNotFoundException を受け取ります。
通常、アプリケーションは、サポートされる API を使用し、システム内部にアクセスする必要はありません。
このプロパティーのデフォルト値は Allow です。
単一のクラス・ローダーですべてのアプリケーションをロードするか、 またはアプリケーションごとに異なるクラス・ローダーを使用するかを選択します。
クラス・ローダーが、クラスをロードする際に、 最初に親クラス・ローダーを検索するのか、 あるいはアプリケーション・クラス・ローダーを検索するのかを指定します。 Developer Kit クラス・ローダーおよび WebSphere Application Server クラス・ローダーの標準は、「親が最初」です。
このフィールドは、「クラス・ローダー・ポリシー」フィールドを single にした場合にのみ適用されます。
Parent last を選択すると、 アプリケーションは、親クラス・ローダーに含まれるクラスをオーバーライドできますが、 オーバーライドされたクラスとオーバーライドされていないクラスを一緒に使用した場合、 このアクションにより、ClassCastException またはリンケージ・エラーが発生する可能性があります。