この章では、asadmin コマンド行ユーティリティーを使用して、&ProductBrandTM; Enterprise Server v3 の環境で一般的な管理タスクを実行する方法について説明します。
ここでは、次のテーマを取り上げます。
管理コンソール を使用してこの章のタスクを実行する方法は、管理コンソール のオンライン ヘルプに記載されています。
Sun GlassFish Enterprise Server の管理タスクを実行するには、コマンド行またはスクリプトから asadmin ユーティリティーを使用します。このユーティリティーは、管理コンソール インタフェースの代わりに使用できます。
ここでは、次のテーマを取り上げます。
asadmin ユーティリティは、as-install /bin ディレクトリにあります。パスを指定せずに asadmin ユーティリティーを実行するには、このディレクトリをパスに入れてください。
asadmin ユーティリティーを実行するための構文は次のとおりです。
asadmin [asadmin-util-options] [subcommand [subcommand-options] [operands]] |
この構文で置き換え可能な項目については、以降の項で説明します。この構文の詳細については、asadmin(1M) のマニュアルページを参照してください。
次の「サブコマンド」は、実行する動作またはタスクを指定します。サブコマンドは大文字と小文字を区別します。サブコマンドは、ローカルサブコマンドとリモートサブコマンドのいずれかです。
「ローカルサブコマンド」は、ドメイン管理サーバー (DAS) を動作させずに実行できます。ただし、サブコマンドを実行してインストールディレクトリやドメインディレクトリにアクセスするには、ドメインのホストマシンにログインする必要があります。
「リモートコマンド」は常に、DAS に接続して DAS でサブコマンドを実行することにより実行されます。稼働中の DAS が必要です。
このリリースの Enterprise Server のサブコマンドリストについては、『Sun GlassFish Enterprise Server v3 Reference Manual』の第 1 節を参照してください。
オプションは、asadmin ユーティリティーとそのサブコマンドの動作を制御します。オプションは大文字と小文字を区別します。
asadmin ユーティリティーには、次のタイプのオプションがあります。
asadmin ユーティリティーのオプション。これらのオプションは、asadmin ユーティリティーの動作を制御します。サブコマンドの動作は制御しません。asadmin ユーティリティーのオプションは、サブコマンドの前後に指定できますが、サブコマンドの後に asadmin ユーティリティーのオプションを指定することは推奨しません。asadminユーティリティーのオプションは、サブコマンドの前、または後にすべて指定する必要があります。asadmin ユーティリティーのオプションをサブコマンドの前と後の両方に指定した場合、エラーが発生します。asadmin ユーティリティーのオプションの詳細については、asadmin(1M) のマニュアルページを参照してください。
「サブコマンドオプション」。これらのオプションは、サブコマンドの動作を制御します。asadmin ユーティリティーの動作は制御しません。サブコマンドオプションは、サブコマンドの後に指定する必要があります。サブコマンドのオプションの詳細については、『Sun GlassFish Enterprise Server v3 Reference Manual』のサブコマンドの項目を参照してください。
サブコマンドオプションの一部は、このリリースの Enterprise Server ではサポートされていません。サポートされていないオプションを指定しても、構文エラーは発生しません。その代わりコマンドが正常に実行され、未サポートのオプションは単に無視されます。
サブコマンドオプションの名前が、asadmin ユーティリティーのオプションの名前と同じ場合がありますが、2 つのオプションの効果は異なります。
オプションには、長形式と省略形式があります。
オプションの省略形式では、ダッシュ 1 つ (-) の後に文字 1 つが続きます。
オプションの長形式では、ダッシュ 2 つ (--) の後にオプションのワードが続きます。
たとえば、terse 出力を指定するオプションの省略形式と長形式は次のとおりです。
省略形式: -t
長形式: --terse
論理型オプションを除く多くのオプションには、機能の有効と無効を切り替える引数の値が必要です。
オペランドは、サブコマンドの動作対象となる項目を指定します。オペランドは、サブコマンドオプションの引数の後に指定する必要があり、空白 1 文字、タブ 1 文字、またはダッシュ 2 文字 (--) で区切ります。asadmin ユーティリティーは、サブコマンドオプションとその値に続くものはすべて、オペランドとして扱います。
シングルモードでは、使用するサブコマンドについて個々に asadmin コマンドを入力する必要があります。 サブコマンドの実行後は、オペレーティングシステムのコマンドシェルに戻ります。asadmin ユーティリティーのオプションは、実行する asadmin コマンドについて個々に指定する必要があります。複数のサブコマンドについて同じ asadmin ユーティリティーのオプションが必要な場合は、マルチモードで asadmin ユーティリティーを使用します。詳細については、「マルチモードセッションを開始する」を参照してください。
オペレーティングシステムのコマンドシェルで、asadmin ユーティリティーを実行してサブコマンドを指定します。
必要に応じて、必須の asadmin ユーティリティーのオプション、サブコマンドのオプション、およびオペランドも指定します。
この例は、シングルモードでサブコマンド list-applications(1) を実行します。この例では、すべてのオプションでデフォルト値を使用します。
この例は、ローカルホストでアプリケーション hello が配備されていることを示します。
asadmin list-applications hello <web> Command list-applications executed successfully. |
この例は、シングルモードで asadmin ユーティリティーのオプション --host とサブコマンド list-applications を指定します。この例では、DAS はホスト srvr1.example.com で稼働中です。
この例は、アプリケーション basic-ezcomp、scrumtoys、ejb31-war、および automatic-timer-ejb がホスト srvr1.example.com に配備されていることを示します。
asadmin --host srvr1.example.com list-applications basic-ezcomp <web> scrumtoys <web> ejb31-war <ejb, web> automatic-timer-ejb <ejb> Command list-applications executed successfully. |
この例は、シングルモードで asadmin ユーティリティーオプション --host、サブコマンドオプション --type、およびサブコマンド list-applications を指定します。この例では、DAS がホスト srvr1.example.com で稼働し、web タイプのアプリケーションが一覧表示されます。
asadmin --host srvr1.example.com list-applications --type web basic-ezcomp <web> scrumtoys <web> ejb31-war <ejb, web> Command list-applications executed successfully. |
Enterprise Server には、asadmin ユーティリティーとそのサブコマンドの構文、目的、およびオプションに関するヘルプ情報が用意されています。このヘルプ情報は、UNIX® プラットフォームのマニュアルページのスタイルで作成されています。このヘルプ情報は、『Sun GlassFish Enterprise Server v3 Reference Manual』にも記載されています。
リモートサブコマンドのヘルプ情報を表示する場合は、サーバーが稼働中であることを確認してください。
リモートサブコマンドを実行するには、稼働中のサーバーが必要です。
対象のサブコマンドを、help サブコマンドのオペランドとして指定します。
オペランドを指定せずに help サブコマンドを実行した場合、asadmin ユーティリティーのヘルプ情報が表示されます。
この例は、asadmin ユーティリティーのヘルプ情報を表示します。
asadmin help |
この例は、サブコマンド create-jdbc-resource のヘルプ情報を表示します。
asadmin help create-jdbc-resource |
使用できるサブコマンドを表示するには、サブコマンド list-commands(1) を使用します。ローカルサブコマンドが、リモートサブコマンドの前に表示されます。サーバーが稼働していない場合は、ローカルサブコマンドのみが表示されます。
asadmin ユーティリティーは、複数コマンドモード、つまりマルチモードで使用できます。マルチモードでは、asadmin ユーティリティーを一度実行してマルチモードセッションを開始します。セッションを終了してオペレーティングシステムのコマンドシェルに戻るまでの間、asadmin ユーティリティーは継続してサブコマンドを受け取ります。マルチモードセッションで設定した asadmin ユーティリティーのオプションは、セッションの後続のサブコマンドすべてについて使用されます。
マルチモードセッションを開始するには、稼働中の DAS は「不要」です。
次のいずれかの操作を行います。
サブコマンドを指定せずに asadmin ユーティリティーを実行します。
サブコマンド multimode(1) を使用します。
必要に応じて、マルチモードセッション全体に適用する asadmin ユーティリティーのオプションも指定します。
マルチモードセッションでは、コマンド行に asadmin> プロンプトが表示されます。このプロンプトに asadmin のサブコマンドを入力して Enterprise Server を管理できます。
この例は、マルチモードセッションを開始し、asadmin ユーティリティーのオプション --user および --passwordfile をこのセッションに設定します。
asadmin --user admin1 --passwordfile pwd.txt multimode |
この例は、サブコマンド multimode を使用して、デフォルトの asadmin ユーティリティーのオプションを使用するマルチモードセッションを開始します。
asadmin multimode |
コマンド行に asadmin> プロンプトが表示されます。
この例は、マルチモードセッションを開始し、そのセッションでサブコマンド list-domains を実行します。
asadmin Enter commands one per "line", ^D to quit asadmin> list-domains Name: domain1 Status: Running Command list-domains executed successfully. asadmin> |
既存のセッションからマルチモードセッションを開始するには、既存のセッションからサブコマンド multimode を実行します。2 つ目のマルチモードセッションを終了すると、元のマルチモードセッションに戻ります。
また、コマンド行に asadmin help multimode を入力して、サブコマンドの詳細構文とオプションも表示できます。
asadmin> プロンプトに、次のコマンドまたはキーコンビネーションのいずれかを入力します。
exit
quit
UNIX および Linux システム: Ctrl-D
Windows システム: Ctrl-Z
オペレーティングシステムのコマンドシェルに戻ります。asadmin> プロンプトは表示されなくなります。asadmin> プロンプトがまだ表示されている場合は、マルチモードセッションからマルチモードセッションを開いた可能性があります。この場合は、この手順を繰り返して残りのマルチモードセッションを終了します。
ファイルから asadmin の一連のサブコマンドを実行すると、繰り返し実行するタスクを自動化できます。
実行するサブコマンドのシーケンスを含むプレーンテキストファイルを作成します。
作成したファイルを指定して、サブコマンド multimode(1) を実行します。
必要に応じて、ファイル内のサブコマンドを実行可能にするために必要な asadmin ユーティリティーのオプションも指定します。
この例には、次のものが含まれます。
asadmin のサブコマンドのシーケンスを含む、名前が commands_file.txt のファイルリスト
ファイル commands_file.txt 内のサブコマンドを実行するためのコマンド
commands_file.txt ファイルには、次の動作シーケンスを実行するための asadmin ユーティリティーのサブコマンドがあります。
ドメイン customdomain の作成
ドメイン customdomain の開始
使用できるすべてのサブコマンドの一覧表示
ドメイン customdomain の停止
ドメイン customdomain の削除
ファイル commands_file.txt の内容は次のとおりです。
create-domain --portbase 9000 customdomain start-domain customdomain list-commands stop-domain customdomain delete-domain customdomain
この例は、commands_file.txt ファイル内のサブコマンドのシーケンスを実行します。ファイル内のサブコマンド create-domain にオプション --portbase が指定されているので、asadmin ユーティリティーのオプション --port も設定する必要があります。
asadmin --port 9048 multimode --file commands_file.txt |
上の例のサブコマンドの詳細については、次のマニュアルページを参照してください。
共有サーバーインスタンスでは、参照される構成に定義された属性の上書きが頻繁に必要になります。任意の構成の属性を、対応する名前のシステムプロパティーによって上書きできます。
ここでは、次のテーマを取り上げます。
ドメインまたは構成の 1 つ以上のシステムプロパティーの作成または更新を行うには、リモートモードでサブコマンド create-system-properties を使用します。 任意の構成の属性を、対応する名前のシステムプロパティーによって上書きできます。
サーバーが稼働中であることを確認してください。
リモートサブコマンドには、実行中のサーバーが必要です。
create-system-properties(1) サブコマンドを使用して、システムプロパティーを作成します。
サブコマンドのプロパティーに関する情報が、このマニュアルページにあります。
この例は、localhost の http-listener-port=1088 に関するシステムプロパティーを作成します。
asadmin> create-system-properties http-listener-port=1088 Command create-system-properties executed successfully. |
コマンド行に asadmin help create-system-properties と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
ドメインまたは構成に適用するシステムプロパティーを一覧表示するには、リモートモードで list-system-properties サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-system-properties(1) サブコマンドを使用して、システムプロパティーを一覧表示します。
HTTP_LISTENER_PORT や HTTP_SSL_LISTENER_PORT などの事前定義プロパティーを含む、既存のシステムプロパティーが表示されます。
この例は、ホスト localhost のシステムプロパティーを一覧表示します。
asadmin> list-system-properties http-listener-port=1088 Command list-system-properties executed successfully. |
コマンド行に asadmin help list-system-properties と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
システムプロパティーを削除するには、リモートモードで delete-system-property サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-system-properties(1) サブコマンドを使用して、既存のシステムプロパティーを一覧表示します。
delete-system-property(1) サブコマンドを使用して、システムプロパティーを削除します。
必要に応じて、システムプロパティーが削除されたことをユーザーに通知します。
この例は、localhost から http-listener-port という名前のシステムプロパティーを削除します。
asadmin> delete-system-property http-listener-port Command delete-system-property executed successfully. |
コマンド行に asadmin help delete-system-property と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
この節では、Enterprise Server 環境にリソースを統合する方法を説明します。JDBC のような特定リソースの管理に関する情報は、他の章に記載されています。
ここでは、次のテーマを取り上げます。
指定の XML ファイル内に名前が指定されているリソースを作成するには、リモートモードで add-resources サブコマンドを使用します。サポートするリソースは、JDBC 接続プールおよびリソース、JMS、JNDI、および JavaMail のリソース、カスタムリソース、コネクタリソースおよび作業セキュリティーマップ、admin オブジェクト、およびリソースアダプタの構成です。
XML ファイルは、as-install/domains/domain1/config ディレクトリに配置される必要があります。相対パスを指定した場合、または単に XML ファイルの名前を指定した場合は、このサブコマンドのオペランドの前に as-install/domains/domain1/config が付けられます。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
add-resources(1) サブコマンドを使用して、XML ファイルからリソースを追加します。
このサブコマンドのプロパティーについては、このマニュアルページに記載されています。
Enterprise Serverを再起動します。
「ドメインの再起動」を参照してください。
この例は、localhost の resource.xml の内容を使用して、リソースを作成します。
asadmin> add-resources c:\tmp\resource.xml Command : JDBC resource jdbc1 created successfully. Command : JDBC connection pool poolA created successfully. Command add-resources executed successfully. |
コマンド行に asadmin help add-resources と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
特定サーバーの Enterprise Server のバージョンに関する情報を表示するには、リモートモードで version サブコマンドを使用します。指定のログイン (ユーザーとパスワード) およびターゲット (ホストとポート) の情報を使用してサブコマンドがサーバーと通信できない場合は、ローカルバージョンと警告メッセージが表示されます
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
version(1) サブコマンドを使用してバージョンを表示します。
この例では、ローカルホストの Enterprise Server のバージョンを表示します。
asadmin> version Version = GlassFish v3 Command version executed successfully. |
コマンド行に asadmin help version と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
配備した JavaTM アプリケーションを一覧表示するには、リモートモードで list-applications サブコマンドを使用します。--type オプションを指定しない場合は、すべてのアプリケーションが一覧表示されます。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-applications(1) サブコマンドを使用して、アプリケーションを一覧表示します。
この例では、localhost の Web アプリケーションを一覧表示します。
asadmin> list-applications --type web hellojsp <web> Command list-applications executed successfully. |
コマンド行に asadmin help list-applications と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
アプリケーションコンテナを一覧表示するには、リモートモードで list-containers サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-containers(1) サブコマンドを使用して、コンテナを一覧表示します。
この例は、localhost のコンテナを一覧表示します。
asadmin> list-containers List all known application containers Container : grizzly Container : ejb Container : webservices Container : ear Container : appclient Container : connector Container : jpa Container : web Container : jruby Container : security Container : webbeans Command list-containers executed successfully. |
コマンド行に asadmin help list-containers と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
Enterprise Server のモジュールサブシステムにアクセスできるモジュールを一覧表示するには、リモートモードで list-modules サブコマンドを使用します。各モジュールの状態が含まれます。表示される状態には、NEW と READY があります。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-modules(1) サブコマンドを使用して、モジュールを一覧表示します。
この例はアクセス可能なモジュールを一覧表示します。
asadmin> list-modules |
次のような情報が表示されます (出力の一部を示す)。
List Of Modules Module : org.glassfish.web.jstl-connector:10.0.0.b28 properties=(visibility=public,State=READY,Sticky=true) Module Characteristics : List of Jars implementing the module Jar : file:/C:/Preview/v3_Preview_release/distributions/web/target/glass fish/modules/web/jstl-connector.jar Module Characteristics : List of imported modules Module Characteristics : Provides to following services Module : org.glassfish.admingui.console-common:10.0.0.b28 properties=(visibility=public,State=NEW,Sticky=true) Module : org.glassfish.admin.launcher:10.0.0.b28 properties=(visibility=public,State=NEW,Sticky=true) Module : org.glassfish.external.commons-codec-repackaged:10.0.0.b28 properties=(visibility=public,State=NEW,Sticky=true) Module : com.sun.enterprise.tiger-types-osgi:0.3.32.Preview-b28 properties=(visibility=public,State=READY,Sticky=true) Module Characteristics : List of imported modules Module Characteristics : Provides to following services Module Characteristics : List of Jars implementing the module Jar : file:/C:/Preview/v3_Preview_release/distributions/web/target/glass fish/modules/tiger-types-osgi.jar. . . . Command list-modules executed successfully. |
コマンド行に asadmin help list-modules と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
配備した asadmin のサブコマンドを一覧表示するには、リモートモードで list-commands サブコマンドを使用します。リモートサブコマンドのみ、またはローカルサブコマンドのみを一覧表示するように指定できます。このサブコマンドのデフォルトでは、ローカルサブコマンドのリストの後にリモートサブコマンドのリストが表示されます。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-commands(1) サブコマンドを使用して、サブコマンドを一覧表示します。
この例は、ローカルサブコマンドのみを一覧表示します。
asadmin> list-commands --localonly create-domain delete-domain list-commands list-domains login monitor start-database start-domain stop-domain stop-database version Command list-commands executed successfully. |
コマンド行に asadmin help list-commands と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
タイマーサービスは、エンタープライズ Bean コンテナによって提供され、エンタープライズ Bean が使用する通知やイベントのスケジュールに使用される、持続的なトランザクション通知サービスです。ステートフルセッション Beans 以外のエンタープライズ Beans はすべて、タイマーサービスからの通知を受信できます。このサービスによって設定された持続タイマーは、サーバーのシャットダウンや再起動では破棄されません。
指定のサーバーインスタンスが所有する持続タイマーを一覧表示するには、リモートモードで list-timers サブコマンドを使用します。この情報を使用して、タイマーを移行するかどうかの決定、または移行が正常に完了したかどうかの検証ができます。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-timers(1) サブコマンドを使用して、タイマーを一覧表示します。
この例は、特定のスタンドアロンサーバーインスタンスのタイマーを一覧表示します。現在、アクティブなタイマーが 1 つ設定されています。
asadmin> list-timers server 1 The list-timers command was executed successfully. |
指定した配備済みコンポーネントの状態 (有効または無効) を取得するには、リモートモードで show-component-status サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
show-component-status(1) サブコマンドを使用して、コンポーネントの状態を表示します。
この例は、MEjbApp コンポーネントの状態を表示します。
asadmin> show-component-status MEjbApp Status of MEjbApp is enabled Command show-component-status executed successfully. |
Enterprise Server は、新規にインストールされたアドオンコンポーネントが提供するデータなど、Enterprise Server の監視データや構成データにアクセスできる表現状態転送 (REST) インタフェースを装備しています。
Enterprise Server の REST インタフェースには、次のようなクライアントアプリケーションからアクセスできます。
また、Enterprise Server の REST インタフェースは、次のような言語で開発された REST クライアントアプリケーションでも使用できます。
JavaScript
Ruby
Perl
Java
JavaFX
Enterprise Server の REST インタフェースの実装は、project Jersey をベースにしています。Project Jersey は、Java TM 仕様要求 (JSR) 311: JAX-RS、RESTful Web サービス用 Java API の参照実装です。JSR 311 に関する情報は、JSR 311 プロジェクトのホームページにも記載されています。
ここでは、次のテーマを取り上げます。
構成および監視のオブジェクトツリーの各ノードは、HTTP uniform resource locator (URL) からアクセスできる REST リソースとして表現されます。Enterprise Server の監視データや構成データの REST リソースにアクセスするには、稼働中の DAS が必要です。
構成および監視のオブジェクトツリーのノードを表現するリソースの URL の形式は、次のとおりです。
構成: http:// host:port/management/domain/ path
監視: http:// host:port/monitoring/domain/ path
これらの URL で置き換え可能な項目は次のとおりです。
DAS が稼働中のホスト
管理用の HTTP ポートまたは HTTPS ポート
ノードへのパス。パスはノードのドット表記名で、各ドット (.) がスラッシュ (/) に置換されます。詳細については次のドキュメントを参照してください。
Enterprise Server の監視データまたは構成データについて、REST リソースの URL を Web ブラウザで開いた場合、ブラウザには、リソースの次の情報を含む Web ページが表示されます。
リソースの属性とその値のリストリソースが構成ツリーのノードを表現している場合は、それらの属性は、リソースの更新に使用できる HTML 形式で表示されます。監視ツリーにあるノードのリソースの属性は、読み取り専用です。
リソースの子を示すハイパーテキストリンクのリストこのリンクのリストを使用して、リソースを含むツリー内を移動して、ツリー内のすべてのリソースを検出できます。
次の図に、ドメインを管理する REST リソースの Web ページを示します。
Enterprise Server の REST インタフェースは、監視および構成のオブジェクトツリーのノードにアクセスする方法をサポートしています。
次の表に、監視データや構成データを管理する REST メソッド、および各メソッドで実行できるタスクを示します。これらのメソッドは、HTTP 1.1 プリミティブです。これらのプリミティブの詳細仕様については、Hypertext Transfer Protocol -- HTTP/1.1 を参照してください。
表 2–1 監視データと構成データを管理する REST リソースメソッド
作業 |
REST メソッド |
---|---|
ツリー内のノードがサポートするメソッドおよびメソッドパラメータの判定 |
OPTIONS または GET |
ツリー内のノードのデータ取得 |
GET |
ツリーへのノードの追加 |
POST |
ツリー内のノードの更新 |
POST |
ツリーからのノードの削除 |
DELETE |
GET メソッドを OPTIONS メソッドの代わりに使用して、ツリー内のノードがサポートするメソッドおよびメソッドパラメータを判定することができます。GET メソッドは、ノードの追加情報も表示します。詳細については、「ツリー内のノードのデータを取得する」を参照してください。
ツリー内のノードがサポートするメソッドおよびメソッドパラメータは、ノードを表す REST リソースによって決まります。
監視用の REST リソースは、GET メソッドのみをサポートします。
構成用の REST リソースはすべて、GET メソッドおよび OPTIONS メソッドをサポートします。ただし、構成用の一部の REST リソースは、POST メソッドと DELETE メソッドもサポートします。
ツリーのノードで操作を実行する前に、そのノードがサポートするメソッドおよびメソッドパラメータを判定します。
この情報の表示形式を指定できます。詳細については、「リソースの表現形式」を参照してください。
サーバーが実行されていることを確認します。
Enterprise Server のデータについて、REST リソースを操作するには、稼働中のサーバーが必要です。
ノードを表す REST リソースに対して、適切なメソッドを使用します。
GET メソッドと OPTIONS メソッドは、リソースがサポートするメソッドのリストを返します。各メソッドについて、使用できるメッセージパラメータのリスト、または使用できるクエリーパラメータのリストが返されます。
この例は、cURL ユーティリティーを使用して、ドメインのリソースがサポートするメソッドおよびメソッドパラメータを判定します。この例は、cURL ユーティリティーの次に示すオプションを使用します。
-X: OPTIONS メソッドを使用していることを示します
-H: リソースが JavaScript Object Notation (JSON) で記述されていることを示します
この例では、DAS がローカルホストで稼働中で、管理用の HTTP ポートは 4848 です。OPTIONS メソッドに加えて、このリソースは POST メソッドと GET メソッドをサポートしています。
curl -X OPTIONS -H "Accept: application/json" http://localhost:4848/management/domain {"Domain": { "Method":{ "Name":"POST", "Message Parameters":{ "log-root":{"Key":"false", "Type":"string", "Optional":"true"}, "application-root":{"Key":"false", "Type":"string", "Optional":"true"}, "locale":{"Key":"false", "Type":"string", "Optional":"true"}, "version":{"Key":"false", "Type":"string", "Optional":"true"} } }, "Method":{ "Name":"GET" } } } |
ツリー内のノードのデータを取得すると、そのノードを表す REST リソースに関する次の情報が得られます。
リソースがサポートする REST メソッドのリスト
リソースの属性とその値のリスト
リソースの子の URL のリスト
この情報の表示形式を指定できます。詳細については、「リソースの表現形式」を参照してください。
サーバーが実行されていることを確認します。
Enterprise Server のデータについて、REST リソースを操作するには、稼働中のサーバーが必要です。
ノードを表す REST リソースに対して、GET メソッドを使用します。
この例は、cURL ユーティリティーを使用して、ドメインのリソースデータを取得します。この例は、cURL ユーティリティーの次に示すオプションを使用します。
-X: GET メソッドを使用していることを示します
-H: リソースが JavaScript Object Notation (JSON) で記述されていることを示します
この例では、DAS がローカルホストで稼働中で、管理用の HTTP ポートは 4848 です。
改行は読みやすくするためです。
curl -X GET -H "Accept: application/json" http://localhost:4848/management/domain { "Domain":{"log-root":"${com.sun.aas.instanceRoot}/logs", "application-root":"${com.sun.aas.instanceRoot}/applications", "locale":"", "version":"74.1"}, "Methods":{ "Method":{ "Name":"POST", "Message Parameters":{ "log-root":{"Key":"false", "Type":"string", "Optional":"true"}, "application-root":{"Key":"false", "Type":"string", "Optional":"true"}, "locale":{"Key":"false", "Type":"string", "Optional":"true"}, "version":{"Key":"false", "Type":"string", "Optional":"true"} } }, "Method":{ "Name":"GET" } }, "Child Resources":[ "http://localhost:4848/management/domain/configs", "http://localhost:4848/management/domain/resources", "http://localhost:4848/management/domain/servers", "http://localhost:4848/management/domain/property", "http://localhost:4848/management/domain/applications", "http://localhost:4848/management/domain/system-applications", "http://localhost:4848/management/domain/stop", "http://localhost:4848/management/domain/restart", "http://localhost:4848/management/domain/uptime", "http://localhost:4848/management/domain/version", "http://localhost:4848/management/domain/rotate-log", "http://localhost:4848/management/domain/host-port" ] |
サーバーが実行されていることを確認します。
Enterprise Server のデータについて、REST リソースを操作するには、稼働中のサーバーが必要です。
ノードの親を表すリソースの POST メソッドについて、使用できるメッセージパラメータを調べます。
この手順の実行方法については、「ツリー内のノードがサポートするメソッドおよびメソッドパラメータを判定する」を参照してください。
追加するノードの親を表す REST リソースに対して、POST メソッドを使用します。
ノードが追加されたことを確認します。
追加したノード (親ではない) を表すリソースに対してこの手順を実行します。この手順の実行方法については、「ツリー内のノードのデータを取得する」を参照してください。
この例は、cURL ユーティリティーを使用して、JDBC リソースを表す REST リソースを作成することにより、ツリーに JDBC リソースを追加します。
この例では、DAS がローカルホストで稼働中で、管理用の HTTP ポートは 4848 です。
改行は読みやすくするためです。
この手順は、リソース jdbc-resource の POST メソッドに使用できるメッセージパラメータを調べます。
curl -X OPTIONS -H "Accept: application/json" http://localhost:4848/management/domain/resources/jdbc-resource {"JdbcResource": { "Method":{ "Name":"POST", "Message Parameters":{ "id":{"Acceptable Values":"", "Default Value":"", "Type":"string", "Optional":"false"}, "enabled":{"Acceptable Values":"", "Default Value":"true", "Type":"boolean", "Optional":"true"}, "description":{"Acceptable Values":"", "Default Value":"", "Type":"string", "Optional":"true"}, "target":{"Acceptable Values":"", "Default Value":"", "Type":"string", "Optional":"true"}, "property":{"Acceptable Values":"", "Default Value":"", "Type":"string", "Optional":"true"}, "connectionpoolid":{"Acceptable Values":"", "Default Value":"", "Type":"string", "Optional":"false"} } }, "Method":{ "Name":"GET" } } } |
この手順は、jdbc-resource リソースの子としてリソースを追加します。cURL ユーティリティーのオプション -d は、必要なメッセージパラメータを次のように設定します。
id が jdbc/myjdbcresource に設定されます。
connectionpoolid が DerbyPool に設定されます。
curl -X POST -d "id=jdbc/myjdbcresource&connectionpoolid=DerbyPool" http://localhost:4848/management/domain/resources/jdbc-resource "http://localhost:4848/management/domain/resources/jdbc-resource/ jdbc/myjdbcresource" created successfully. |
この手順は、ノードを表す REST リソースのデータを取得することにより、ノードが追加されたことを確認します。
curl -X GET -H "Accept: application/json" http://localhost:4848/management/domain/resources/ jdbc-resource/jdbc-myjdbcresource { "JdbcMyjdbcresource":{"enabled":"true", "pool-name":"DerbyPool", "description":"", "jndi-name":"jdbc/myjdbcresource", "object-type":"user"}, "Methods":{ "Method":{ "Name":"POST", "Message Parameters":{ "enabled":{"Key":"false", "Default Value":"true", "Type":"boolean", "Optional":"true"}, "pool-name":{"Key":"false", "Type":"string", "Optional":"true"}, "description":{"Key":"false", "Type":"string", "Optional":"true"}, "jndi-name":{"Key":"true", "Type":"string", "Optional":"true"}, "object-type":{"Key":"false", "Default Value":"user", "Type":"string", "Optional":"true"} } }, "Method":{ "Name":"GET" }, "Method":{ "Name":"DELETE", "Message Parameters":{ "target":{"Acceptable Values":"", "Default Value":"", "Type":"string", "Optional":"true"} } } } } |
サーバーが実行されていることを確認します。
Enterprise Server のデータについて、REST リソースを操作するには、稼働中のサーバーが必要です。
ノードを表すリソースの POST メソッドについて、使用できるメッセージパラメータを判定します。
この手順の実行方法については、「ツリー内のノードがサポートするメソッドおよびメソッドパラメータを判定する」を参照してください。
更新するノードを表す REST リソースに対して、POST メソッドを使用します。
ノードが更新されたことを確認します。
この手順の実行方法については、「ツリー内のノードのデータを取得する」を参照してください。
この例は、cURL ユーティリティーを使用して、JDBC リソースを表す REST リソースを変更することにより、ツリーの JDBC リソースを更新します。
この例では、DAS がローカルホストで稼働中で、管理用の HTTP ポートは 4848 です。
改行は読みやすくするためです。
この手順は、リソース jdbc-myjdbcresource の POST メソッドに使用できるメッセージパラメータを調べます。
curl -X OPTIONS -H "Accept: application/json" http://localhost:4848/management/domain/resources/ jdbc-resource/jdbc-myjdbcresource {"JdbcMyjdbcresource": { "Method":{ "Name":"POST", "Message Parameters":{ "enabled":{"Key":"false", "Default Value":"true", "Type":"boolean", "Optional":"true"}, "pool-name":{"Key":"false", "Type":"string", "Optional":"true"}, "description":{"Key":"false", "Type":"string", "Optional":"true"}, "jndi-name":{"Key":"true", "Type":"string", "Optional":"true"}, "object-type":{"Key":"false", "Default Value":"user", "Type":"string", "Optional":"true"} } }, "Method":{ "Name":"GET" }, "Method":{ "Name":"DELETE", "Message Parameters":{ "target":{"Acceptable Values":"", "Default Value":"", "Type":"string", "Optional":"true"} } } } } |
この手順は、jdbc-myjdbcresource が表す JDBC リソースを無効にするように、REST リソース jdbc-myjdbcresource を更新します。cURL ユーティリティーのオプション -d は、メッセージパラメータ enabled を disabled に設定します。
curl -X POST -d "enabled=false" http://localhost:4848/management/domain/resources/ jdbc-resource/jdbc-myjdbcresource "http://localhost:4848/management/domain/resources/jdbc-resource/ jdbc-myjdbcresource" updated successfully. |
この手順は、ノードを表す REST リソースのデータを取得することにより、ノードが更新されたことを確認します。
curl -X GET -H "Accept: application/json" http://localhost:4848/management/domain/resources/ jdbc-resource/jdbc-myjdbcresource { "JdbcMyjdbcresource":{"enabled":"false", "pool-name":"DerbyPool", "description":"", "jndi-name":"jdbc/myjdbcresource", "object-type":"user"}, "Methods":{ "Method":{ "Name":"POST", "Message Parameters":{ "enabled":{"Key":"false", "Default Value":"true", "Type":"boolean", "Optional":"true"}, "pool-name":{"Key":"false", "Type":"string", "Optional":"true"}, "description":{"Key":"false", "Type":"string", "Optional":"true"}, "jndi-name":{"Key":"true", "Type":"string", "Optional":"true"}, "object-type":{"Key":"false", "Default Value":"user", "Type":"string", "Optional":"true"} } }, "Method":{ "Name":"GET" }, "Method":{ "Name":"DELETE", "Message Parameters":{ "target":{"Acceptable Values":"", "Default Value":"", "Type":"string", "Optional":"true"} } } } } |
サーバーが実行されていることを確認します。
Enterprise Server のデータについて、REST リソースを操作するには、稼働中のサーバーが必要です。
ノードが削除できることを確認します。
この手順の実行方法については、「ツリー内のノードがサポートするメソッドおよびメソッドパラメータを判定する」を参照してください。
ノードが削除されたことを確認します。
削除したノードを表すリソースに対してこの手順を実行します。この手順の実行方法については、「ツリー内のノードのデータを取得する」を参照してください。
この例は、cURL ユーティリティーを使用して、JDBC リソースを表す REST リソースを削除することにより、ツリーから JDBC リソースを削除します。
この例では、DAS がローカルホストで稼働中で、管理用の HTTP ポートは 4848 です。
改行は読みやすくするためです。
この手順は、リソース jdbc-myjdbcresource がサポートする REST のメソッドを取得することにより、ノードが削除できることを確認します。
curl -X OPTIONS -H "Accept: application/json" http://localhost:4848/management/domain/resources/ jdbc-resource/jdbc-myjdbcresource {"JdbcMyjdbcresource": { "Method":{ "Name":"POST", "Message Parameters":{ "enabled":{"Key":"false", "Default Value":"true", "Type":"boolean", "Optional":"true"}, "pool-name":{"Key":"false", "Type":"string", "Optional":"true"}, "description":{"Key":"false", "Type":"string", "Optional":"true"}, "jndi-name":{"Key":"true", "Type":"string", "Optional":"true"}, "object-type":{"Key":"false", "Default Value":"user", "Type":"string", "Optional":"true"} } }, "Method":{ "Name":"GET" }, "Method":{ "Name":"DELETE", "Message Parameters":{ "target":{"Acceptable Values":"", "Default Value":"", "Type":"string", "Optional":"true"} } } } } |
この手順は、リソース jdbc-myjdbcresource を削除します。
curl -X DELETE http://localhost:4848/management/domain/resources/ jdbc-resource/jdbc-myjdbcresource |
この手順は、ノードの親を表す REST リソースのデータを取得することにより、ノードが削除されたことを確認します。
curl -X GET -H "Accept: application/json" http://localhost:4848/management/domain/resources/jdbc-resource/ { "JdbcResource":{}, "Methods":{ "Method":{ "Name":"POST", "Message Parameters":{ "id":{"Acceptable Values":"", "Default Value":"", "Type":"string", "Optional":"false"}, "enabled":{"Acceptable Values":"", "Default Value":"true", "Type":"boolean", "Optional":"true"}, "description":{"Acceptable Values":"", "Default Value":"", "Type":"string", "Optional":"true"}, "target":{"Acceptable Values":"", "Default Value":"", "Type":"string", "Optional":"true"}, "property":{"Acceptable Values":"", "Default Value":"", "Type":"string", "Optional":"true"}, "connectionpoolid":{"Acceptable Values":"", "Default Value":"", "Type":"string", "Optional":"false"} } }, "Method":{ "Name":"GET" } }, "Child Resources":[ "http://localhost:4848/management/domain/resources/jdbc-resource/ jdbc-__TimerPool", "http://localhost:4848/management/domain/resources/jdbc-resource/ jdbc-__default" ] |
Enterprise Server の REST インタフェースは次に示すように、作成、読み取り、更新、および削除 (CRUD) 以外の操作もサポートしています。
状態管理
クエリー
アプリケーション配備
これらの操作は、操作の実行対象リソースの子リソースを通じてサポートされます。子リソースは、構成オブジェクトツリーのノードを表しません。
たとえば、ドメイン管理用リソースは、次の表に示す CRUD 以外の操作用の子リソースを提供します。
表 2–2 ドメインでの CRUD 以外の操作用の子リソース
リソース |
アクション |
---|---|
host-port |
DAS が稼働中のホスト、および DAS が HTTP 要求を待機するポートを表示します。 |
restart |
ドメインの DAS を停止し、その後再起動します。 |
rotate-log |
タイムスタンプ名を持つファイルを server.log_date-and-time の形式の名前に変更し、空のログを作成することにより、サーバーログファイルをローテーションします。 |
stop |
ドメインの DAS を停止します。 |
uptime |
DAS の最後の再起動後の動作時間を表示します。 |
version |
Enterprise Server のバージョン情報を表示します。 |
Enterprise Server の REST インタフェースは、セキュアな接続上での基本認証をサポートしています。セキュリティーを有効にしたときには、REST リソースの URL にプロトコルとして https を指定し、ユーザー名とパスワードを指定する必要があります。
Enterprise Server の REST インタフェースのセキュリティー保護では、次のタスクシーケンスが実行されます。
admin-realm ユーザーを asadmin ユーザーグループに追加
Secure Sockets Layer (SSL) を有効化
コマンド行からこれらのタスクを実行する方法については、次に示すドキュメントを参照してください。
管理コンソール を使用してこれらのタスクを実行する方法については、管理コンソール のオンラインヘルプから次に示すトピックを参照してください。
管理レルムにユーザーを追加する
プロトコルの SSL 設定を編集する
Enterprise Server の REST インタフェースは、次に示す形式でリソースを表現します。
XML
HTML
リソースの表現を指定する方法は、Enterprise Server の REST インタフェースへのアクセス方法によって異なります。たとえば、cURL ユーティリティーを使用している場合は、オプション -H を使用して、次のようにリソースの表現を指定します。
JSON の場合は、-H "Accept: application/json" を指定します。
XML の場合は、-H "Accept: application/xml" を指定します。
HTML の場合は、オプション -H を省略します。
リソースの JSON 表現の一般的な形式は次のとおりです。
{ "resource":{attributes}, "Methods": { method-list } "Child Resources":[urls] }
この形式の置き換え可能な項目は次のとおりです。
リソース名。
コンマ (,) で区切られたゼロ以上の名前と値のペア。名前と値の各ペアは、"名前":値 として指定します。
リソースがサポートするメソッドを表現する、コンマ (,) で区切られた 1 つ以上のメタデータのセット。 各メタデータセットの形式については、「メソッドリストのメソッドの JSON 表現」を参照してください。
コンマ (,) で区切られたゼロ以上の子リソースの URL。
メソッドリストのメソッドの JSON 表現は、次のとおりです。
Method":{ "Name":"method-name", "Message Parameters":{ message-parameter-list } "Query Parameters":{ queryparameter- list } }
この形式の置き換え可能な項目は次のとおりです。
GET、POST、DELETE のいずれかのメソッド名。
メソッドで使用できるメッセージパラメータを表す、コンマ (,) で区切られたゼロ以上のメタデータのセット。各メタデータセットの形式については、「メッセージパラメータまたはクエリーパラメータの JSON 表現」.を参照してください。
メソッドで使用できるクエリーパラメータを表す、コンマ (,) で区切られたゼロ以上のメタデータのセット。各メタデータセットの形式については、「メッセージパラメータまたはクエリーパラメータの JSON 表現」.を参照してください。
メッセージパラメータまたはクエリーパラメータの JSON 表現は、次のとおりです。
"parameter-name":{attribute-list}
この形式の置き換え可能な項目は次のとおりです。
パラメータ名。
コンマで区切られた、パラメータの属性の名前と値のペアのリスト。各ペアの形式は次のとおりです。
"name":"value"
使用できる属性は次のとおりです。
この例は、ドメイン管理用リソースの JSON 表現を示します。この例では、DAS がローカルホストで稼働中で、管理用の HTTP ポートは 4848 です。この例のリソースの URL は、http://localhost:4848/management/domain です。
改行は読みやすくするためです。
{ "Domain":{"log-root":"${com.sun.aas.instanceRoot}/logs", "application-root":"${com.sun.aas.instanceRoot}/applications", "locale":"", "version":"73"}, "Methods":{ "Method":{ "Name":"POST", "Message Parameters":{ "log-root":{"Key":"false", "Type":"string", "Optional":"true"}, "application-root":{"Key":"false", "Type":"string", "Optional":"true"}, "locale":{"Key":"false", "Type":"string", "Optional":"true"}, "version":{"Key":"false", "Type":"string", "Optional":"true"} } }, "Method":{ "Name":"GET" } }, "Child Resources":[ "http://localhost:4848/management/domain/configs", "http://localhost:4848/management/domain/resources", "http://localhost:4848/management/domain/servers", "http://localhost:4848/management/domain/property", "http://localhost:4848/management/domain/applications", "http://localhost:4848/management/domain/system-applications", "http://localhost:4848/management/domain/stop", "http://localhost:4848/management/domain/restart", "http://localhost:4848/management/domain/uptime", "http://localhost:4848/management/domain/version", "http://localhost:4848/management/domain/rotate-log", "http://localhost:4848/management/domain/host-port" ] } |
リソースの XML 表現の一般的な形式は次のとおりです。
<resource attributes> <Methods> method-list </Methods> children </type>
この形式の置き換え可能な項目は次のとおりです。
リソース名。
空白文字 1 つで区切られたゼロ以上の名前と値のペア。名前と値の各ペアは名前="値"として指定します。
リソースがサポートするメソッドを表現する、1 つ以上の XML 要素。 各要素の形式については、「リソースメソッドの XML 表現」を参照してください。
子リソースの URL を指定するゼロ以上の XML 要素。各要素は、<child-resource> url</child-resource> として指定します。child-resource は子リソースの名前、url は子リソースの URL です。
メソッドリストのメソッドの XML 表現は、次のとおりです。
<Method name="method-name"> <Message-Parameters> message-parameter-list </Message-Parameters> <Query-Parameters> query-parameter-list </Query-Parameters> </Method>
この形式の置き換え可能な項目は次のとおりです。
GET、POST、DELETE のいずれかのメソッド名。
メソッドで使用できるメッセージパラメータを表す、改行で区切られたゼロ以上の XML 要素。各要素の形式については、「メッセージパラメータまたはクエリーパラメータの XML 表現」を参照してください。
メソッドで使用できるクエリーパラメータを表す、改行で区切られたゼロ以上の XML 要素。各要素の形式については、「メッセージパラメータまたはクエリーパラメータの XML 表現」を参照してください。
メッセージパラメータまたはクエリーパラメータの XML 表現は、次のとおりです。
<parameter-name attribute-list/>
この形式の置き換え可能な項目は次のとおりです。
パラメータ名。
空白文字で区切られた、パラメータの属性の名前と値のペアのリスト。各ペアの形式は次のとおりです。
name="value"
使用できる属性は次のとおりです。
この例は、ドメイン管理用リソースの XML 表現を示します。この例では、DAS がローカルホストで稼働中で、管理用の HTTP ポートは 4848 です。この例のリソースの URL は、http://localhost:4848/management/domain です。
改行は読みやすくするためです。
<Domain log-root="${com.sun.aas.instanceRoot}/logs" application-root="${com.sun.aas.instanceRoot}/applications" locale="" version="73"> <Methods> <Method name="POST"> <Message-Parameters> <log-root Key="false" Type="string" Optional="true"/> <application-root Key="false" Type="string" Optional="true"/> <locale Key="false" Type="string" Optional="true"/> <version Key="false" Type="string" Optional="true"/> </Message-Parameters> </Method> <Method name="GET"> </Method> </Methods> <Child-Resources> <Child-Resource>http://localhost:4848/management/domain/configs</Child-Resource> <Child-Resource>http://localhost:4848/management/domain/resources</Child-Resource> <Child-Resource>http://localhost:4848/management/domain/servers</Child-Resource> <Child-Resource>http://localhost:4848/management/domain/property</Child-Resource> <Child-Resource>http://localhost:4848/management/domain/applications</Child-Resource> <Child-Resource>http://localhost:4848/management/domain/system-applications</Child-Resource> <Child-Resource>http://localhost:4848/management/domain/stop</Child-Resource> <Child-Resource>http://localhost:4848/management/domain/restart</Child-Resource> <Child-Resource>http://localhost:4848/management/domain/uptime</Child-Resource> <Child-Resource>http://localhost:4848/management/domain/version</Child-Resource> <Child-Resource>http://localhost:4848/management/domain/rotate-log</Child-Resource> <Child-Resource>http://localhost:4848/management/domain/host-port</Child-Resource> </Child-Resources> </Domain> |
リソースの HTML 表現の形式は Web ページであり、リソースに関して次の情報を提供します。
リソースの属性とその値のリスト
リソースがサポートするメソッドおよびメソッドパラメータのリスト各メソッドとそのパラメータは、HTML フォーム内の適切な型を持つフィールドとして表示されます。
リソースの子を示すハイパーテキストリンクのリスト
Web ページの例については、図 2–1 を参照してください。この例では、DAS がローカルホストで稼働中で、管理用の HTTP ポートは 4848 です。この例のリソースの URL は、http://localhost:4848/management/domain です。
この章では、asadmin コマンド行ユーティリティーを使用して Sun GlassFishTM Enterprise Server v3 環境でドメインを管理する手順について説明します。
ここでは、以下のトピックに関して説明します。
本章で説明するタスクを 管理コンソール から実行する手順については、管理コンソール オンラインヘルプを参照してください。
ドメインは同時に管理されるインスタンスのグループです。ドメインは、事前に設定されたランタイムをユーザーアプリケーションに提供します。管理上の境界線を設けることに加え、ドメインは基本的なセキュリティー構造を提供し、これによって別々の管理者がサーバーインスタンスの特定のグループを管理できます。サーバーインスタンスを個別のドメインにグループ化することにより、さまざまな組織や管理者が 1 つの Enterprise Server インストールを共有できます。ドメインには、固有の構成、ログファイル、およびアプリケーションの配備領域があり、これらはほかのドメインとは無関係です。1 つのド メインの構成が変更されても、ほかのドメインの構成は影響を受けません。
Enterprise Server インストーラにより、デフォルトの管理ドメイン ( domain1という名前) が作成されます。さらに、関連するドメイン管理サーバー (DAS) (server という名前) も作成されます。DAS は管理者を認証し、管理ツールからの要求を受け付け、ドメイン内のサーバーインスタンスと通信して要求を実行するように特別に指定されたインスタンスです。DAS はデフォルトサーバーと呼ばれることもあります。デフォルトサーバーと呼ばれる理由は、Enterprise Server のインストール時に作成される唯一のサーバーインスタンスで、配備に使用できるからです。
。デフォルトの管理ポートは 4848 ですが、インストール中に別のポートを指定することもできます。ドメインが作成されると、管理ユーザー名とパスワードを入力するよう求められますが、ユーザー名が admin でパスワードがない場合は、デフォルトのままにすることもできます。管理者パスワードをリセットするには、「管理パスワードを変更する」を参照してください。
グラフィカルな 管理コンソール は、特定のDAS と通信し、その DAS と関連するドメインを管理します。管理コンソール の各セッションにより、特定のドメインを設定し、管理できます。ドメインを複数作成した場合は、別々に 管理コンソール セッションを起動して、それぞれのドメインを管理する必要があります。
ここでは、以下のトピックに関して説明します。
Enterprise Server をインストールしてデフォルトドメイン (domain1 ) を作成してからは、ローカルの create-domain サブコマンドを使用してさらにドメインが作成できるようになります。このサブコマンドは、ドメインの構成を作成します。所定のシステムの asadmin ユーティリティーに対してアクセス権を持つユーザーは、ドメインを作成し、自分の選択するフォルダにそのドメイン構成を格納することができます。デフォルトでは、ドメイン構成はドメインのデフォルトディレクトリに作成されます。この場所をオーバーライドして、別の場所に構成を格納することもできます。
ドメインを作成すると、管理ユーザーを指定するよう求められます。または、パスワードなしでユーザー名が admin のデフォルトログイン ID のままにしておくこともできます。
ドメインに適用するプロファイルを決定します。
作成中のドメイン名を選択します。
まだ使用されていないドメイン名かどうかを確認するには、list-domains(1) を使用します。
ドメインを作成するには、create-domain(1) サブコマンドを使用します。
このサブコマンドのオプションについては、このマニュアルページに記載されています。
ドメインの admin ユーザー名とパスワードを入力します。
admin ログインを設定しないようにするには、パスワードなしでデフォルトの admin のままにします。Return を押しても、デフォルトが選択されます。
この例では、domain1 というドメイン名を作成します。コマンドを入力すると、ログイン情報を入力するよう求められることがあります。
asadmin> create-domain --adminport 4848 domain1 Enter admin user name[Enter to accept default]> Using port 4848 for Admin. Default port 8080 for HTTP Instance is in use. Using 1161 Using default port 7676 for JMS. Using default port 3700 for IIOP. Using default port 8081 for HTTP_SSL. Using default port 3820 for IIOP_SSL. Using default port 3920 for IIOP_MUTUALAUTH. Default port 8686 for JMX_ADMIN is in use. Using 1162 Distinguished Name of the self-signed X.509 Server Certificate is: [CN=moonbeam.gateway.2wire.net,OU=GlassFish,O=Sun Microsystems,L=Santa Clara,ST California,C=US] Domain domain1 created. Command create-domain executed successfully. |
管理コンソール をブラウザで起動するには、次のフォーマットで URL を入力します。
http://hostname:5000 |
この例の場合、ドメインのログファイル、構成ファイル、および配備されたアプリケーションは次のディレクトリに置かれます。
domain-root-dir/mydomain
このサブコマンドの完全な構文を確認するには、コマンド行に asadmin help create-domain と 入力してください。
ドメインとそのステータスを一覧表示するには、list-domains サブコマンドを使用します。ドメインのディレクトリが指定されていない場合は、デフォルト as-install の /domains ディレクトリにあるコンテンツが表示されます。複数のドメインが存在する場合は、ドメイン名を指定する必要があります。
別のディレクトリに作成されているドメインを一覧表示するには、--domaindir オプションを指定します。
ドメインを一覧表示するには、list-domains(1) サブコマンドを使用します。
この例では、デフォルトの as-install/domains ディレクトリを一覧表示しています。
asadmin> list-domains Name: domain1 Status: Running Name: domain4 Status: Not Running Name: domain6 Status: Not Running Command list-domains executed successfully. |
このサブコマンドの完全な構文を確認するには、コマンド行に asadmin help list-domain と 入力してください。
どのリモートサブコマンドにも資格が必要で、管理ユーザー名とそのパスワードを指定しなくてはなりません。ID が明示的または暗黙的に何も指定されていない場合は、デフォルトでは asadmin ユーザーが管理者向け操作を実行できるような ID でドメインが作成されます。デフォルト ID は、ユーザー名が admin でパスワードがない形式です。コマンド行やプロンプトにユーザー名を指定せず、--passwordfile オプションまたはプロンプトにパスワードを何も指定せず、login サブコマンドまたは create-domain サブコマンドに ----savelogin オプションを付けたうちのいずれかでドメインにログインしたことがなければ、asadmin ユーティリティーが ID を何も指定せずに指定の管理操作を実行しようとします。サーバー (ドメイン) は、次の状況に当てはまる限り、このデフォルト ID を使用して管理操作を行えるようにします。
1. サーバー (ドメイン) が、admin ユーザーの認証にファイルレルムを使用している。
2. ファイルレルムに、ユーザーが 1 人しかいない (ユーザー名の内容は問わない)。
3. その 1 人のユーザーに、パスワードが用意されていない。
デフォルトでは、特定のユーザー名とパスワードでドメインを作成していない限り、これらの条件がすべて当てはまります。したがって、唯一の管理ユーザーは、パスワードなしの admin となります。3. に当てはまらない場合は、パスワードを指定する必要があります。2. に当てはまらない場合も、ユーザー名を指定する必要があります。1. に当てはまらない場合は、ユーザー名とパスワードを指定する必要があります。
特定ドメインへの認証 (ログイン) を行うには、ローカルモードで login サブコマンドを使用します。ログインした後は、そのドメインのそれ以降の操作に管理ユーザーやパスワードを指定しなくても済むようになります。login サブコマンドは、管理パスワードを指定する際にのみ使用できます。リモートサブコマンドから入力を求められるこれ以外のパスワードについては、--passwordfile オプションを使用するか、コマンドプロンプトでパスワードを指定してください。管理ユーザー名とパスワードの入力が常に求められます。
logout サブコマンドは一切ありません。別のドメインにログインするには、asadmin login の --host と --port に新しい値を付けて呼び出します。
ログインしようとしているドメイン名を指定します。
既存ドメインの一覧表示
asadmin list-domains |
login(1)コマンドでドメインにログインします。
この例では、別のマシンにあるドメインにログインします。login サブコマンドの前に、オプションを指定します。
asadmin> --host foo --port 8282 login Please enter the admin user name>admin Please enter the admin password> Trying to authenticate for administration of server at host [foo] and port [8282] ... Login information relevant to admin user name [admin] for host [foo] and admin port [8282] stored at [/.asadminpass] successfully. Make sure that this file remains protected. Information stored in this file will be used by asadmin commands to manage associated domain. |
この例では、デフォルトポートの myhost にあるドメインにログインします。login サブコマンドの前に、オプションを指定します。
asadmin> --host myhost login Please enter the admin user name>admin Please enter the admin password> Trying to authenticate for administration of server at host [myhost] and port [4848] ... An entry for login exists for host [myhost] and port [4848], probably from an earlier login operation. Do you want to overwrite this entry (y/n)?y Login information relevant to admin user name [admin] for host [myhost] and admin port [4848] stored at [/home/joe/.asadminpass] successfully. Make sure that this file remains protected. Information stored in this file will be used by asadmin commands to manage associated domain. |
このサブコマンドの完全な構文を確認するには、コマンド行に asadmin help login と 入力してください。パスワードの詳細は、「パスワードの管理」を参照してください。
サーバーから既存のドメインを削除するには、delete-domain サブコマンドを使用します。このサブコマンドを実行できるのは、このドメインを管理する権限があるルートユーザー、もしくはオペレーティングシステムのユーザーだけです。
削除する前に、ドメインがすでに停止している必要があります。
ドメインを一覧表示するには、list-domains(1) サブコマンドを使用します。
必要な場合は、削除しようとしているドメインのドメインユーザーに通知してください。
削除対象のドメインが停止していることを確認します。
必要な場合は、「ドメインの停止」を参照してください。
delete-domain(1) サブコマンドを使用して、ドメインを削除します。
この例では、domain1 という名前のドメインを指定の場所から削除します。
asadmin> delete-domain --domaindir ..\domains domain1 Domain domain1 deleted. Command delete-domain executed successfully. |
このサブコマンドの完全な構文を確認するには、コマンド行に asadmin help delete-domain と 入力してください。
ここでは、以下のトピックに関して説明します。
ドメインまたはサーバーの起動時に、ドメイン管理サーバー (DAS) が起動されます。DAS は、一度起動すると常時稼動となり、要求を待機して受け付けます。
ドメインのディレクトリが指定されていない場合は、デフォルトの as-install/domains ディレクトリにあるドメインが起動します。複数のドメインが存在する場合、domain_name オペランドを指定する必要があります。各ドメインは、別々に起動する必要があります。
起動しているドメインで restart-domain サブコマンドを使用できるようにするには、--watchdog オプションを true に設定してください (true がデフォルトです)。--watchdog オプションを false に設定しておくと、そのドメインで restart-domain サブコマンドが使用できません。
Microsoft Windows の場合、ドメインを起動するにはもう 1 つ方法があります。Windows の「スタート」メニューで、「プログラム」>「Sun Microsystems」>「Enterprise Server」>「デフォルトサーバーを起動」を選択します。
このサブコマンドは、ローカルモードでのみサポートされています。
ドメインを起動するには、start-domain(1) サブコマンドを使用します。
この例では、デフォルトドメインディレクトリ内の domain2 を起動します。
asadmin> start-domain domain2 |
ドメインが 1 つだけの場合は、ドメイン名を省略できます。パスワードを含めていない場合は、入力を求められることがあります。
Name of the domain started: [domain1] and its location: [C:\prelude\v3_prelude_release\distributions\web\target\glassfish domains\domain1]. Admin port for the domain: [4848]. |
このサブコマンドの完全な構文を確認するには、コマンド行に asadmin help start-domain と 入力してください。
ドメインまたはサーバーを停止すると、そのドメインの管理サーバー (DAS) がシャットダウンします。ドメインを停止すると、その DAS は新しい接続を受け付けなくなり、未完了の接続がすべて完了するまで待機します。このシャットダウンプロセスには数秒間かかります。ドメインの停止処理中は、管理コンソール およびほとんどの asadmin サブコマンドが使用できません。このサブコマンドは、異常なサーバーを停止する際に特に有用です。制御された状態では、restart-domain(1) サブコマンドも使用できます。
Microsoft Windows の場合、ドメインを停止するにはもう 1 つ方法があります。「スタート」メニューで、「プログラム」>「Sun Microsystems」>「Enterprise Server」>「デフォルトサーバー停止」を選択します。
必要な場合は、停止しようとしているドメインのユーザーに通知します。
stop-domain(1) サブコマンドを使用して、ドメインを停止します。
この例では、デフォルトディレクトリにある domain1 を停止します。ここで、domain1 はこのディレクトリに存在する唯一のドメインとします。
asadmin> stop-domain Waiting for the domain to stop ........... Command stop-domain executed successfully. |
このサブコマンドの完全な構文を確認するには、コマンド行に asadmin help stop-domain と 入力してください。
指定ホストのドメイン管理サーバー (DAS) を再起動するには、リモートモードで restart-domain サブコマンドを使用します。ドメインを再起動すると、その DAS は新しい接続を受け付けなくなり、未完了の接続がすべて完了するまで待機します。このシャットダウンプロセスには数秒間かかります。ドメインが再起動されるまで、管理コンソール およびほとんどの asadmin サブコマンドが使用できません。
このサブコマンドは、サーバーマシンがセキュリティー保護されていてアクセスしにくい環境で特に有用です。正当な資格がある状態であれば、そのサーバーをリモートからでも同一マシンからでも再起動できます。
サーバーが再起動しない場合は、stop-domain(1) サブコマンドの後に start-domain(1) サブコマンドを使用します。
restart-domain サブコマンドを成功させるには、ドメインを起動した時に start-domain サブコマンドの --watchdog オプションを (デフォルトの) true に設定しておく必要があります。このオプションが false に設定された状態でドメインを再起動しようとすると、ドメインが停止し警告メッセージのログが記録されます。--watchdog オプションを false に設定している場合、ドメインを再起動するには stop-domain および start-domain サブコマンドを使用するほかありません。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
restart-domain(1) サブコマンドを使用して、ドメインを再起動します。
この例では、デフォルトディレクトリにある mydoimain4 を再起動します。
asadmin> restart-domain mydomain4 Waiting for the domain to restart ........... Command restart-domain executed successfully. |
この例では、ブラウザで restart-domain サブコマンドを呼び出します。
http://yourhost:4848/__asadmin/restart-domain |
このサブコマンドの完全な構文を確認するには、コマンド行に asadmin help restart-domain と 入力してください。
ここでは、Solaris でドメインを自動的に再起動するようにシステムを設定する方法について説明します。
ここでは、以下のトピックに関して説明します。
create-service サブコマンドは、Solaris と Windows プラットフォームの両方でサポートされていますが、ここでは Solaris の手順のみ説明します。
Solaris 10 では、asadmin create-service サブコマンドを使用して、ドメイン管理サーバー (DAS) を再起動する Solaris Service Management Facility (SMF) サービスを作成できます。サービスはプロセスに、そのプロセスを実行するユーザーの特権を付与します。SMF サービスを作成する場合、デ フォルトのユーザーはスーパーユーザーです。別のユーザーがプロセスを実行する 必要がある場合は、method_credential にそのユーザーを指定します。
プロセスを Solaris 10 の特権ポートにバインドする場合、そのプロセスには net_privaddr 特権が必要です。Solaris オペレーティングシステム の特権ポートは、1024 より小さいポート番号です。
ユーザーが net_privaddr 特権を持っているかどうかを確認するには、そのユーザーとしてログインし、ppriv -l | grep net_privaddr コマンドを入力します。
SMF サービスを作成して有効にしたあと、ドメインが停止した場合は、SMF によって再起動されます。
asadmin create-service コマンドを実行するには、solaris.smf.* 認証が必要です。この認証の設定方法については、useradd および usermod のマニュアルページを参照してください。さらに次のディレクトリツリーでの書き込み権も必要です。 /var/svc/manifest/application/SUNWappserver。通常、スーパーユーザーはこれらの権限をどちらも持っています。また、svccfg、svcs、auths などの Solaris 10 管理コマンドが PATH で使用できなければなりません。
特定の Enterprise Server ドメインにデフォルトのユーザー特権を与えないようにする場合は、サービスのマニフェストを変更し、サービスを再インポートします。
create-service(1) サブコマンドを使用して、サービスを作成します。
このサブコマンドのプロパティーについては、このマニュアルページに記載されています。
サービスが作成されたら、svacdm enable コマンドを使用してサービスを有効にします。
次に例を示します。
svacdm enable /appserver/domains/domain1 |
この例では、サービスを作成します。
asadmin> create-service The Service was created successfully. Here are the details: Name of the service:application/GlassFish/domain1 Type of the service:Domain Configuration location of the service:/home/gfuser/glassfish-installations /glassfishv3/glassfish/domains Manifest file location on the system:/var/svc/manifest/application /GlassFish/domain1_home_gfuser_glassfish-installations_glassfishv3 _glassfish_domains/Domain-service-smf.xml. You have created the service but you need to start it yourself. Here are the most typical Solaris commands of interest: * /usr/bin/svcs -a | grep domain1 // status * /usr/sbin/svcadm enable domain1 // start * /usr/sbin/svcadm disable domain1 // stop * /usr/sbin/svccfg delete domain1 // uninstall Command create-service executed successfully |
サービスを管理するときに、次の Solaris コマンドが役に立ちます。 auths、smf_security、svcadm、 svccfg、rbac、useradd、および usermod。
Linux 上で再起動を設定するには、/etc/inittab を編集します。/etc/rc.local またはこれに相当するファイルを使用している場合は、/etc/rc.local に必要な asadmin サブコマンドを呼び出す行を追加します。
/etc/inittab ファイルにテキストを 1 行追加します。
次に例を示します。
das:3:respawn:/opt/SUNWappserver/bin/asadmin start-domain --user admin --passwordfile /opt/SUNWappserver/password.txt domain1 |
このテキストは 1 行で記述してください。先頭の 3 文字はこのプロセスに対する一意の指示子ですが、これは変更可能です。
デフォルトでは、Java Virtual Machine (JVM) は、Windows のシャットダウンまたはユーザーの Windows ログアウトが行われることを示すシグナルを Windows からキャッチし、Java VM 自身を完全にシャットダウンします。この動作により、Enterprise Server サービスがシャットダウンされます。ユーザーがログアウトするときにサービスがシャットダウンしないようにするには、-Xrs Java VM オプション を設定します。
as-install\domains\ domain-name\config\domain.xml ファイル内の、Java VM オプションを定義するセクションに次の行を追加します。
<jvm-options>-Xrs</jvm-options>
Enterprise Server サービスが稼働している場合、変更を有効にするには、そのサービスを再起動します。
ここでは、以下のトピックに関して説明します。
ドメイン管理サーバー (DAS) を最後に起動してから今まで稼動している期間を表示するには、リモートモードで uptime サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
uptime(1) サブコマンドで稼働時間を表示します。
この例では、DAS の稼働時間を表示します。
asadmin> uptime Uptime: 1 Weeks, 4 days, 0 hours, 17 minutes, 14 seconds, Total milliseconds: 951434595 Command uptime executed successfully. |
このサブコマンドの完全な構文を確認するには、コマンド行に asadmin help uptime と 入力してください。
Enterprise Server v3 には、JavaTM プラットフォーム (Java Virtual Machine すなわち JVMTM マシン) のベースとなる仮想マシンに Version 6 Java SE プラットフォームが必要です。
新しい JVM マシンでドメインを作成したあとは、以前の Java バージョンにはダウングレードしないでください。ご使用の JVM マシンをダウングレードする必要がある場合は、そのドメインの Java バージョンだけをダウングレードしてください。
まだダウングレードしていない場合は、目的の Java SDK (JRE ではありません) をダウンロードして、システムにインストールしてください。
Java SDK は、http://java.sun.com/j2se でダウンロードできます。
JDK を変更するドメインを起動します。
次のフォーマットを使用します。
as-install/bin/asadmin start-domain domain-name |
有効な JVM インストールの場合、次の順で場所がチェックされます。
有効な JDK が見つからない場合は、致命的エラーが発生し、その問題のレポートが返されます。
必要な場合は、ドメインの JVM マシン属性を変更します。
特に、JAVA_HOME 環境変数を変更する必要があります。JAVA_HOME 変数を変更するには、たとえば次のように入力します。
as-install/bin/asadmin set "server.java-config.java-home=path-to-java-home" |
この章では、asadmin コマンド行ユーティリティーを使用して、Sun GlassFishTM Enterprise Server v3 環境で JavaTM プラットフォームの仮想マシン (Java 仮想マシン、または JVMTM マシン) を管理する手順について説明します。
ここでは、次のテーマを取り上げます。
これらのタスクを 管理コンソール を使用して実行する場合の手順は、管理コンソール のオンラインヘルプで説明します。
Java 仮想マシンは、コンパイルされた Java プログラムのバイトコードを実行するための、インタプリタ型の処理エンジンです。仮想マシンは Java バイトコードをホストマシンのネイティブ命令に変換します。Java プロセスの 1 つである Enterprise Server は、Java アプリケーションの実行とサポートに仮想マシンを必要とします。JVM の設定は、Enterprise Server の構成の一部です。
ここでは、次のテーマを取り上げます。
Java 構成または domain.xml ファイルのプロファイラ要素に JVM オプションを作成するには、リモートモードで create-jvm-options サブコマンドを使用します。プロファイラ用に作成された JVM オプションは、プロファイラを開始する設定を記録するために使用されます。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
create-jvm-options(1) サブコマンドを使用して、JVM オプションを作成します。
複数の JVM オプションを作成する場合は、コロン (:) を使用してオプションを区切ります。JVM オプション自体にコロン (:) が含まれている場合は、バックスラッシュ (\) を使用して区切り記号のコロンと区別します。
このサブコマンドのプロパティーについては、このマニュアルページに記載されています。
変更内容を適用するために、Enterprise Server を再起動します。「ドメインの再起動」を参照してください。
この例では、複数の Java システムプロパティーを設定します。
asadmin> create-jvm-options -Dunixlocation=/root/example: -Dvariable=\$HOME: -Dwindowslocation=d\\:\\\sun\\\appserver: -Doption1=-value1 created 4 option(s) Command create-jvm-options executed successfully. |
コマンド行に asadmin help create-jvm-options と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
既存の JVM オプションを一覧表示するには、リモートモードで list-jvm-options サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-jvm-options(1) サブコマンドを使用して、JVM オプションを一覧表示します。
この例では、すべての JVM オプションを表示します。
asadmin> list-jvm-options -Djava.security.auth.login.config=${com.sun.aas.instanceRoot}/config/login.conf -XX: LogVMOutput -XX: UnlockDiagnosticVMOptions -Dcom.sun.enterprise.config.config_environment_factory_class=com.sun.enterprise. config.serverbeans.AppserverConfigEnvironmentFactory -Djavax.net.ssl.keyStore=${com.sun.aas.instanceRoot}/config/keystore.jks -XX:NewRatio=2 -Djava.security.policy=${com.sun.aas.instanceRoot}/config/server.policy -Djdbc.drivers=org.apache.derby.jdbc.ClientDriver -Djavax.net.ssl.trustStore=${com.sun.aas.instanceRoot}/config/cacerts.jks -client -Djava.ext.dirs=${com.sun.aas.javaRoot}/lib/ext${path.separator}${com.sun.aas.ja vaRoot}/jre/lib/ext${path.separator}${com.sun.aas.instanceRoot}/lib/ext${path.se parator}${com.sun.aas.derbyRoot}/lib -Xmx512m -XX:LogFile=${com.sun.aas.instanceRoot}/logs/jvm.log -Djava.endorsed.dirs=${com.sun.aas.installRoot}/lib/endorsed Command list-jvm-options executed successfully. |
コマンド行に asadmin help list-jvm-options と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
Java 構成または domain.xml ファイルのプロファイラ要素から JVM オプションを削除するには、リモートモードで delete-jvm-options サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-jvm-options(1) サブコマンドを使用して、JVM オプションを一覧表示します。
必要に応じて、JVM オプションを削除することをユーザーに通知します。
delete-jvm-options(1) サブコマンドを使用して、JVM オプションを削除します。
複数の JVM オプションを削除する場合は、コロン (:) を使用してオプションを区切ります。JVM オプション自体にコロンが含まれている場合は、バックスラッシュ (\) を使用して区切り記号のコロンと区別します。
変更内容を適用するために、Enterprise Server を再起動します。「ドメインの再起動」を参照してください。
この例では、1 つの JVM オプションを削除します。
asadmin> delete-jvm-options -Dopt1=A deleted 1 option(s) Command delete-jvm-options executed successfully. |
この例では、複数の JVM オプションを削除します。
asadmin> delete-jvm-options -Doption1=-value1:-Dvariable=\$HOME deleted 2 option(s) Command delete-jvm-options executed successfully. |
コマンド行に asadmin help delete-jvm-options と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
指定したドメイン管理サーバー (DAS) のスレッド (スタックトレースのダンプ)、クラス、メモリー、およびロガーを示す JVM レポートを生成するには、リモートモードで generate-jvm-report サブコマンドを使用します。生成できるレポートのタイプは、概要 (デフォルト)、クラス、スレッド、およびログです。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
generate-jvm-report(1) サブコマンドを使用して、レポートを生成します。
この例では、スレッド、クラス、およびメモリーの概要情報を表示します。
asadmin> generate-jvm-report --type summary Operating System Information: Name of the Operating System: Windows XP Binary Architecture name of the Operating System: x86, Version: 5.1 Number of processors available on the Operating System: 2 System load on the available processors for the last minute: NOT_AVAILABLE. (Sum of running and queued runnable entities per minute). . , . user.home = C:\Documents and Settings\Jennifer user.language = en user.name = Jennifer user.timezone = America/New_York user.variant = variable = \$HOME web.home = C:\Preview\v3_Preview_release\distributions\web\target\ glassfish\modules\web Command generate-jvm-report executed successfully. |
コマンド行に asadmin help generate-jvm-report と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
「プロファイラ」は、サーバーパフォーマンスの解析に使用される情報を生成します。ここでは、次のテーマを取り上げます。
サーバーインスタンスは、Java 構成内のプロファイラ要素によって、特定のプロファイラと連動しています。プロファイラ用に作成された JVM オプションは、特定のプロファイラの有効化に必要な設定を記録するために使用されます。Java 構成にプロファイラ要素を作成するには、リモートモードで create-profiler サブコマンドを使用します。
存在できるプロファイラは 1 つだけです。すでにプロファイラが存在している場合はエラーメッセージが表示され、新しいプロファイラを作成する前に古いプロファイラを削除するように指示されます。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
create-profiler(1) サブコマンドを使用して、プロファイラを作成します。
このサブコマンドのプロパティーについては、このマニュアルページに記載されています。
変更内容を適用するために、Enterprise Server を再起動します。
「ドメインの再起動」を参照してください。
この例では、sample_profiler という名前のプロファイラを作成します。
asadmin> create-profiler --classpath=/home/appserver/ --nativelibrarypath=/u/home/lib --enabled=false --property=defaultuser=admin:password=adminadmin sample_profiler Command create-profiler executed successfully. |
コマンド行に asadmin help create-profiler と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
Java 構成からプロファイラ要素を削除するには、リモートモードで delete-profiler サブコマンドを使用します。削除のあと、新しいプロファイラを作成できます。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
delete-profiler(1) サブコマンドを使用して、プロファイラを削除します。
変更内容を適用するために、Enterprise Server を再起動します。
「ドメインの再起動」を参照してください。
この例では、sample_profiler という名前のプロファイラを削除します。
asadmin> delete-profiler sample_profiler Command delete-profiler executed successfully. |
コマンド行に asadmin help delete-profiler と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
この章では、asadmin コマンド行ユーティリティーを使用して、Sun GlassFishTM Enterprise Server v3 環境でスレッドプールを管理する手順について説明します。
ここでは、次のテーマを取り上げます。
これらのタスクを 管理コンソール を使用して実行する場合の手順は、管理コンソール のオンラインヘルプで説明します。
JavaTM プラットフォームの仮想マシン (Java 仮想マシン、または JVMTM マシン) は、多数の実行スレッドを同時にサポートすることができます。パフォーマンスの向上に役立つように、Enterprise Server は 1 つまたは複数のスレッドプールを維持します。特定のスレッドプールを、コネクタモジュール、ネットワークリスナー、または ORB (Object Request Broker) に割り当てることができます。
1 つのスレッドプールで、複数のコネクタモジュールおよびエンタープライズ Bean を処理できます。「要求スレッド」は、アプリケーションコンポーネントへのユーザーの要求を処理します。Enterprise Server は要求を受け取ると、その要求をスレッドプール内の使用可能なスレッドに割り当てます。スレッドはクライアントの要求を実行し、結果を返します。たとえば、現在ビジー状態のシステムリソースが必要な場合、スレッドはリソースが解放されるのを待ってから、リソースの使用を要求に許可します。
アプリケーションからの要求用に確保するスレッドの最小数と最大数を指定できます。スレッドプールはこれら 2 つの値の間で動的に調整されます。
ここでは、次のテーマを取り上げます。
スレッドプールを作成するには、リモートモードで create-threadpool サブコマンドを使用します。
サーバーは、指定された最小スレッドプールサイズに従って、アプリケーション要求用に確保するスレッドを割り当てます。その数は、指定された最大スレッドプールサイズまで増加できます。プロセスで使用可能なスレッドの数を増やすと、プロセスが同時に応答できるアプリケーション要求数が多くなります。
1 つのリソースアダプタまたはアプリケーションが Enterprise Server のすべてのスレッドを占有すると、スレッド不足が発生します。この状況は、Enterprise Server のスレッドを複数のスレッドプールに分割することで回避できます。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
create-threadpool(1) サブコマンドを使用して、新しいスレッドプールを作成します。
サブコマンドのオプションについては、このサブコマンドのマニュアルページを参照してください。
変更内容を適用するために、Enterprise Server を再起動します。
「ドメインの再起動」を参照してください。
Web コンテナによって使用されるスレッドプールでは、再起動が必要ない場合もあります。
この例では、threadpool-l を作成します。
asadmin> create-threadpool --maxthreadpoolsize 100 --minthreadpoolsize 20 --idletimeout 2 --workqueues 100 threadpool-1 Command create-threadpool executed successfully |
コマンド行に asadmin help create-threadpool と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
既存のスレッドプールを一覧表示するには、リモートモードで list-threadpools サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-threadpools(1) サブコマンドを使用して、既存のスレッドプールを一覧表示します。
この例では、既存のスレッドプールを一覧表示します。
asadmin> list-threadpools threadpool-1 Command list-threadpools executed successfully |
コマンド行に asadmin help list-threadpools と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
set サブコマンドを使用して、指定したスレッドプールの値を更新します。
list-threadpools(1) サブコマンドを使用して、既存のスレッドプールを一覧表示します。
set(1) サブコマンドを使用して、スレッドプールの値を変更します。
スレッドプールはドット表記名で識別されます。
変更内容を適用するために、Enterprise Server を再起動します。
「ドメインの再起動」を参照してください。
Web コンテナによって使用されるスレッドプールでは、再起動が必要ない場合もあります。
この例では、max-thread-pool-size を元の値から 8 に変更します。
asadmin> set server.thread-pools.thread-pool.http-thread-pool.max-thread-pool-size=8 Command set executed successfully |
コマンド行に asadmin help set と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
既存のスレッドプールを削除するには、リモートモードで delete-threadpool サブコマンドを使用します。スレッドプールがネットワークリスナーによって参照されている場合、そのプールの削除は失敗します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-threadpools(1) サブコマンドを使用して、既存のスレッドプールを一覧表示します。
delete-threadpool(1) サブコマンドを使用して、指定したスレッドプールを削除します。
変更内容を適用するために、Enterprise Server を再起動します。
「ドメインの再起動」を参照してください。
Web コンテナによって使用されるスレッドプールでは、再起動が必要ない場合もあります。
この例では、threadpool-1 を削除します。
asadmin> delete-threadpool threadpool-1 Command delete-threadpool executed successfully |
コマンド行に asadmin help delete-threadpool と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
この章では、Sun GlassFishTM Enterprise Server v3 環境で Web アプリケーションを管理する方法について説明します。
ここでは、次のテーマを取り上げます。
これらのタスクの一部を 管理コンソール を使用して実行する場合の手順は、管理コンソール のオンラインヘルプで説明します。
Enterprise Server に配備されたサーブレットは、ブラウザに URL を指定して呼び出すことができます。また、HTML ファイルや JSP ファイル内にリンクとして埋め込まれたサーブレットも呼び出すことができます。サーブレットの呼び出し URL の形式は次のとおりです。
http://server:port/context-root/servlet-mapping?name=value表 6–1 アプリケーション内のサーブレットを呼び出す URL のフィールド
この例では、localhost はホスト名、MortPages はコンテキストルート、および calcMortgage はサーブレットマッピングを表します。
http://localhost:8080/MortPages/calcMortgage?rate=8.0&per=360&bal=180000
JSP ファイル内でサーブレットを呼び出す場合は、相対パスを使用できます。次に例を示します。
<jsp:forward page="TestServlet"/><jsp:include page="TestServlet"/>
ServletContext.log のメッセージは、サーバーログに送信されます。デフォルトでは、サーブレットの System.out および System.err 出力はサーバーログに送信されます。起動中に、サーバーログのメッセージは System.err 出力にエコーされます。またデフォルトでは、System.err 出力用の Windows 専用コンソールはありません。
これらのデフォルト設定は、管理コンソール の「システムログに書き込み」ボックスを使用して変更できます。このボックスにチェックマークを付けると、System.out 出力がサーバーログに送信されます。チェックマークを外すと、System.out 出力はシステムのデフォルトの場所だけに送信されます。
default-web.xml ファイルを使用して、フィルタやセキュリティー制約などの、すべての Web アプリケーションに適用される機能を定義できます。
たとえば、ディレクトリの一覧表示は、セキュリティーの強化のためにデフォルトで無効化されます。ドメインの default-web.xml ファイルでディレクトリの一覧表示を有効にするには、servlet-name が default であるサーブレットの定義を検索し、listings という名前の init-param を true に設定します。続いて、サーバーを再起動します。
<init-param> <param-name>listings</param-name> <param-value>true</param-value> </init-param>
listings を true に設定した場合、ディレクトリの一覧表示をソートする方法も決定できます。sortedBy という名前の init-param の値を、NAME、SIZE、または LAST_MODIFIED に設定します。続いて、サーバーを再起動します。
<init-param> <param-name>sortedBy</param-name> <param-value>LAST_MODIFIED</param-value> </init-param>
default-web.xml ファイルの mime-mapping 要素はグローバルで、すべての Web アプリケーションで継承されます。Web アプリケーションの web.xml ファイルで mime-mapping 要素を使用して、これらのマッピングを上書きするか、独自に定義することができます。mime-mapping 要素の詳細は、Servlet 仕様を参照してください。
default-web.xml ファイルは、管理コンソール を使用して編集するか、次の手順で直接編集することができます。
フィルタ、セキュリティー制約、またはその他の機能の JAR ファイルを、domain-dir/lib ディレクトリに配置します。
配置した JAR ファイルを参照するように、domain-dir/config/default-web.xml ファイルを編集します。
変更内容を適用するために、Enterprise Server を再起動します。
「ドメインの再起動」を参照してください。
古い URL に対する要求を、新しい URL に対する要求として処理するように指定できます。この処理は、URL の「リダイレクト」と呼ばれます。
仮想サーバーのリダイレクトされる URL を指定するには、redirect_ n プロパティーを使用します。n は正の整数で、複数の指定が可能です。各 redirect_n プロパティーは、仮想サーバーに配備されたすべての Web アプリケーションによって継承されます。
redirect_n プロパティーの値には 2 つの構成要素があり、任意の順番で指定できます。
最初の構成要素の from は、照合する要求された URI のプレフィックスを指定します。
2 番目の構成要素の url-prefix はクライアントに返す新しい URL プレフィックスを指定します。 from プレフィックスは、この URL プレフィックスで置き換えられます。
この例では、from に指定した dummy を etude にリダイレクトします。
<property name="redirect_1" value="from=/dummy url-prefix=http://etude"/>
mod_jk コネクタを使用すると、Web コンテナを Apache HTTP Server などの Web サーバーに接続できます。mod_jk は Enterprise Server に付属するコネクタで、これを使用することにより、Enterprise Server の前に Apach HTTP Server をたてることができます。この処理の一般的な目的は、静的なリソースに対する要求を Apache HTTP Server に処理させ、サーブレットや JavaServerTM Pages (JSP) などの動的なリソースに対する要求を、Enterprise Server のバックエンドインスタンスに転送して処理することです。
負荷分散の目的で、mod_jk を JSP またはサーブレットエンジンで直接使用することもできます。
ここでは、次のテーマを取り上げます。
ここで説明するように mod_jk コネクタを有効化することで、Enterprise Server と Apache HTTP Server を連携させることができます。ネットワークリスナーの jk-enabled 属性を使用する場合、追加の JAR ファイルを /lib ディレクトリにコピーする必要はありません。ネットワークリスナー属性の jk-enabled を使用することで、JK コネクタを別の仮想サーバーに作成することもできます。
Apache HTTP Server と mod_jk をインストールします。
Apache HTTP Server のインストール方法については、http://httpd.apache.org/docs/2.0/install.html を参照してください。
mod_jk のインストール方法については、http://tomcat.apache.org/connectors-doc/webserver_howto/apache.html を参照してください。
次のファイルを設定します。
apache2/conf/httpd.conf (Apache の主要な構成ファイル)
apache2/config/workers.properties または domain-dir /config/glassfish-jk.properties (http://tomcat.apache.org/tomcat-5.5-doc/config/ajp.html で説明されている属性のデフォルト以外の値を使用する場合)
worker.properties ファイルと glassfish-jk.properties ファイルの両方を使用する場合は、httpd.conf で参照されている (または、httpd.conf で最初に参照される) ファイルが優先されます。
Apache HTTP Server (httpd) を起動します。
Web アプリケーションが少なくとも 1 つ配備されている Enterprise Server を起動します。
配備済み Web アプリケーションを少なくとも 1 つ使用する Web コンテナが起動されていなければ、mod_jk コネクタは起動できません。
次のコマンドを実行して、HTTP リスナーを作成します。
asadmin> create-http-listener --listenerport 8009 --listeneraddress 0.0.0.0 --defaultvs server listener-name |
asadmin> set server-config.network-config.network-listeners. network-listener.listener-name.jk-enabled=true |
listener-name は、mod_jk を有効にするネットワークリスナーの ID です。
glassfish-jk.properties ファイルを使用していて、httpd.conf でこのファイルを参照していない場合は、次のコマンドを実行してファイルの場所を指定します。
asadmin> create-jvm-options -Dcom.sun.enterprise.web.connector.enableJK.propertyFile= domain-dir/config/glassfish-jk.properties |
変更内容を適用するために、Enterprise Server を再起動します。
「ドメインの再起動」を参照してください。
この例では、httpd.conf ファイルを示します。
LoadModule jk_module /usr/lib/httpd/modules/mod_jk.so JkWorkersFile /etc/httpd/conf/worker.properties # Where to put jk logs JkLogFile /var/log/httpd/mod_jk.log # Set the jk log level [debug/error/info] JkLogLevel debug # Select the log format JkLogStampFormat "[%a %b %d %H:%M:%S %Y] " # JkOptions indicate to send SSL KEY SIZE, JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories # JkRequestLogFormat set the request format JkRequestLogFormat "%w %V %T" # Send all jsp requests to GlassFish JkMount /*.jsp worker1 # Send all glassfish-test requests to GlassFish JkMount /glassfish-test/* worker1
この例では、worker.properties または glassfish-jk.properties ファイルを示します。
# Define 1 real worker using ajp13 worker.list=worker1 # Set properties for worker1 (ajp13) worker.worker1.type=ajp13 worker.worker1.host=localhost worker.worker1.port=8009
Apache の詳細は、http://httpd.apache.org/ を参照してください。
負荷分散は、1 台のコンピュータで実行しなければならない作業を複数のコンピュータに分配し、同じ時間でより多くの作業を行う処理です。
「mod_jk を有効にする」の手順を実行します。
少なくとも 1 つの Web アプリケーションが配備されている、別の Enterprise Server を起動します。
配備済み Web アプリケーションを少なくとも 1 つ使用する Web コンテナが起動されていなければ、mod_jk コネクタは起動できません。
次のようなコマンドを実行して、HTTP リスナーを作成します。
asadmin> create-http-listener --listenerport 8010 --listeneraddress 0.0.0.0 --defaultvs server my-connector |
複数のインスタンスが同じマシンで動作している場合は、別の JK ポートを選択する必要があります。ポートは worker.properties ファイルの worker.worker*.port に一致する必要があります。以下のプロパティーファイルの例を参照してください。
次のコマンドを実行して、mod_jk を有効にします。
asadmin> set server-config.network-config.network-listeners. network-listener.listener-name.jk-enabled=true |
listener-name は、mod_jk を有効にするネットワークリスナーの ID です。
変更を適用するには、Apache と Enterprise Server を再起動します。
「ドメインの再起動」を参照してください。
この例では、httpd.conf ファイルを示します。
LoadModule jk_module /usr/lib/httpd/modules/mod_jk.so JkWorkersFile /etc/httpd/conf/worker.properties # Where to put jk logs JkLogFile /var/log/httpd/mod_jk.log # Set the jk log level [debug/error/info] JkLogLevel debug # Select the log format JkLogStampFormat "[%a %b %d %H:%M:%S %Y] " # JkOptions indicate to send SSL KEY SIZE, JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories # JkRequestLogFormat set the request format JkRequestLogFormat "%w %V %T" # Send all jsp requests to GlassFish JkMount /*.jsp worker1 # Send all glassfish-test requests to GlassFish JkMount /glassfish-test/* loadbalancer |
この例では、worker.properties または glassfish-jk.properties ファイルを示します。worker.worker*.port は、作成した JK ポートに一致している必要があります。
worker.list=loadbalancer worker.worker1.type=ajp13 worker.worker1.host=localhost worker.worker1.port=8009 worker.worker1.lbfactor=1 worker.worker1.socket_keepalive=1 worker.worker1.socket_timeout=300 worker.worker2.type=ajp13 worker.worker2.host=localhost worker.worker2.port=8010 worker.worker2.lbfactor=1 worker.worker2.socket_keepalive=1 worker.worker2.socket_timeout=300 worker.loadbalancer.type=lb worker.loadbalancer.balance_workers=worker1,worker2 |
この章では、Sun GlassFishTM Enterprise Server v3 環境で、ロギングを設定する手順とログ情報を表示する手順について説明します。
ここでは、次のテーマを取り上げます。
これらのタスクの実行とプロパティーの編集を 管理コンソール を使用して行う場合の手順は、管理コンソール のオンラインヘルプで説明します。
「ロギング」は、構成エラー、セキュリティー障害、サーバーの不完全な動作といったサーバーの動作中に発生したイベントに関する情報を、Enterprise Server が取得するための処理です。このデータはログファイルに記録され、通常は問題が発生したときの主要な情報源となります。ログファイルの解析は、サーバーの健全性を判断する際に役立ちます。
アプリケーションコンポーネントでは Apache Commons Logging Library を使用してメッセージを記録することもできますが、より適切なログ構成を行うには、プラットフォーム標準の JSR 047 API をお勧めします。
ここでは、次のテーマを取り上げます。
Enterprise Server のログレコードはサーバーログに記録されます。デフォルトのサーバーログの名前は server.log で、通常は domain-dir/logs に保存されます。サーバーログのデフォルトの名前または場所は、管理コンソール を使用して変更できます。
サーバーログのほかに、domain-dir/logs ディレクトリには次のログも保存されます。
HTTP サービスアクセスログ (/access サブディレクトリ)
トランザクションサービスログ (/tx サブディレクトリ)
サーバーログのサイズが指定された値 (バイト単位) に達すると、ログはローテーションされ、タイムスタンプを付加した server.log_ date という名前に変更されます。date は、ファイルがローテーションされた日時を表します。ログファイルのローテーションは、「サーバーログのローテーション」の手順に従って手動で行うこともできます。
Enterprise Server のログレコードは、次の統一形式に従います。
|
[#|yyyy-mm-ddThh:mm:ss.SSS-Z|Log Level|ProductName-Version|LoggerName|Key Value Pairs|Message|#] |
[# と #] はレコードの開始と終了をマーク付けします。
垂直線 (|) は、レコードのフィールドを区切ります。
yyyy-mm-ddThh:mm:ss.SSSS-Z は、レコードが作成された日時を表します。たとえば、2006-10-21T13:25:53.852-0400 です。
Log Level は、指定したログレベルを表します。ログレベルには、SEVERE、WARNING、INFO、CONFIG、FINE、FINER、および FINEST のいずれかの値を選択できます。デフォルトは、「INFO」です。
ProductName-Version は、Enterprise Server の現在のバージョンを表します。たとえば、glassfish です。
LoggerName は、ログモジュールのソースを識別する階層ロガーの名前空間です。たとえば、javax.enterprise.system.core です。
Key Value Pairs は、キーの名前と値のペア (通常はスレッド ID) を表します。たとえば、_ThreadID=14; です。
Message は、ログメッセージのテキストです。Enterprise Server のすべての SEVERE および WARNING のメッセージと、多くの INFO メッセージは、モジュールコードと数値で構成されるメッセージ ID で始まります。たとえば、CORE5004 です。
ログレコードの例を次に示します。
[#|2006-10-21T13:25:53.852-0400|INFO|GlassFish10.0|javax.enterprise. system.core|_ThreadID=13;|CORE5004: Resource Deployed: [cr:jms/DurableConnectionFactory].|#]
管理コンソール では、ログレコードがわかりやすい形式で表示されます。
list-logger-levels(1) サブコマンドを使用して、モジュールの既存のロガーを一覧表示できます。次に例を示します。
javax.enterprise.system.container.cmp: INFO javax.enterprise.system.tools.admin: INFO javax.enterprise.system.container.web: INFO javax.enterprise.system.util: INFO javax.enterprise.resource.webcontainer.jsf.timing: INFO javax: INFO javax.enterprise.resource.corba: INFO javax.enterprise.system.core.naming: INFO javax.enterprise.system.core.selfmanagement: INFO javax.enterprise.system.container.ejb: INFO javax.enterprise.resource.webcontainer.jsf.config: INFO javax.enterprise.resource.javamail: INFO org.apache.catalina: INFO javax.enterprise.system.core.config: INFO javax.enterprise.system.webservices.rpc: INFO javax.enterprise.system.webservices.registry: INFO javax.enterprise.system.tools.deployment: INFO javax.enterprise.resource.jms: INFO javax.enterprise.system: INFO javax.enterprise.system.webservices.saaj: INFO org.apache.jasper: INFO javax.enterprise.resource.webcontainer.jsf.lifecycle: INFO javax.enterprise.resource.jta: INFO javax.enterprise.resource.jdo: INFO javax.enterprise.resource.resourceadapter: INFO javax.enterprise.system.core.transaction: INFO javax.enterprise.resource.webcontainer.jsf.resource: INFO javax.enterprise.system.core.security: INFO javax.enterprise.resource.webcontainer.jsf.application: INFO javax.enterprise.system.core.classloading: INFO org.apache.coyote: INFO javax.enterprise.resource.webcontainer.jsf.managedbean: INFO javax.enterprise.system.container.ejb.mdb: INFO javax.enterprise.resource.webcontainer.jsf.context: INFO javax.enterprise.resource.webcontainer.jsf.renderkit: INFO javax.enterprise.resource.webcontainer.jsf.facelets: INFO javax.enterprise.resource.webcontainer.jsf.taglib: INFO |
「ログレベル」は、ログに記録するメッセージの粒度を決定します。ここには、エラーのみ (SEVERE) から詳細なデバッグ情報 (FINEST) までのいずれかを指定します。選択できる値は、SEVERE、WARNING、INFO、CONFIG、FINE、FINER、および FINEST です。各ログレベルは上位のレベルを含みます。つまり、特定のログレベル (たとえば、INFO) を設定した場合、これより上位のログレベル (SEVERE および WARNING) のメッセージも記録されます。もっとも低いログレベル (FINEST) に設定した場合、出力にはファイルのすべてのメッセージが含まれます。デフォルト設定は、INFO です。
ログレベルの設定には、グローバル設定とロガー固有の設定の 2 つを利用できます。ロガー固有の設定を選択し、この設定がグローバル設定と異なる場合は、ロガー固有の設定が優先されます。
グローバルログレベルを設定するには、logging.properties ファイルを編集します。モジュールごとのログレベルは、この節で説明するように asadmin サブコマンドを使用して設定します。
ログレベルの設定は動的な処理であるため、変更を有効にするために Enterprise Server を再起動する必要はありません。
ここでは、次のテーマを取り上げます。
モジュールと各モジュールの現在のログレベルを一覧表示するには、リモートモードで list-logger-levels サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-logger-levels(1) サブコマンドを使用して、既存のモジュールのロガーを一覧表示します。
この例では、既存のロガーの一部と、各ロガーで設定されているログレベルを一覧表示します。
asadmin> list-logger-levels javax.enterprise.system.container.cmp: INFO javax.enterprise.system.tools.admin: INFO java.util.logging.ConsoleHandler: FINEST javax.enterprise.system.container.web: INFO javax.enterprise.system.util: INFO javax.enterprise.resource.webcontainer.jsf.timing: INFO javax: INFO javax.enterprise.resource.corba: INFO ... Command list-logger-levels executed successfully. |
コマンド行に asadmin help list-logger-levels と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
「グローバルログレベル」は、すべてのロガーで記録されるイベントの種類を指定します。コンソールへのメッセージ出力のデフォルトレベルは INFO です。このレベルには、SEVERE と WARNING のメッセージも含まれます。
グローバルロギングは、logging.properties ファイルを編集して設定します。デフォルトの logging.properties ファイルは、domain.xml ファイルと同じディレクトリにあり、通常は domain-dir/config に保存されています。java.util.logging.config.file システムプロパティーにファイル名を指定して、別のファイルを選択することもできます。たとえば、次のように指定します。
java -Djava.util.logging.config.file=myfile |
ConsoleHandler には、表示されるメッセージを制限する独立したログレベル設定があります。次に例を示します。
java.util.logging.ConsoleHandler.level = INFO java.util.logging.ConsoleHandler.formatter = com.sun.enterprise.server.logging.UniformLogFormatter |
ログレベルをルートレベルで設定すると、すべてのロガーのレベルを設定できます。この例では、すべてのロガーのログレベルを INFO に設定します。
.level= INFO
「モジュールログレベル」は、特定のロガーで記録するイベントの種類を指定します。コンソールへのメッセージ出力のデフォルトレベルは INFO です。このレベルには、SEVERE と WARNING のメッセージも含まれます。グローバルログレベルは、モジュールに固有のログレベルで上書きされます。
デフォルトでは、モジュールログレベルは FINE に設定されます。ロガーを設定する行は次のようになります。太字はモジュールを示しています。
#javax.enterprise.system.tools.level=FINE #javax.enterprise.system.container.ejb.level=FINE #javax.enterprise.system.core.security.level=FINE #javax.enterprise.system.tools.admin.level=FINE #javax.enterprise.level=FINE #javax.enterprise.system.container.web.level=FINE |
ログレベルの設定は動的な処理であるため、変更を有効にするために Enterprise Server を再起動する必要はありません。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-logger-levels(1) サブコマンドを使用して、既存のモジュールのロガーを一覧表示します。
set-log-level(1) サブコマンドを使用して、モジュールのログレベルを設定します。
選択できる値は、SEVERE、WARNING、INFO、CONFIG、FINE、FINER、および FINEST です。
この例では、Web コンテナロガーのログレベルを FINE に設定します。
asadmin> set-log-level javax.enterprise.system.container.web.level=FINE Command set-log-level executed successfully. |
この例では、セキュリティーロガーと Web コンテナロガーのログレベルを設定します。
asadmin> set-log-level javax.enterprise.system.core.security.level=FINE javax.enterprise.system.container.web=WARNING Command set-log-level executed successfully. |
コマンド行に asadmin help set-log-level と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
ログは logging.properties ファイルの設定に従って自動的にローテーションされます。これらの設定は 管理コンソール を使用して変更できます。
サーバーログファイルを手動でローテーションするには、リモートモードで rotate-log サブコマンドを使用します。デフォルトの場所にあるサーバーログは、ただちにタイムスタンプ付きの名前に変更され、新しいサーバーログが作成されます。
ログのローテーションは動的な処理であるため、変更を有効にするために Enterprise Server を再起動する必要はありません。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
rotate-log(1) サブコマンドを使用して、ログをローテーションします。
この例では、server.log ファイルの名前を yyyy-mm-dd_server.log に変更し、デフォルトの場所に新しい server.log ファイルを作成します。
asadmin> rotate-log Command rotate-log executed successfuly. |
コマンド行に asadmin help rotate-log と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
デフォルトでは、すべてのロギング情報は server.log ファイルに記録されます。このファイルは、通常 domain-dir /logs に保存されます。ロギング情報は、管理コンソール のログビューアを使用して表示できます。管理コンソール のロギング機能を使用する手順は、管理コンソール のオンラインヘルプで説明します。
特定のモジュールで収集された情報を表示するには、server.log ファイルをテキストエディタで開き、対象のモジュールを検索します。
この章では、asadmin コマンド行ユーティリティーを使用して、Sun GlassFishTM Enterprise Server v3 のコンポーネントとサービスを監視する方法について説明します。Enterprise Server リソースを監視するための JConsole の設定手順についても説明します。
ここでは、次のテーマを取り上げます。
管理コンソール を使用して監視を行う場合の手順は、管理コンソール のオンラインヘルプで説明します。
REST インタフェースを使用して監視を行う方法については、「REST インタフェースによる Enterprise Server の管理」を参照してください。
「監視」は、パフォーマンスの向上や問題の解決のために、システムの統計を調査する処理です。監視サービスでは、1 秒あたりの要求数、平均応答時間、スループットなどの運用上の統計を追跡および表示できます。Enterprise Server に配備されたさまざまなコンポーネントとサービスの状態を監視することで、パフォーマンスのボトルネックの識別、障害の予測、根本原因の分析を行い、すべての機能を期待どおりに動作させることができます。監視によって収集されたデータは、パフォーマンスの調整や容量計画にも役立ちます。
Enterprise Server のこのリリースでは、監視はモジュール方式で公開され、多くのクライアントモジュールが監視統計にアクセスして、これらを表示することができます。これらのクライアントには、管理コンソール、asadmin ユーティリティー、AMX、および REST インタフェースが含まれます。
ここでは、次のテーマを取り上げます。
「監視可能なオブジェクト」は、監視の対象に指定できるコンポーネント、サブコンポーネント、またはサービスです。Enterprise Server は、ツリー構造を使って監視可能なオブジェクトを追跡します。ツリーは動的であるため、Enterprise Server のコンポーネントが追加または削除されるときに、ツリーも変更されます。
ツリー内の監視可能なオブジェクトは、そのオブジェクトで監視できる対象を正確に表す子オブジェクト (ノード) を持ちます。すべての子オブジェクトのアドレス指定にはドット (.) 文字を区切り記号として使用します。このようなドット区切りの名前は、「ドット表記名」と呼ばれます。ドット表記名の詳細は、dotted-names(5ASC) のマニュアルページを参照してください。
次のコマンドは、インスタンス server の監視可能な子オブジェクトを一覧表示します。
asadmin> list --monitor "server.*" |
server.applications server.connector-service server.http-service server.jms-service server.containers.jruby server.jvm server.network server.orb server.resources server.security server.thread-pool server.transaction-service server.web |
各オブジェクトはドット表記名で表されます。また、監視可能なオブジェクトの特定の属性も、ドット表記名で指定します。たとえば、jvm オブジェクトには memory 属性と maxheapsize という名前の統計があります。この属性は次のドット表記名で表します。
server.jvm.memory.maxheapsize
オブジェクトが監視可能であっても、常に監視する必要はありません。監視を有効にする手順については、「監視の設定」を参照してください。
監視可能なオブジェクトは、それぞれ階層的なツリー構造を持ちます。ツリー中の「*statistics」などの置換可能な文字列は、統計を表示できる属性の名前を表しています。
ここでは、次のノードのツリー階層を説明します。
applications ツリーには、次のノードが含まれます。
server.applications |--- application1 | |--- ejb-module-1 | | |--- ejb1 * | | |--- bean-cache (for entity/sfsb) * | | |--- bean-pool (for slsb/mdb/entity) * | | |--- bean-methods | | |---method1 * | | |---method2 * | | |--- timers (for s1sb/entity/mdb) * | |--- web-module-1 | | |--- virtual-server-1 * | | |---servlet1 * | | |---servlet2 * |--- standalone-web-module-1 | | |----- virtual-server-2 * | | |---servlet3 * | | |---servlet4 * | | |----- virtual-server-3 * | | |---servlet3 *(same servlet on different vs) | | |---servlet5 * |--- standalone-ejb-module-1 | | |--- ejb2 * | | |--- bean-cache (for entity/sfsb) * | | |--- bean-pool (for slsb/mdb/entity) * | | |--- bean-methods | | |--- method1 * | | |--- method2 * | | |--- timers (for s1sb/entity/mdb) * |--- jersey-application-1 | |--- jersey | | |--- resources resource-0 hitcount *statistic |--- application2
ドット表記名は、server.applications.hello.server.request.maxtime のようになります。
EJB の method ノード以下のドット表記名は、server.applications.ejbsfapp1.ejbsfapp1ejbmod1\.jar.SFApp1EJB1 のようになります。
Jersey のドット表記名は、server.applications.helloworld-webapp.jersey.resources.resource-0.hitcount .resourcehitcount-count のようになります。
使用可能な統計については、「EJB 統計」、「Jersey の統計」、および 「Web の統計」 を参照してください。
connector-service ツリーには、コネクタ接続プールなどの、プールの監視可能な属性が格納されます。connector-service ツリーには、次のノードが含まれます。
server.connector-service resource-adapter-1 connection-pools pool-1 work-management
ドット表記名は、server.connector-service.resource-adapter-1.connection-pools.pool-1 のようになります。使用可能な統計については、「JMS サービスおよびコネクタサービスの統計」を参照してください。
http-service ツリー階層には、次のノードが含まれます。
server.http-service virtual-server request *statistic _asadmin request *statistic
virtual-server ノード以下のドット表記名は、server.http-service.virtual-server1.request.requestcount のようになります。使用可能な統計については、「HTTP サービスの統計」を参照してください。
jms-service ツリーには、接続ファクトリ (リソースアダプタの接続プール) と作業管理 (Message Queue リソースアダプタ用) の監視可能な属性が格納されます。jms-service ツリーには、次のノードが含まれます。
server.jms-service connection-factories connection-factory-1 work-management
connection-factories ノード以下のドット表記名は、server.jms-service.connection-factories.connection-factory-1 のようになります。この表記名は、この接続ファクトリのすべての統計を表します。使用可能な統計については、「JMS サービスおよびコネクタサービスの統計」を参照してください。
jruby ツリーには、次のノードが含まれます。
server.containers.jruby.applications jruby-application *statistic http *statistic runtime-pool *statistic |
使用可能な統計については、「JRuby の統計」を参照してください。
jvm ツリーには、次のノードが含まれます。
server.jvm class-loading-system compilation-system garbage-collectors memory operating-system runtime
memory ノード以下のドット表記名は、server.jvm.memory.maxheapsize のようになります。使用可能な統計については、「JVM の統計」を参照してください。
ネットワークの統計は、admin-listener 、http-listener-1、http-listener-2 などのネットワークリスナーに適用されます。network ツリーには、次のノードが含まれます。
server.network type-of-listener keep-alive *statistic file-cache *statistic thread-pool *statistic connection-queue *statistic
network ノード以下のドット表記名は、server.network.admin-listener.keep-alive.maxrequests-count のようになります。使用可能な統計については、「ネットワークの統計」を参照してください。
orb ツリーには、接続マネージャーの監視可能な属性が格納されます。orb ツリーには、次のノードが含まれます。
server.orb transport connectioncache inbound *statistic outbound *statistic
ドット表記名は、server.orb.transport.connectioncache.inbound.connectionsidle-count のようになります。使用可能な統計については、「ORB の統計 (接続マネージャー)」を参照してください。
resources ツリーには、JDBC 接続プールやコネクタ接続プールなどの、プールの監視可能な属性が格納されます。resources ツリーには、次のノードが含まれます。
server.resources connection-pool request *statistic
ドット表記名は、server.resources.jdbc-connection-pool1.numconnfree.count のようになります。使用可能な統計については、「リソースの統計 (接続プール)」を参照してください。
security ツリーには、次のノードが含まれます。
server.security ejb *statistic web *statistic realm *statistic
ドット表記名は、server.security.realm.realmcount-starttime のようになります。使用可能な統計については、「セキュリティーの統計」を参照してください。
thread-pool ツリー階層には、接続マネージャーの監視可能な属性が格納され、次のノードが含まれます。
server.thread-pool orb threadpool thread-pool-1 *statistic
ドット表記名は、server.thread-pool.orb.threadpool.thread-pool-1.averagetimeinqueue-current のようになります。使用可能な統計については、「スレッドプールの統計」を参照してください。
transaction-service ツリーには、トランザクションをロールバックするためのトランザクションサブシステムに関して、監視可能な属性が格納されます。transaction-service ツリーには、次のノードが含まれます。
server.transaction-service statistic
ドット表記名は、server.tranaction-service.activeids のようになります。使用可能な統計については、「トランザクションサービスの統計」を参照してください。
web ツリーには、次のノードが含まれます。
server.web jsp *statistic servlet *statistic session *statistic request *statistic
servlet ノードのドット表記名は、server.web.servlet.activeservletsloadedcount のようになります。使用可能な統計については、「Web モジュールの共通統計」を参照してください。
一般的に、アドオンコンポーネントは、Enterprise Server が実行時に収集できる統計を生成します。監視機能を追加することで、アドオンコンポーネントは Enterprise Server の配布で提供されているコンポーネントと同じ方法で、Enterprise Server に統計を提供できるようになります。結果として、コンポーネントの製造元にかかわらず、インストールされているすべての Enterprise Server コンポーネントの統計を、同じ管理インタフェースを使用して監視することができます。
Enterprise Server のサービスとコンポーネントを監視するために、次の asadmin サブコマンドが提供されています。
enable-monitoring、disable-monitoring、または get および set サブコマンドは、監視を有効または無効にするために使用します。手順については、「監視の設定」を参照してください。
monitor --type サブコマンドは、特定のタイプの監視可能なオブジェクトの基本データを表示するために使用します。手順については、「共通の監視データの表示」を参照してください。
list --monitor サブコマンドは、monitor サブコマンドで監視できるオブジェクトを表示するために使用します。ガイドラインと手順については、「list および get サブコマンドを監視に使用する場合のガイドライン」を参照してください。
get サブコマンドは、属性や値などの総合的なデータをドット表記名で表示するために使用します。get サブコマンドでワイルドカードのパラメータを使用すると、任意の監視可能なオブジェクトで使用可能なすべての属性を表示できます。詳細は、「list および get サブコマンドを監視に使用する場合のガイドライン」を参照してください。
デフォルトでは、Enterprise Server の監視サービスは有効になっていますが、各モジュールの監視は有効になっていません。モジュールの監視を有効にするには、モジュールの監視レベルを LOW または HIGH に変更します。監視の必要がないオブジェクトでは、監視レベルを OFF のままにすることもできます。
LOW。作成数やバイト数などの簡単な統計が含まれます。
HIGH。簡単な統計に加え、メソッドの数や実行時間などのメソッドの統計が含まれます。
OFF。監視を行いません。パフォーマンスへの影響はありません。
ここでは、次のタスクを説明します。
enable-monitoring サブコマンドを使用して、監視サービス自体を有効にするか、個々のモジュールの監視を有効にします。監視はただちに有効になります。Enterprise Server の再起動は必要ありません。
set(1) サブコマンドを使用して、モジュールの監視を有効にすることもできます。set コマンドの使用は動的な手順ではないため、変更を有効にするには Enterprise Server を再起動する必要があります。
現在監視が有効になっているサービスとコンポーネントを確認します。
asadmin> get server.monitoring-service.module-monitoring-levels.* |
この例の出力は、HTTP サービスでは監視が有効でなく (OFF)、その他のオブジェクトでは有効であることを示しています。
configs.config.server-config.monitoring-service.module-monitoring-levels.web-container=HIGH configs.config.server-config.monitoring-service.module-monitoring-levels.http-service=OFF configs.config.server-config.monitoring-service.module-monitoring-levels.jvm=HIGH |
enable-monitoring(1) サブコマンドを使用して、監視を有効にします。
サーバーの再起動は必要ありません。
この例では、個々のモジュールの監視に影響を与えずに、監視サービスを有効にします。
asadmin> enable-monitoring Command enable-monitoring executed successfully |
この例では、ejb-container モジュールの監視を有効にします。
asadmin> enable-monitoring --level ejb-container=HIGH Command enable-monitoring executed successfully |
この例では、監視レベルを HIGH に設定することで、HTTP サービスの監視を有効にします。変更を有効にするには、サーバーを再起動する必要があります。
asadmin> set server.monitoring-service.module-monitoring-levels.http-service=HIGH Command set executed successfully |
コマンド行に asadmin help enable-monitoring と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
disable-monitoring サブコマンドを使用して、監視サービス自体を無効にするか、個々のモジュールの監視を無効にします。監視はただちに停止されます。Enterprise Server の再起動は必要ありません。
set(1) サブコマンドを使用して、モジュールの監視を無効にすることもできます。set コマンドの使用は動的な手順ではないため、変更を有効にするには Enterprise Server を再起動する必要があります。
現在監視が有効になっているサービスとコンポーネントを確認します。
asadmin get server.monitoring-service.module-monitoring-levels.* |
この例の出力は、web-container 、http-service、および jvm で監視が有効であることを示しています。
configs.config.server-config.monitoring-service.module-monitoring-levels.web-container=HIGH configs.config.server-config.monitoring-service.module-monitoring-levels.http-service=HIGH configs.config.server-config.monitoring-service.module-monitoring-levels.jvm=HIGH |
disable-monitoring(1) サブコマンドを使用して、サービスまたはモジュールの監視を無効にします。
サーバーの再起動は必要ありません。
この例では、個々のモジュールの監視レベルを変更することなく、監視サービスを無効にします。
asadmin> disable-monitoring Command disable-monitoring executed successfully |
この例では、指定したモジュールの監視を無効にします。これらのモジュールの監視レベルは OFF に設定されます。
asadmin> disable-monitoring --modules web-container,ejb-container Command disable-monitoring executed successfully |
この例では、HTTP サービスの監視を無効にします。変更を有効にするには、サーバーを再起動する必要があります。
asadmin> set server.monitoring-service.module-monitoring-levels.http-service=OFF Command set executed successfully |
コマンド行に asadmin help disable-monitoring と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
monitor サブコマンドを使用して、共通で監視されるオブジェクトについての基本的なデータを表示できます。
monitor サブコマンドの --type オプションを使用して、httplistener、jvm、webmodule などの、データを表示するオブジェクトを指定します。タイプを指定せずに monitor サブコマンドを使用すると、エラーメッセージが表示されます。
サブコマンドの出力は、表形式で続けて表示されます。--interval オプションを使用すると、特定の間隔 (デフォルトでは 30 秒) で出力を表示することができます。
監視可能なオブジェクトのデータを表示する前に、対象のオブジェクトで監視を設定する必要があります。「監視を有効にする 」を参照してください。
監視する監視可能なオブジェクトのタイプを決定します。
v3 では、jvm、httplistener 、および webmodule を選択できます。
monitor(1) サブコマンドを使用して、監視データを要求します。
この例では、インスタンス server の jvm タイプの共通データを要求します。
asadmin> monitor --type jvm server UpTime(ms) Heap and NonHeap Memory(bytes) current min max low high count 9437266 8585216 619642880 0 0 93093888 9467250 8585216 619642880 0 0 93093888 |
コマンド行に asadmin help monitor と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
共通の監視統計について、次の節で説明します。
httplistener タイプに関して利用可能な統計を、次の表に示します。
表 8–1 HTTP リスナーの共通監視統計
Statistic |
説明 |
---|---|
ec |
エラー数。エラー数の累積値です。 |
mt |
最大時間。要求あたりの最長応答時間です。累積値ではなく、応答時間の中で最大の値です。 |
pt |
処理時間。各要求の処理にかかった時間の累積値。処理時間は、要求全体での要求処理時間の平均になります。 |
rc |
要求数。現時点までに処理された要求の累積数。 |
jvm タイプに関して利用可能な統計を、次の表に示します。
表 8–2 JVM の共通監視統計
Statistic |
説明 |
---|---|
count |
JVM マシンでの使用が保証されているメモリー量 (バイト)。 |
high |
他のリリースとの互換性を維持するために使用されます。 |
low |
他のリリースとの互換性を維持するために使用されます。 |
max |
メモリー管理用として使用可能なメモリーの最大サイズ。 |
min |
起動中のメモリー管理用に JVM マシンがオペレーティングシステムに要求するメモリー量の初期値 (バイト)。 |
UpTime |
直前の起動日時からの JVM マシンの稼働時間 (ミリ秒)。 |
webmodule タイプに関して利用可能な統計を、次の表に示します。
表 8–3 Web モジュールの共通監視統計
Statistic |
説明 |
---|---|
ajlc |
読み込まれているアクティブな JavaServer PagesTM (JSPTM) テクノロジページの数。 |
asc |
現在のアクティブなセッション。 |
aslc |
読み込まれているアクティブなサーブレットの数。 |
ast |
アクティブなセッションの合計数。 |
mjlc |
読み込まれている JSP ページの最大数。 |
mslc |
読み込まれているサーブレットの最大数 |
rst |
拒否されたセッションの合計数。 |
st |
セッションの合計数。 |
tjlc |
読み込まれている JSP ページの合計数。 |
tslc |
読み込まれているサーブレットの合計数。 |
ツリー構造に対して list および get サブコマンドをドット表記名を使用して適用することで、各統計の説明や測定単位など、より総合的な監視データを表示することができます。
ここでは、次のテーマを取り上げます。
list コマンドと get コマンドでドット表記名を使用する場合は、基本として次の内容が前提となります。
list サブコマンドにドット表記名を指定する場合、ドット表記名のあとにワイルドカード (*) を指定しないと、現在のノードの直接の子だけが一覧表示されます。たとえば、次のサブコマンドは server ノードに属する直接の子をすべて表示します。
list --monitor server
list サブコマンドにドット表記名を指定する場合、ドット表記名の後ろに .* の形式のワイルドカードを指定すると、指定したノードから子ノードの階層ツリーが一覧表示されます。たとえば、次のサブコマンドは applications ノード以下のすべての子ノードを、それぞれの子ノードも含めてすべて表示します。
list --monitor server.applications.*
list サブコマンドにドット表記名を指定する場合、ドット表記名の前または後ろに、*dottedname、dotted * name、または dottedname * の形式のワイルドカードを指定すると、指定したマッチングパターンで表される正規表現に一致する、すべてのノードとその子ノードが一覧表示されます。
get サブコマンドのあとに .* または * を指定すると、指定したノードに含まれる属性とその値のセットが取得されます。
例として、list および get サブコマンドに resources ノードのドット表記名を使用した場合の出力を、次の表に示します。
表 8–4 リソースレベルのドット表記名の例
サブコマンド |
ドット表記名 |
出力 |
---|---|---|
list --monitor |
server.resources |
プール名の一覧。 |
list --monitor |
server.resources.connection-pool1 |
属性は表示されず、代わりに「get --monitor サブコマンドを使用して、このノードの属性と値を表示してください」というメッセージが表示されます。 |
get --monitor |
server.resources.connection-pool1.* |
接続プールの属性に対応した属性と値のリスト。 |
ドット表記名の詳細は、dotted-names(5ASC) のマニュアルページを参照してください。
monitor サブコマンドは多くの状況で役に立ちますが、すべての監視可能なオブジェクトの完全なリストを表示することはできません。特定のオブジェクトタイプの総合的なデータを操作するには、list --monitor サブコマンドおよび get --monitor サブコマンドのあとに、監視可能なオブジェクトのドット表記名を指定します。
監視可能なオブジェクトの情報を表示する前に、対象のオブジェクトで監視を設定する必要があります。必要な場合は、「監視を有効にする 」を参照してください。
list(1) サブコマンドを使用して、監視が有効なオブジェクトを一覧表示します。
たとえば、次のサブコマンドは、インスタンス server で監視が有効になっているコンポーネントとサービスをすべて表示します。
asadmin> list --monitor "*" server.web server.connector-service server.orb server.jms-serviceserver.jvm server.applications server.http-service server.thread-pools |
get(1) サブコマンドを使用して、監視対象のコンポーネントまたはサービスのデータを取得します。
この例では、インスタンス serverで、オブジェクトタイプ jvm のすべての属性に関する情報を取得します。
asadmin> get --monitor server.jvm.* server.jvm.class-loading-system.loadedclasscount = 3715 server.jvm.class-loading-system.totalloadedclasscount = 3731 server.jvm.class-loading-system.unloadedclasscount = 16 server.jvm.compilation-system.name-current = HotSpot Client Compiler server.jvm.compilation-system.totalcompilationtime = 769 server.jvm.garbage-collectors.Copy.collectioncount = 285 server.jvm.garbage-collectors.Copy.collectiontime = 980 server.jvm.garbage-collectors.MarkSweepCompact.collectioncount = 2 server.jvm.garbage-collectors.MarkSweepCompact.collectiontime = 383 server.jvm.memory.committedheapsize = 23498752 server.jvm.memory.committednonheapsize = 13598720 server.jvm.memory.initheapsize = 0 server.jvm.memory.initnonheapsize = 8585216 server.jvm.memory.maxheapsize = 66650112 server.jvm.memory.maxnonheapsize = 100663296 server.jvm.memory.objectpendingfinalizationcount = 0 server.jvm.memory.usedheapsize = 19741184 server.jvm.memory.usednonheapsize = 13398352 server.jvm.operating-system.arch-current = x86 server.jvm.operating-system.availableprocessors = 2 server.jvm.operating-system.name-current = Windows XP server.jvm.operating-system.version-current = 5.1 server.jvm.runtime.classpath-current = glassfish.jar server.jvm.runtime.inputarguments-current = [] server.jvm.runtime.managementspecversion-current = 1.0 server.jvm.runtime.name-current = 4372@ABBAGANI_WORK server.jvm.runtime.specname-current = Java Virtual Machine Specification server.jvm.runtime.specvendor-current = Sun Microsystems Inc. server.jvm.runtime.specversion-current = 1.0 server.jvm.runtime.uptime = 84813 server.jvm.runtime.vmname-current = Java HotSpot(TM) Client VM server.jvm.runtime.vmvendor-current = Sun Microsystems Inc. server.jvm.runtime.vmversion-current = 1.5.0_11-b03 |
この例では、インスタンス server の監視可能なアプリケーションをすべて表示します。
asadmin> list --monitor server.applications.* server.applications.app1 server.applications.app2 server.applications.app1.virtual-server1 server.applications.app2.virtual-server1 |
この例では、アプリケーション hello のすべての属性に関する情報を取得します。
asadmin> get --monitor server.applications.hello.* server.applications.hello.server.activatedsessionstotal = 0 server.applications.hello.server.activejspsloadedcount = 1 server.applications.hello.server.activeservletsloadedcount = 1 server.applications.hello.server.activesessionscurrent = 1 server.applications.hello.server.activesessionshigh = 1 server.applications.hello.server.errorcount = 0 server.applications.hello.server.expiredsessionstotal = 0 server.applications.hello.server.maxjspsloadedcount = 1 server.applications.hello.server.maxservletsloadedcount = 0 server.applications.hello.server.maxtime = 0 server.applications.hello.server.passivatedsessionstotal = 0 server.applications.hello.server.persistedsessionstotal = 0 server.applications.hello.server.processingtime = 0.0 server.applications.hello.server.rejectedsessionstotal = 0 server.applications.hello.server.requestcount = 0 server.applications.hello.server.sessionstotal = server.applications.hello.server.totaljspsloadedcount = 0 server.applications.hello.server.totalservletsloadedcount = 0 |
この例では、インスタンス server の jvm 属性 runtime.vmversion-current に関する情報を取得します。
asadmin> get --monitor server.jvm.runtime.vmversion-current server.jvm.runtime.vmversion-current = 10.0-b23 |
目的の統計を表すドット表記名を指定することで、総合的な監視統計を取得できます。たとえば、次のドット表記名では、virtual-server1 の HTTP サービスに対する要求の累積数が表示されます。
server.http-service.virtual-server1.request.requestcount
監視可能なオブジェクトのそれぞれで使用可能な統計を、次の節の表に示します。
EJB は、「アプリケーションのツリー階層」に示したオブジェクトツリー内に含まれます。次のドット表記名パターンを使用して、アプリケーションの統計を取得します。
server.applications.appname.ejbmodulename.ejbname.bean-cache.statistic
アプリケーションに関して利用可能な統計を、次の節で説明します。
EJB キャッシュの統計では、次のドット表記名パターンを使用します。
server.applications.appname.ejbmodulename.bean-cache.ejbname.statistic
EJB キャッシュに関して利用可能な統計を、次の表に示します。
表 8–5 EJB キャッシュの監視統計
Statistic |
データ型 |
説明 |
---|---|---|
cachemisses |
RangeStatistic |
ユーザー要求に対する Bean がキャッシュ内で見つからなかった回数。 |
cachehits |
RangeStatistic |
ユーザー要求に対するエントリがキャッシュ内で見つかった回数。 |
numbeansincache |
RangeStatistic |
キャッシュ内の Beans 数。これは現在のキャッシュサイズです。 |
numpassivations |
CountStatistic |
非活性化された Bean の数。ステートフルセッション Beans にのみ適用されます。 |
numpassivationerrors |
CountStatistic |
非活性化中に発生したエラーの数。ステートフルセッション Beans にのみ適用されます。 |
numexpiredsessionsremoved |
CountStatistic |
クリーンアップスレッドによって削除された期限切れセッションの数。ステートフルセッション Beans にのみ適用されます。 |
numpassivationsuccess |
CountStatistic |
非活性化が正常に終了した回数。ステートフルセッション Beans にのみ適用されます。 |
EJB コンテナの統計では、次のドット表記名パターンを使用します。
server.applications.appname.ejbmodulename.container.ejbname
EJB コンテナに関して利用可能な統計を、次の表に示します。
表 8–6 EJB コンテナの監視統計
Statistic |
データ型 |
説明 |
---|---|---|
createcount |
CountStatistic |
特定の EJB に対する create メソッドの呼び出し回数。 |
messagecount |
CountStatistic |
特定のメッセージ駆動型 Bean に対して受信されたメッセージの数。 |
methodreadycount |
RangeStatistic |
MethodReady 状態にあるステートフルまたはステートレスセッション Beans の数。 |
passivecount |
RangeStatistic |
Passive 状態にあるステートフルセッション Beans の数。 |
pooledcount |
RangeStatistic |
プールされた状態にあるエンティティー Bean の数。 |
readycount |
RangeStatistic |
実行可能状態にあるエンティティー Bean の数。 |
removecount |
CountStatistic |
特定の EJB に対する remove メソッドの呼び出し回数。 |
EJB メソッドの統計では、次のドット表記名パターンを使用します。
server.applications.appname.ejbmodulename.bean-methods.ejbname.statistic
EJB メソッドの呼び出しに関して利用可能な統計を、次の表に示します。
表 8–7 EJB メソッドの監視統計
Statistic |
データ型 |
説明 |
---|---|---|
executiontime |
CountStatistic |
成功または失敗した最後の操作実行時にメソッド実行に費やされた時間 (ミリ秒)。この情報は、EJB コンテナの監視が有効になっている場合に、ステートレスおよびステートフルのセッション Beans とエンティティー Beans に対して収集されます。 |
methodstatistic |
TimeStatistic |
特定の操作の呼び出し回数。その呼び出しにかかった合計時間など。 |
totalnumerrors |
CountStatistic |
メソッド実行時に例外が発生した回数。この情報は、EJB コンテナの監視が有効になっている場合に、ステートレスおよびステートフルのセッション Beans とエンティティー Beans に対して収集されます。 |
totalnumsuccess |
CountStatistic |
メソッドが正常に実行された回数。この情報は、EJB コンテナの監視が有効になっている場合に、ステートレスおよびステートフルのセッション Beans とエンティティー Beans に対して収集されます。 |
EJB プールの統計では、次のドット表記名パターンを使用します。
server.applications.appname.ejbmodulename.bean-pool.ejbname.statistic表 8–8 EJB プールの監視統計
Statistic |
データ型 |
説明 |
---|---|---|
jmsmaxmessagesload |
CountStatistic |
メッセージ駆動型 Bean のサービスを提供するために JMS セッション内に一度にロード可能なメッセージの最大数。デフォルトは 1 です。メッセージ駆動型 Beans 用のプールにのみ適用されます。 |
numbeansinpool |
RangeStatistic |
関連付けられたプール内の EJB 数。プールの変化に関する情報を提供します。 |
numthreadswaiting |
RangeStatistic |
未使用 Beans を取得するために待機しているスレッドの数。これは、要求が過剰である可能性を示します。 |
totalbeanscreated |
CountStatistic |
関連付けられたプール内でデータ収集開始後に作成された Beans の数。 |
totalbeansdestroyed |
CountStatistic |
関連付けられたプール内でデータ収集開始後に破棄された Beans の数。 |
server.applications.appname.ejbmodulename.timers.ejbname.statistic表 8–9 タイマーの監視統計
Statistic |
データ型 |
説明 |
---|---|---|
numtimerscreated |
CountStatistic |
システム内で作成されたタイマーの数。 |
numtimersdelivered |
CountStatistic |
システムによって配信されたタイマーの数。 |
numtimersremoved |
CountStatistic |
システムから削除されたタイマーの数。 |
HTTP サービスは、「HTTP サービスのツリー階層」に示したオブジェクトツリー内に含まれます。
HTTP サービスの統計を、次の節で説明します。
HTTP サービス仮想サーバーの統計では、次のドット表記名パターンを使用します。
server.http-service.virtual-server.request.statistic
仮想サーバーに関する HTTP サービスの統計を、次の表に示します。
表 8–10 HTTP サービス仮想サーバーの監視統計
Statistic |
データ型 |
説明 |
---|---|---|
count200 |
CountStatistic |
状態コードが 200 である応答の数。 |
count2xx |
CountStatistic |
状態コードが 2xx の範囲内にある応答の数。 |
count302 |
CountStatistic |
状態コードが 302 である応答の数。 |
count304 |
CountStatistic |
状態コードが 304 である応答の数。 |
count3xx |
CountStatistic |
状態コードが 3xx の範囲内にある応答の数。 |
count400 |
CountStatistic |
状態コードが 400 である応答の数。 |
count401 |
CountStatistic |
状態コードが 401 である応答の数。 |
count403 |
CountStatistic |
状態コードが 403 である応答の数。 |
count404 |
CountStatistic |
状態コードが 404 である応答の数。 |
count4xx |
CountStatistic |
状態コードが 4xx の範囲内にある応答の数。 |
count503 |
CountStatistic |
状態コードが 503 である応答の数。 |
count5xx |
CountStatistic |
状態コードが 5xx の範囲内にある応答の数。 |
countother |
CountStatistic |
状態コードが 2xx、3xx、4xx、および 5xx の範囲外である応答の数。 |
errorcount |
CountStatistic |
エラー回数の累計値。エラー回数は、応答コードが 400 以上になった場合の回数を表します。 |
hosts |
StringStatistic |
仮想サーバーのホスト (エイリアス) 名。 |
maxtime |
CountStatistic |
要求あたりの最長応答時間です。累積値ではなく、応答時間の中で最大の値です。 |
processingtime |
CountStatistic |
各要求の処理にかかった時間の累積値。処理時間は、要求数全体での要求処理時間の平均値になります。 |
requestcount |
CountStatistic |
現時点までに処理された要求の累積数。 |
state |
StringStatistic |
仮想サーバーの状態 |
Jersey は、「アプリケーションのツリー階層」に示したオブジェクトツリー内に含まれます。
Jersey の統計では、次のドット表記名パターンを使用します。
server.applications.jersey-application.jersey.resources.resource-0.hitcount.statistic表 8–11 Jersey の統計
Statistic |
データ型 |
説明 |
---|---|---|
resourcehitcount |
CountStatistic |
このリソースクラスでのヒット数。 |
rootresourcehitcount |
CountStatistic |
このルートリソースクラスでのヒット数。 |
JMS サービスとコネクタサービスは、「JMS およびコンテナサービスのツリー階層」に示したオブジェクトツリー内に含まれます。
JMS サービスとコネクタサービスの統計を、次の節で説明します。
JMS サービスとコネクタサービスの接続プールの統計では、次のドット表記名パターンを使用します。
server.connector-service.resource-adapter-1.connection-pool.statistic
コネクタ接続プールに関して利用可能な JMS サービスとコネクタサービスの統計を、次の表に示します。
表 8–12 コネクタ接続プールの監視統計 (JMS)
Statistic |
データ型 |
説明 |
---|---|---|
averageconnwaittime |
CountStatistic |
接続プールからサービスを受けるまでにかかった平均接続待ち時間。 |
connectionrequestwaittime |
RangeStatistic |
接続要求の最長待ち時間と最短待ち時間。現在の値は、プールのサービスを最後に受けた要求の待ち時間を示します。 |
numconnfailedvalidation |
CountStatistic |
開始時刻から前回のサンプリング時刻までの間に検証に失敗した接続プール内の接続の合計数。 |
numconnused |
RangeStatistic |
現在使用されている合計接続数に加え、過去に使用された接続の最大数 (ハイウォーターマーク) に関する情報も提供します。 |
numconnfree |
RangeStatistic |
前回のサンプリング時点におけるプール内の未使用接続の合計数。 |
numconntimedout |
CountStatistic |
開始時刻から前回のサンプリング時刻までの間にタイムアウトしたプール内の接続の合計数。 |
numconncreated |
CountStatistic |
前回のリセット後に作成された物理接続の数。 |
numconndestroyed |
CountStatistic |
前回のリセット後に破棄された物理接続の数。 |
numconnacquired |
CountStatistic |
プールから取得された論理接続の数。 |
numconnreleased |
CountStatistic |
プールに解放された論理接続の数。 |
waitqueuelenght |
CountStatistic |
サービスを受けるためにキュー内で待機している接続要求の数。 |
JMS サービスとコネクタサービスの作業管理の統計では、次のドット表記名パターンを使用します。
server.connector-service.resource-adapter-1.work-management.statistic
コネクタ作業管理に関して利用可能な JMS サービスとコネクタサービスの統計を、次の表に示します。
表 8–13 コネクタ作業管理の監視統計 (JMS)
Statistic |
データ型 |
説明 |
---|---|---|
activeworkcount |
RangeStatistic |
コネクタによって実行された作業オブジェクトの数。 |
completedworkcount |
CountStatistic |
完了した作業オブジェクトの数。 |
rejectedworkcount |
CountStatistic |
Enterprise Server によって拒否された作業オブジェクトの数。 |
submittedworkcount |
CountStatistic |
コネクタモジュールによって送信された作業オブジェクトの数。 |
waitqueuelength |
RangeStatistic |
実行される前にキュー内で待機している作業オブジェクトの数。 |
workrequestwaittime |
RangeStatistic |
作業オブジェクトが実行されるまでの最長待ち時間と最短待ち時間。 |
JRuby は、「JRuby のツリー階層」に示したオブジェクトツリー内に含まれます。
JRuby に関して利用可能な統計を、次の節で説明します。
JRuby コンテナの統計では、次のドット表記名パターンを使用します。
server.containers.jruby.applications.jruby-application.statistic
JRuby コンテナに関して利用可能な統計を、次の表に示します。
表 8–14 JRuby コンテナの統計
Statistic |
データ型 |
説明 |
---|---|---|
environment |
StringStatistic |
JRuby アプリケーション環境。 |
appname |
StringStatistic |
Ruby アプリケーション名。 |
contextpath |
StringStatistic |
Ruby アプリケーションのコンテキストパス。 |
jrubyversion |
StringStatistic |
JRuby のバージョン。 |
rubyframework |
StringStatistic |
Ruby アプリケーションフレームワーク。 |
JRuby ランタイムの統計では、次のドット表記名パターンを使用します。
server.containers.jruby.applications.jruby-application.runtime.statistic
JRuby ランタイムに関して利用可能な統計を、次の表に示します。
表 8–15 JRuby ランタイムの統計
Statistic |
データ型 |
説明 |
---|---|---|
activeruntimes |
CountStatistic |
現在アクティブなランタイムの数。 |
appname |
StringStatistic |
Ruby アプリケーション名。 |
hardmaximum |
CountStatistic |
アクティブなランタイムの最大数。 |
hardminimum |
CountStatistic |
アクティブなランタイムの最小数。 |
JRuby HTTP サービスの統計では、次のドット表記名パターンを使用します。
server.containers.jruby.applications.jruby-application.http.statistic
JRuby HTTP サービスに関して利用可能な統計を、次の表に示します。
表 8–16 JRuby HTTP サービスの統計
Statistic |
データ型 |
説明 |
---|---|---|
address |
StringStatistic |
サーバーアドレス。 |
appname |
StringStatistic |
Ruby アプリケーション名。 |
averageprocessingtime |
CountStatistic |
平均要求処理時間 (ミリ秒)。 |
contextpath |
StringStatistic |
Ruby アプリケーションのコンテキストパス。 |
count2xx |
CountStatistic |
状態コードが 2xx の範囲内にある応答の数。 |
count200 |
CountStatistic |
状態コードが 200 である応答の数。 |
count3xx |
CountStatistic |
状態コードが 3xx の範囲内にある応答の数。 |
count302 |
CountStatistic |
状態コードが 302 である応答の数。 |
Count304 |
CountStatistic |
状態コードが 304 である応答の数。 |
count4xx |
CountStatistic |
状態コードが 4xx の範囲内にある応答の数。 |
count400 |
CountStatistic |
状態コードが 400 である応答の数。 |
count401 |
CountStatistic |
状態コードが 401 である応答の数。 |
count403 |
CountStatistic |
状態コードが 403 である応答の数。 |
count404 |
CountStatistic |
状態コードが 404 である応答の数。 |
count5xx |
CountStatistic |
状態コードが 5xx の範囲内にある応答の数。 |
count503 |
CountStatistic |
状態コードが 503 である応答の数。 |
countother |
CountStatistic |
状態コードがその他の値である応答の数。 |
errorcount |
CountStatistic |
状態コードが 400 より大きい応答の数。 |
requests/seconds |
CountStatistic |
1 秒あたりの要求数。 |
JVM は、「JVM のツリー階層」に示したオブジェクトツリー内に含まれます。
Java プラットフォームの仮想マシン (JavaTM 仮想マシン、または JVM マシン) に関して利用可能な統計を、次の節で説明します。
JVM クラス読み込みシステムの統計では、次のドット表記名パターンを使用します。
server.jvm.class-loading-system.statistic
Java SE では、JVM から追加の監視情報を取得できます。監視レベルを「低」に設定すると、この追加情報の表示が有効になります。監視レベルを「高」に設定すると、さらにシステム内の各ライブスレッドに関する情報も表示されます。Java SE で利用可能な追加監視機能の詳細は、『Monitoring and Management for the Java Platform』を参照してください。この文書は、http://java.sun.com/javase/6/docs/technotes/guides/management/ で入手できます。
Java SE 監視ツールについては、http://java.sun.com/javase/6/docs/technotes/tools/#manage を参照してください。
Java SE の JVM で利用可能なクラス読み込み関連の統計を、次の表に示します。
表 8–17 Java SE のクラス読み込みに関する JVM の監視統計
Statistic |
データ型 |
説明 |
---|---|---|
loadedclasscount |
CountStatistic |
JVM 内に現在読み込まれているクラスの数。 |
totalloadedclasscount |
CountStatistic |
JVM の実行開始後に読み込まれたクラスの合計数。 |
unloadedclasscount |
CountStatistic |
JVM の実行開始後に JVM から読み込み解除されたクラスの数。 |
Java SE の JVM で利用可能なスレッド関連の統計を、次の図に示します。
表 8–18 Java SE に関する JVM の監視統計 - スレッド
Statistic |
データ型 |
説明 |
---|---|---|
allthreadids |
StringStatistic |
すべてのライブスレッド ID のリスト。 |
currentthreadcputime |
CountStatistic |
CPU 時間の測定が有効になっている場合は、現在のスレッドに対する CPU 時間 (ナノ秒)。CPU 時間の測定が無効になっている場合は、-1 が返されます。 |
daemonthreadcount |
CountStatistic |
ライブデーモンスレッドの現在の数。 |
monitordeadlockedthreads |
StringStatistic |
監視デッドロックが発生しているスレッド ID のリスト。 |
peakthreadcount |
CountStatistic |
JVM 起動後またはピーク値リセット後におけるライブスレッドのピーク数。 |
threadcount |
CountStatistic |
ライブデーモンスレッドと非デーモンスレッドの現在の数。 |
totalstartedthreadcount |
CountStatistic |
JVM が起動されて以来、作成されたスレッド、起動されたスレッド、作成および起動されたスレッドの合計数。 |
JVM コンパイルシステムの統計では、次のドット表記名パターンを使用します。
server.jvm.compilation-system.statistic
Java SE の JVM のコンパイルに関して利用可能な統計を、次の表に示します。
表 8–19 Java SE のコンパイルに関する JVM の監視統計
Statistic |
データ型 |
説明 |
---|---|---|
name-current |
StringStatistic |
現在のコンパイラの名前。 |
totalcompilationtime |
CountStatistic |
コンパイルに費やされた時間の累計 (ミリ秒)。 |
JVM ガベージコレクタの統計では、次のドット表記名パターンを使用します。
server.jvm.garbage-collectors.statistic
Java SE の JVM のガベージコレクションに関して利用可能な統計を、次の表に示します。
表 8–20 Java SE のガベージコレクタに関する JVM の監視統計
Statistic |
データ型 |
説明 |
---|---|---|
collectioncount |
CountStatistic |
実行されたコレクションの合計回数。 |
collectiontime |
CountStatistic |
コレクションに費やされた時間の累計 (ミリ秒)。 |
JVM メモリーの統計では、次のドット表記名パターンを使用します。
server.jvm.memory.statistic
Java SE の JVM のメモリーに関して利用可能な統計を、次の表に示します。
表 8–21 Java SE のメモリーに関する JVM の監視統計
Statistic |
データ型 |
説明 |
---|---|---|
committedheapsize |
CountStatistic |
JVM 用としてコミットされたヒープメモリーのサイズ (バイト)。 |
committednonheapsize |
CountStatistic |
JVM 用としてコミットされた非ヒープメモリーのサイズ (バイト)。 |
initheapsize |
CountStatistic |
JVM が最初に要求したヒープのサイズ。 |
initnonheapsize |
CountStatistic |
JVM が最初に要求した非ヒープ領域のサイズ |
maxheapsize |
CountStatistic |
メモリー管理用として使用可能なヒープメモリーの最大サイズ (バイト)。 |
maxnonheapsize |
CountStatistic |
メモリー管理用として使用可能な非ヒープメモリーの最大サイズ (バイト)。 |
objectpendingfinalizationcount |
CountStatistic |
ファイナライズを保留しているオブジェクトの概算数。 |
usedheapsize |
CountStatistic |
現在使用されているヒープのサイズ。 |
usednonheapsize |
CountStatistic |
現在使用されている非ヒープ領域のサイズ。 |
JVM オペレーティングシステムの統計では、次のドット表記名パターンを使用します。
server.jvm.operating-system.statistic
Java SE の JVM マシンのオペレーティングシステムに関して利用可能な統計を、次の表に示します。
表 8–22 Java SE のオペレーティングシステムに関する JVM の統計
Statistic |
データ型 |
説明 |
---|---|---|
arch-current |
StringStatistic |
オペレーティングシステムのアーキテクチャー。 |
availableprocessors |
CountStatistic |
JVM が使用できるプロセッサの数。 |
name-current |
StringStatistic |
オペレーティングシステムの名前。 |
version-current |
StringStatistic |
オペレーティングシステムのバージョン。 |
JVM ランタイムの統計では、次のドット表記名パターンを使用します。
server.jvm.runtime.statistic
Java SE の JVM ランタイムに関して利用可能な統計を、次の表に示します。
表 8–23 Java SE のランタイムに関する JVM の監視統計
Statistic |
データ型 |
説明 |
---|---|---|
classpath-current |
StringStatistic |
システムクラスローダーがクラスファイルの検索時に使用するクラスパス。 |
inputarguments-current |
StringStatistic |
JVM に渡される入力引数 (main メソッドへの引数は含まない)。 |
managementspecversion-current |
StringStatistic |
JVM で実装される管理仕様のバージョン。 |
name-current |
StringStatistic |
実行中の JVM を表す名前 |
specname-current |
StringStatistic |
JVM 仕様の名前。 |
specvendor-current |
StringStatistic |
JVM 仕様のベンダー。 |
specversion-current |
StringStatistic |
JVM 仕様のバージョン。 |
uptime |
CountStatistic |
JVM の稼働時間 (ミリ秒)。 |
vmname-current |
StringStatistic |
JVM 実装の名前。 |
vmvendor-current |
StringStatistic |
JVM 実装のベンダー。 |
vmversion-current |
StringStatistic |
JVM 実装のバージョン。 |
ネットワークは、「ネットワークのツリー階層」に示したオブジェクトツリー内に含まれます。
ネットワークの統計を、次の節で説明します。
ネットワークキープアライブの統計では、次のドット表記名パターンを使用します。
server.network.type-of-listener.keep-alive.statistic
ネットワークキープアライブに関して利用可能な統計を、次の表に示します。
表 8–24 ネットワークキープアライブの統計
Statistic |
データ型 |
説明 |
---|---|---|
countconnections |
CountStatistic |
キープアライブモードの接続の数。 |
counttimeouts |
CountStatistic |
タイムアウトしたキープアライブ接続の数。 |
secondstimeouts |
CountStatistic |
キープアライブのタイムアウト値 (秒)。 |
maxrequests |
CountStatistic |
1 つのキープアライブ接続で許可されている要求の最大数。 |
countflushes |
CountStatistic |
閉じられたキープアライブ接続の数。 |
counthits |
CountStatistic |
キープアライブモードの接続で受信した要求の数。 |
countrefusals |
CountStatistic |
拒否されたキープアライブ接続の数。 |
ネットワーク接続キューの統計では、次のドット表記名パターンを使用します。
server.network.type-of-listener.connection-queue.statistic
ネットワーク接続キューに関して利用可能な統計を、次の表に示します。
表 8–25 ネットワーク接続キューの統計
Statistic |
データ型 |
説明 |
---|---|---|
countopenconnections |
CountStatistic |
開いている接続またはアクティブな接続の数。 |
countoverflows |
CountStatistic |
キューがいっぱいになったために接続を格納できなかった回数。 |
countqueued |
CountStatistic |
キュー内に現在存在している接続の数。 |
countqueued15minutesaverage |
CountStatistic |
キューに格納されている接続数の過去 15 分間における平均値。 |
countqueued1minuteaverage |
CountStatistic |
キューに格納されている接続数の過去 1 分間における平均値。 |
countqueued5minutesaverage |
CountStatistic |
キューに格納されている接続数の過去 5 分間における平均値。 |
counttotalconnections |
CountStatistic |
受け付けられた接続の合計数。 |
counttotalqueued |
CountStatistic |
キューに格納された接続の合計数。 |
maxqueued |
CountStatistic |
接続キューの最大サイズ。 |
peakqueued |
CountStatistic |
キュー内に同時に存在していた接続の最大数。 |
tickstotalqueued |
CountStatistic |
接続がキュー内で費やした合計ティック数 (未サポート)。 |
ネットワークファイルキャッシュの統計では、次のドット表記名パターンを使用します。
server.network.type-of-listener.file-cache.statistic
ネットワークファイルキャッシュに関して利用可能な統計を、次の表に示します。
表 8–26 ネットワークファイルキャッシュの統計
Statistic |
データ型 |
説明 |
---|---|---|
contenthits |
CountStatistic |
キャッシュファイルコンテンツのヒット数。 |
contentmisses |
CountStatistic |
キャッシュファイルコンテンツの失敗数。 |
heapsize |
CountStatistic |
現在のキャッシュサイズ (バイト)。 |
hits |
CountStatistic |
キャッシュ検索のヒット数。 |
infohits |
CountStatistic |
キャッシュファイル情報のヒット数。 |
infomisses |
CountStatistic |
キャッシュファイル情報の失敗数。 |
mappedmemorysize |
CountStatistic |
キャッシュ用に割り当てられたメモリーのサイズ (バイト)。 |
maxheapsize |
CountStatistic |
キャッシュ用のヒープ領域の最大サイズ (バイト)。 |
maxmappedmemorysize |
CountStatistic |
キャッシュ用の最大メモリーマップサイズ (バイト)。 |
misses |
CountStatistic |
キャッシュ検索に失敗したデータタイプの数。 |
opencacheentries |
CountStatistic |
現在開いているキャッシュエントリの数。 |
ネットワークスレッドプールの統計では、次のドット表記名パターンを使用します。
server.network.type-of-listener.thread-pool.statistic
ネットワークスレッドプールに関して利用可能な統計を、次の表に示します。
表 8–27 ネットワークスレッドプールの統計
Statistic |
データ型 |
説明 |
---|---|---|
corethreads |
CountStatistic |
スレッドプールに含まれるスレッドのコア数。 |
currentthreadcount |
CountStatistic |
リスナースレッドプール内に現在存在している要求処理スレッドの数。 |
currentthreadsbusy |
CountStatistic |
要求処理用リスナースレッドプール内で現在使用されている要求処理スレッドの数。 |
maxthreads |
CountStatistic |
スレッドプールで許可されているスレッドの最大数。 |
totalexecutedtasks |
CountStatistic |
スレッドプールで実行されたタスクの合計数。 |
ORB は、「ORB のツリー階層」に示したオブジェクトツリー内に含まれます。
ORB の統計では、次のドット表記名パターンを使用します。
server.orb.transport.connectioncache.inbound.statistic server.orb.transport.connectioncache.outbound.statistic
ORB の接続マネージャーに関して利用可能な統計を、次の表に示します。
表 8–28 ORB の監視統計 (接続マネージャー)
Statistic |
データ型 |
説明 |
---|---|---|
connectionsidle |
CountStatistic |
ORB への接続のうち、アイドル状態の接続の合計数。 |
connectionsinuse |
CountStatistic |
ORB への接続のうち、使用中の接続の合計数。 |
totalconnections |
BoundedRangeStatistic |
ORB への接続の合計数。 |
接続プールリソースを監視することで、実行時にパフォーマンスの測定やリソースの使用状況の取得を行えます。接続は負荷が大きく、アプリケーションでは頻繁にパフォーマンスのボトルネックとなります。接続プールの解放状況と新しい接続の作成状況、および特定のプールから接続を取得するために待機中であるスレッドの数を監視することが重要です。
接続プールリソースは、「リソースのツリー階層」に示したオブジェクトツリー内に含まれます。
接続プールの統計では、次のドット表記名パターンを使用します。
server.resources.connection-pool.statistic
接続プールの統計を、次の表に示します。
表 8–29 リソースの監視統計 (接続プール)
Statistic |
データ型 |
説明 |
---|---|---|
averageconnwaittime |
CountStatistic |
成功した接続要求あたりの平均待ち時間。 |
connrequestwaittime |
RangeStatistic |
前回のサンプリング以降の、接続要求の最長待ち時間と最短待ち時間 (ミリ秒)。現在の値は、プールで処理された直前の要求の待ち時間を示します。 |
numconnfailedvalidation |
CountStatistic |
開始時刻から前回のサンプリング時刻までの間に検証に失敗した接続プール内の接続数。 |
numconnused |
RangeStatistic |
現在使用されている接続数と、過去に使用された接続の最大数 (ハイウォーターマーク) に関する情報。 |
numconnfree |
RangeStatistic |
前回のサンプリング時点におけるプール内の未使用の接続の数。 |
numconntimedout |
CountStatistic |
開始時刻から前回のサンプリング時刻までの間にタイムアウトしたプール内の接続の数。 |
numconncreated |
CountStatistic |
前回のリセット後にプールによって作成された物理接続の数。 |
numconndestroyed |
CountStatistic |
前回のリセット後に破棄された物理接続の数。 |
numconnacquired |
CountStatistic |
前回のサンプリング以降に、プールから取得された論理接続の数。 |
numconnreleased |
CountStatistic |
前回のサンプリング以降に、プールに戻された接続の数。 |
numconnnotsuccessfullymatched |
CountStatistic |
マッチング中に拒否された接続の数。 |
numconnsuccessfullymatched |
CountStatistic |
マッチングに成功した接続の数。 |
numpotentialconnleak |
CountStatistic |
潜在的な接続リークの数。 |
waitqueuelength |
CountStatistic |
キュー内で処理されるのを待機している接続要求の数。 |
セキュリティーは、「セキュリティーのツリー階層」に示したオブジェクトツリー内に含まれます。
セキュリティーに関して利用可能な統計を、次の節で説明します。
EJB セキュリティーの統計では、次のドット表記名パターンを使用します。
server.security.ejb.statistic
EJB セキュリティーに関して利用可能な統計を、次の表に示します。
表 8–30 EJB セキュリティーの監視統計
Statistic |
データ型 |
説明 |
---|---|---|
policyconfigurationcount |
CountStatistic |
ポリシー構成の数。 |
securitymanagercount |
CountStatistic |
EJB セキュリティーマネージャーの数。 |
Web セキュリティーの統計では、次のドット表記名パターンを使用します。
server.security.web.statistic
Web セキュリティーに関して利用可能な統計を、次の表に示します。
表 8–31 Web セキュリティーの監視統計
Statistic |
データ型 |
説明 |
---|---|---|
websecuritymanagercount |
CountStatistic |
セキュリティーマネージャーの数。 |
webpolicyconfigurationcount |
CountStatistic |
ポリシー構成オブジェクトの数。 |
レルムセキュリティーの統計では、次のドット表記名パターンを使用します。
server.security.realm.statistic
レルムセキュリティーに関して利用可能な統計を、次の表に示します。
表 8–32 レルムセキュリティーの監視統計
Statistic |
データ型 |
説明 |
---|---|---|
realmcount |
CountStatistic |
レルムの数。 |
スレッドプールは、「スレッドプールのツリー階層」に示したオブジェクトツリー内に含まれます。
スレッドプールに関して利用可能な統計を、次の節で説明します。
スレッドプールの統計では、次のドット表記名パターンを使用します。
server.thread-pool.thread-pool.statistic
スレッドプールに関して利用可能な統計を、次の表に示します。
表 8–33 スレッドプールの監視統計
Statistic |
データ型 |
説明 |
---|---|---|
averagetimeinqueue |
BoundedRangeStatistic |
キュー内の要求が処理されるまでの平均待ち時間 (ミリ秒)。 |
averageworkcompletiontime |
BoundedRangeStatistic |
割り当てが完了するまでの平均時間 (ミリ秒)。 |
currentbusythreads |
CountStatistic |
ビジースレッドの数。 |
currentnumberofthreads |
BoundedRangeStatistic |
要求処理スレッドの現在の数。 |
numberofavailablethreads |
CountStatistic |
使用可能なスレッドの数。 |
numberofworkitemsinqueue |
BoundedRangeStatistic |
キューで待機している作業項目の現在の数。 |
totalworkitemsadded |
CountStatistic |
前回のサンプリング以降に、作業キューに追加された作業項目の合計。 |
Java SE の JVM で利用可能な ThreadInfo 関連の統計を、次の図に示します。
表 8–34 Java SE に関する JVM の監視統計 - スレッド情報
Statistic |
データ型 |
説明 |
---|---|---|
blockedcount |
CountStatistic |
このスレッドが BLOCKED 状態に入った合計回数。 |
blockedtime |
CountStatistic |
このスレッドが BLOCKED 状態に入ったあと経過した時間 (ミリ秒)。スレッド競合監視が無効になっている場合は、-1 が返されます。 |
lockname |
StringStatistic |
このスレッドが獲得をブロックされている監視ロック、またはこのスレッドが Object.wait メソッド経由で通知されるのを待っている監視ロックの文字列表現。 |
lockownerid |
CountStatistic |
このスレッドのブロック対象オブジェクトの監視ロックを保持しているスレッドの ID。 |
lockownername |
StringStatistic |
このスレッドのブロック対象オブジェクトの監視ロックを保持しているスレッドの名前。 |
stacktrace |
StringStatistic |
このスレッドに関連付けられているスタックトレース。 |
threadid |
CountStatistic |
スレッドの ID。 |
threadname |
StringStatistic |
スレッドの名前 |
threadstate |
StringStatistic |
スレッドの状態。 |
waitedtime |
CountStatistic |
スレッドが WAITING 状態に入ったあと経過した時間 (ミリ秒)。スレッド競合監視が無効になっている場合は、-1 が返されます。 |
waitedcount |
CountStatistic |
スレッドが WAITING 状態または TIMED_WAITING 状態になった合計回数。 |
トランザクションサービスを使用すると、クライアントはトランザクションサブシステムをフリーズして、トランザクションをロールバックしたり、フリーズ時点で処理中であったトランザクションを特定することができます。トランザクションサービスは、「トランザクションサービスのツリー階層」に示したオブジェクトツリー内に含まれます。
トランザクションサービスの統計では、次のドット表記名パターンを使用します。
server.transaction-service.statistic
トランザクションサービスに関して利用可能な統計を、次の表に示します。
表 8–35 トランザクションサービスの監視統計
Statistic |
データ型 |
説明 |
---|---|---|
activecount |
CountStatistic |
現在アクティブなトランザクションの数。 |
activeids |
StringStatistic |
現在アクティブなトランザクションの ID。それらの各トランザクションは、トランザクションサービスのフリーズ後にロールバックすることができます。 |
committedcount |
CountStatistic |
コミットされたトランザクションの数。 |
rolledbackcount |
CountStatistic |
ロールバックされたトランザクションの数。 |
state |
StringStatistic |
トランザクションがフリーズされたかどうかを示します。 |
Web モジュールは、「Web のツリー階層」に示したオブジェクトツリー内に含まれます。
Web モジュールサーブレットの統計では、次のドット表記名パターンを使用します。
server.applications.web-module.virtual-server.servlet.statistic server.applications.application.web-module.virtual-server.servlet.statistic
利用可能な Web モジュールサーブレットの統計を、次の表に示します。
表 8–36 Web モジュールサーブレットの統計
Statistic |
データ型 |
説明 |
---|---|---|
errorcount |
CountStatistic |
応答コードが 400 以上になった場合の累計件数。 |
maxtime |
CountStatistic |
Web コンテナの要求待ち状態の最大継続時間。 |
processingtime |
CountStatistic |
各要求の処理に要した時間の累計値。この処理時間は、要求処理時間を要求数で割って得られた平均値です。 |
requestcount |
CountStatistic |
その時点までに処理された要求の合計数。 |
servicetime |
CountStatistic |
応答時間の総計 (ミリ秒)。 |
Web JSP の統計では、次のドット表記名パターンを使用します。
server.applications.web-module.virtual-server.statistic server.applications.application.web-module.virtual-server.statistic
利用可能な Web JSP 統計を、次の表に示します。
表 8–37 Web JSP の監視統計
Statistic |
データ型 |
説明 |
---|---|---|
jspcount-current |
RangeStatistic |
アクティブな JSP ページの数。 |
jsperrorcount |
CountStatistic |
JSP ページの呼び出しでトリガーされたエラーの合計数。 |
jspreloadedcount |
CountStatistic |
再読み込みされた JSP ページの合計数。 |
totaljspcount |
CountStatistic |
これまでに読み込まれた JSP ページの合計数。 |
Web 要求の統計では、次のドット表記名パターンを使用します。
server.applications.web-module.virtual-server.statistic server.applications.application.web-module.virtual-server.statistic
利用可能な Web 要求統計を、次の表に示します。
表 8–38 Web 要求の監視統計
Statistic |
データ型 |
説明 |
---|---|---|
errorcount |
CountStatistic |
エラー回数の累計値。エラー回数は、応答コードが 400 以上になった場合の回数を表します。 |
maxtime |
CountStatistic |
要求あたりの最長応答時間です。累積値ではなく、応答時間の中で最大の値です。 |
processingtime |
CountStatistic |
平均要求処理時間 (ミリ秒)。 |
requestcount |
CountStatistic |
現時点までに処理された要求の累積数。 |
Web サーブレットの統計では、次のドット表記名パターンを使用します。
server.applications.web-module.virtual-server.statistic server.applications.application.web-module.virtual-server.statistic
利用可能な Web サーブレットの統計を、次の表に示します。
表 8–39 Web サーブレットの監視統計
Statistic |
データ型 |
説明 |
---|---|---|
activeservletsloadedcount |
RangeStatistic |
現在読み込まれているサーブレットの数。 |
servletprocessingtimes |
CountStatistic |
サーブレット処理時間の累積値 (ミリ秒)。 |
totalservletsloadedcount |
CountStatistic |
Web モジュールに読み込まれたサーブレットの累積数。 |
Web セッションの統計では、次のドット表記名パターンを使用します。
server.applications.web-module.virtual-server.statistic server.applications.application.web-module.virtual-server.statistic
利用可能な Web セッションの統計を、次の表に示します。
表 8–40 Web セッションの監視統計
Statistic |
データ型 |
説明 |
---|---|---|
activatedsessionstotal |
CountStatistic |
アクティブ化されたセッションの合計数。 |
activesessionscurrent |
RangeStatistic |
現在のアクティブセッションの数。 |
activesessionshigh |
CountStatistic |
現在のアクティブセッションの最大数。 |
expiredsessionstotal |
CountStatistic |
期限切れセッションの合計数。 |
passivatedsessionstotal |
CountStatistic |
パッシブ化されたセッションの合計数。 |
persistedsessionstotal |
CountStatistic |
持続化されたセッションの合計数。 |
rejectedsessionstotal |
CountStatistic |
拒否されたセッションの合計数。 |
sessionstotal |
CountStatistic |
作成されたセッションの合計数。 |
Java SE には、MBean Server に接続し、サーバーに登録されている MBean を表示するためのツールが用意されています。JConsole は一般的な JMX コネクタクライアントであり、標準 Java SE ディストリビューションの一部として利用できます。Enterprise Server で使用できるように JConsole を設定すると、Enterprise Server は JMX コネクタのサーバー側となり、JConsole は JMX コネクタのクライアント側となります。
Java SE 6 では、Platform MBean Server を含めること、および仮想マシンを設定するための管理対象 Bean (MBean) を含めることにより、仮想マシンの管理と監視を拡張します。
すべての MBean を表示するために、Enterprise Server にはシステム JMX コネクタサーバーという標準 JMX コネクタサーバーの構成が用意されています。Enterprise Server の起動時に、この JMX コネクタサーバーのインスタンスが起動します。規格に準拠する JMX コネクタクライアントはすべて、JMX コネクタサーバーを使用してサーバーに接続できます。
デフォルトでは、Enterprise Server はセキュリティー保護されていないシステム JMX コネクタサーバーを使用するように設定されています。この設定で問題がある場合は、JMX コネクタを削除できます。ただし、address を locahost に設定することにより、特定の IP アドレス (たとえば、ループバックアドレス) へのアクセスが制限される場合があります。
ドメインを起動します。
手順については、「ドメインの起動」を参照してください。
JDK_HOME /bin/jconsole の形式を使用して、JConsole を起動します。
次に例を示します。
/usr/java/bin/jconsole |
JConsole の「Connect to Agent」ウィンドウが表示されます。
「リモート」タブをクリックし、ホスト名とポート番号を入力します。
JConsole には常にリモートで接続してください。リモート以外で接続した場合は、MBean が自動的に読み込まれません。
「接続」をクリックします。
「Remote Process」テキストボックスに、JMX サービス URL を指定します。
次に例を示します。
service:jmx:rmi:///jndi/rmi://localhost:8686/jmxrmi |
JMX サービス URL は、サーバーによって起動時に発行され、次のような形式になります。
[#|2009-12-03T10:25:17.737-0800|INFO|glassfishv3.0| javax.enterprise.system.tools.admin.org.glassfish.server|_ThreadID=20; _ThreadName=Thread-26;|JMXStartupService: Started JMXConnector, JMXService URL = service:jmx:rmi://localhost:8686/jndi/rmi://localhost:8686/jmxrmi|#] |
ただし、ほとんどの場合は、簡単に host:port (192.168.1.150:8686 など) を入力するだけで十分です。長いサービス URL は必要ありません。
localhost の代わりに別のホスト名を指定することもできます。jmx-connector の構成が変更されている場合は、デフォルトのポート番号 (8686) が変更されている場合があります。
「接続」をクリックします。
JConsole ウィンドウの各種タブに、MBean、JVM 情報などが表示されます。監視に利用できる MBean のほとんどは、amx および java.lang ドメインにあります。
JConsole の詳細は、http://java.sun.com/javase/6/docs/technotes/guides/management/jconsole.html を参照してください。
この章では、Sun GlassFishTMEnterprise Server v3 環境でライフサイクルモジュールを管理する手順について説明します。
ここでは、次のテーマを取り上げます。
本章で説明するタスクを管理コンソールから実行する手順については、管理コンソールのオンラインヘルプを参照してください。
「ライフサイクルモジュール」は初期化サービスとも呼ばれ、Enterprise Server 環境内で短期的または長期的な Java ベースタスクを実行する手段として利用できます。これらのモジュールはサーバーの起動時に自動的に開始され、サーバーのライフサイクルのさまざまな段階で通知を受け取ります。ライフサイクルモジュールの設定済みのプロパティーは、サーバーの初期化中にプロパティーとして渡されます。
ライフサイクルモジュールのすべてのクラスとインタフェースは、as-install /glassfish/modules/glassfish-api.jar ファイルに格納されています。
ライフサイクルモジュールは次の Enterprise Server イベントを待機し、イベントに応じてタスクを実行します。
「初期化」。サーバーは構成を読み取り、組み込みサブシステム (セキュリティーサービスやロギングサービス) を初期化して、コンテナを作成します。
「起動」。サーバーは配備されたアプリケーションを読み込んで初期化します。
「実行可能」。サーバーは要求の処理を開始します。
「シャットダウン」。サーバーはアプリケーションをシャットダウンして停止します。
「終了」。サーバーはコンテナ、組み込みサブシステム、およびサーバー実行環境を終了します。
これらのイベントは LifecycleEvent クラスで定義されます。ライフサイクルモジュールの作成については、『Sun GlassFish Enterprise Server v3 Application Development Guide』の第 13 章「Developing Lifecycle Listeners」を参照してください。
is-failure-fatal 設定が true に設定されている場合は (デフォルトでは false)、ライフサイクルモジュールで障害が発生したときにサーバーの初期化または起動が中止されます。ただし、シャットダウンまたは終了は実行されます。
ここでは、次のテーマを取り上げます。
ライフサイクルモジュールを作成するには、リモートモードで create-lifecycle-module サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
create-lifecycle-module(1) サブコマンドを使用して、新しいライフサイクルモジュールを作成します。
サブコマンドのオプションとプロパティーについては、このマニュアルページに記載されています。
サーバーを再起動して、変更を有効にします。
「ドメインの再起動」を参照してください。
この例では、customSetup というライフサイクルモジュールを作成します。
asadmin> create-lifecycle-module --classname "com.acme.CustomSetup" --classpath "/export/customSetup" --loadorder 1 --failurefatal=true --description "this is a sample customSetup" --property rmi="Server\=acme1\:7070":timeout=30 customSetup Command create-lifecycle-module executed successfully |
コマンド行に asadmin help create-lifecycle-module と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
既存のライフサイクルモジュールを一覧表示するには、リモートモードで list-lifecycle-modules サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-lifecycle-modules(1) サブコマンドを使用して、ライフサイクルモジュールを一覧表示します。
この例では、既存のライフサイクルモジュールを一覧表示します。
asadmin> list-lifecycle-modules WSTCPConnectorLCModule Command list-lifecycle-modules executed successfully |
コマンド行に asadmin help list-lifecycle-modules と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
set サブコマンドを使用して、既存のライフサイクルモジュールを更新します。
get(1) サブコマンドを使用して、ライフサイクルモジュールの更新可能なプロパティーを一覧表示します。
次に例を示します (シングルモード)。
asadmin get "*" | grep sampleLCM applications.application.sampleLCMmodule.availability-enabled=false applications.application.sampleLCMmodule.directory-deployed=false applications.application.sampleLCMmodule.enabled=true applications.application.sampleLCMmodule.name=sampleLCMmodule applications.application.sampleLCMmodule.object-type=user applications.application.sampleLCMmodule.property.class-name=example.lc.SampleModule applications.application.sampleLCMmodule.property.classpath=/build/lcm.jar applications.application.sampleLCMmodule.property.is-failure-fatal=false applications.application.sampleLCMmodule.property.isLifecycle=true |
set(1) サブコマンドを使用して、ライフサイクルモジュールを更新します。
サーバーを再起動して、変更を有効にします。
「ドメインの再起動」を参照してください。
この例では、classpath プロパティーを更新します。
sadmin> set applications.application.sampleLCMmodule. property.classpath=/build/lcm_new.jarapplications.application. sampleLCMmodule.property.classpath=/build/lcm_new.jarCommand set executed successfully. |
コマンド行に asadmin help set と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
ライフサイクルモジュールを削除するには、リモートモードで delete-lifecycle-module サブコマンドを使用します。
サーバーが実行されていることを確認します。
リモートサブコマンドには、実行中のサーバーが必要です。
list-lifecycle-modules(1) サブコマンドを使用して、現在のライフサイクルモジュールを一覧表示します。
delete-lifecycle-module(1) サブコマンドを使用して、ライフサイクルモジュールを削除します。
この例では、customSetup というライフサイクルモジュールを削除します。
asadmin> delete-lifecycle-module customSetup Command delete-lifecycle-module executed successfully |
コマンド行に asadmin help delete-lifecycle-module と入力して、このサブコマンドの完全な構文とオプションを確認することもできます。
この章では、配備された Sun GlassFishTM Enterprise Server v3 の拡張および更新に関するタスクを、更新ツールを使用して実行する手順を説明します。pkg コマンドを使用する手順もこの章で説明します。Enterprise Server には、pkg コマンドの使用方法を説明するリファレンスページが用意されています。
ここでは、次のテーマを取り上げます。
この章のタスクを管理コンソールを使用して実行する場合の手順は、管理コンソールオンラインヘルプの更新ツールの項目で説明します。スタンドアロンの更新ツールにも、オンラインヘルプが用意されています。更新ツールの詳細は、http://wikis.sun.com/display/IpsBestPractices/Screenshots を参照してください。
Enterprise Server は、機能をモジュール形式で提供するように設計されています。したがって、必要な機能だけをインストールして、必要がない機能のインストールは省略することができます。「OSGi モジュール」は、バンドルとも呼ばれ、配備した Enterprise Server にアドオン機能を提供します。サーバーの再起動を必要とせず、実行時にアドオンコンポーネントを追加または削除することができます。
時間の経過とともに、新しいアドオンコンポーネントが開発され、既存のコンポーネントは変更されていきます。Enterprise Server では、配備したサーバー上のソフトウェアを更新できるように、一連の Image Packaging System (IPS) ツールが提供されています。更新ツールを次の方法で使用して、新しいアドオンコンポーネンや更新されたアドオンコンポーネントをインストールできます。
グラフィカルな Enterprise Server 管理コンソール で選択して起動します。
コマンド行から開始できるスタンドアロンのグラフィカルツールとして起動します。コマンドの形式は、as-install-parent /bin/updatetool です。
コマンド行ユーティリティー (pkg コマンド) として起動します。グラフィカルな更新ツールで実行できるほとんどのタスクを実行できます。pkg コマンドを使用する主な理由は次のとおりです。
グラフィカルなバージョンの更新ツールには、どちらにも詳細なオンラインヘルプが用意されています。
この節では、pkg コマンドを使用して、配備済みの Enterprise Server に Enterprise Server アドオンコンポーネントをインストールする手順について説明します。
pkg コマンドを使用して、アドオンコンポーネントをシステムにインストールできます。複数のバージョンのパッケージを使用できる場合は、指定しないかぎり最新のバージョンが適用されます。pkg コマンドは、as-install-parent/bin ディレクトリに格納されています。
pkg コンポーネント、updatetool コンポーネント、またはコマンド行から呼び出すその他の有効なコンポーネントが、配備済みの Enterprise Server にまだインストールされていない場合は、コンポーネントをインストールするかどうかを確認するメッセージが表示されます。「Y」を入力すると、コンポーネントがインストールされます。
追加コンポーネントをインストールする前に、Enterprise Server v3 が完全に配備されている必要があります。インストールの手順については、『Sun GlassFish Enterprise Server v3 Installation Guide 』を参照してください。
インストール済みのコンポーネントを一覧表示します。
pkg list |
次のような情報が表示されます。
NAME (AUTHORITY) VERSION STATE UFIX glassfishv3-common 0-1 installed ---- glassfishv3-ejb 0-1 installed u--- glassfishv3-nucleus 0-1 installed ---- glassfishv3-web 0-1 installed ---- grails 1.0-1.0 installed ---- jersey 0.7-0.1 installed u--- jmaki 1.8.0-1.0 installed ---- jruby 1.1.1-1.0 installed ---- metro 1.2-1 installed u--- pkg 0.1.4-6.564 installed u--- python2.4-minimal 2.4.4-6.564 installed u--- updatetool (glassfish.org) 2.0-6.564 installed u--- wxpython2.8-minimal 2.8.7.1-6.564 installed u---
使用可能なパッケージをすべて表示します。
pkg list -a |
リポジトリから次のような情報が表示されます。
NAME (AUTHORITY) VERSION STATE UFIX glassfishv3-common 0-1 known u--- glassfishv3-common 0-1 known u--- glassfishv3-common 0-1 installed ---- glassfishv3-ejb 0-1 known u--- glassfishv3-ejb 0-1 known u--- glassfishv3-ejb 0-1 known u--- glassfishv3-ejb 0-1 installed u--- glassfishv3-ejb 0-1 known ---- glassfishv3-nucleus 0-1 known u--- glassfishv3-nucleus 0-1 known u--- glassfishv3-nucleus 0-1 installed ---- glassfishv3-web 0-1 known u--- glassfishv3-web 0-1 known u--- glassfishv3-web 0-1 installed ---- grails 1.0-1.0 installed ---- javadb 0-1 known u--- javadb 0-1 known u--- javadb 0-1 known ---- jersey 0.7-0.1 installed u--- jersey 0.7-0.2 known u--- jersey 0.7-0.3 known u--- jersey 0.8-0.1 known ---- jmaki 1.8.0-1.0 installed ---- jruby 1.1.1-1.0 installed ---- metro 1.2-1 installed u--- metro 1.2-2 known u--- metro 1.2-3 known ---- pkg 0.1.4-6.564 installed u--- pkg 0.1.5-8.724 known ---- python2.4-minimal 2.4.4-6.564 installed u--- python2.4-minimal 2.4.4-8.724 known ---- updatetool 2.0-6.564 installed u--- updatetool 2.0-8.724 known ---- wxpython2.8-minimal 2.8.7.1-6.564 installed u--- wxpython2.8-minimal 2.8.7.1-8.724 known ----
as-install ディレクトリに移動します。
使用可能なパッケージのリストから、パッケージをインストールします。
pkg install package-name という構文を使用します。次に例を示します。
pkg install javadb |
コンポーネントの最新のバージョンがインストールされ、次のような情報が表示されます。
DOWNLOAD PKGS FILES XFER (MB) javadb 0/1 61/200 2.10/7.26 PHASE ACTIONS Install Phase 222/222
変更内容を適用するために、Enterprise Server を再起動します。
「ドメインの再起動」を参照してください。
pkg コマンドを使用する際の完全な構文とオプションは、as-install/pkg/man/ ディレクトリにあるリファレンスページで説明されています。これらのリファレンスページは、man コマンドでは表示されません。代わりに、more または cat などのコマンドを使用してください。
この節では、Enterprise Server のコンポーネントをインストールしたあとに、これらのコンポーネントを更新する次の手順について説明します。
更新されたバージョンのコンポーネントをインストールする場合は、変更されたファイルだけがダウンロードおよびインストールされます。更新されたパッケージで削除されているファイルは、更新プロセス中に削除されます。
使用可能な更新があるインストール済みのパッケージだけを一覧表示します。
pkg list -u |
次のような情報が表示されます。
NAME (AUTHORITY) VERSION STATE UFIX glassfishv3-ejb 0-1 installed u--- jersey 0.7-0.1 installed u--- metro 1.2-1 installed u--- pkg 0.1.4-6.564 installed u--- python2.4-minimal 2.4.4-6.564 installed u--- updatetool (glassfish.org) 2.0-6.564 installed u--- wxpython2.8-minimal 2.8.7.1-6.564 installed u---
新しいバージョンのパッケージをインストールします。
pkg install package-name という構文を使用します。次に例を示します。
pkg install metro |
次のような情報が表示されます。
DOWNLOAD PKGS FILES XFER (MB) Completed 1/1 5/5 0.49/0.49 PHASE ACTIONS Removal Phase 2/2 Update Phase 7/7 Install Phase 2/2
変更内容を適用するために、Enterprise Server を再起動します。
「ドメインの再起動」を参照してください。
pkg コマンドを使用する際の完全な構文とオプションは、as-install /pkg/man/ ディレクトリにあるリファレンスページで説明されています。これらのリファレンスページは、man コマンドでは表示されません。代わりに、more または cat などのコマンドを使用してください。
Enterprise Server では、単一のシステムで複数のインストールイメージを保守できます。インストールイメージを更新するときに、イメージ内にあるすべてのコンポーネントは、新しいバージョンを利用できる場合、そのバージョンに更新されます。更新されたバージョンのコンポーネントをインストールするときに、変更されたファイルだけがダウンロードおよびインストールされます。更新されたパッケージで削除されているファイルは、更新プロセス中に削除されます。
イメージのすべてのパッケージをインストールします。
pkg install image-name の構文を使用します。次に例を示します。
pkg image-update |
次のような情報が表示されます。
DOWNLOAD PKGS FILES XFER (MB) Completed 6/6 729/729 21.59/21.59 PHASE ACTIONS Removal Phase 887/887 Update Phase 253/253 Install Phase 584/584
変更内容を適用するために、Enterprise Server を再起動します。
「ドメインの再起動」を参照してください。
pkg コマンドを使用する際の完全な構文とオプションは、as-install /pkg/man/ ディレクトリにあるリファレンスページで説明されています。これらのリファレンスページは、man コマンドでは表示されません。代わりに、more または cat などのコマンドを使用してください。
使用していないコンポーネントをシステムから削除する場合は、uninstall コマンドを使用します。コンポーネントを以前のバージョンに戻す必要がある場合は、現在のバージョンをアンインストールしたあとに、バージョン番号を指定して以前のバージョンをインストールする必要があります。
インストール済みのコンポーネントを削除する前に、削除するコンポーネントに依存関係がないことを確認します。
インストール済みのコンポーネントをすべて表示します。
pkg list |
NAME (AUTHORITY) VERSION STATE UFIX glassfishv3-common 0-1 installed ---- glassfishv3-ejb 0-1 installed u--- glassfishv3-nucleus 0-1 installed ---- glassfishv3-web 0-1 installed ---- grails 1.0-1.0 installed ---- jersey 0.7-0.1 installed u--- jmaki 1.8.0-1.0 installed ---- jruby 1.1.1-1.0 installed ---- metro 1.2-1 installed u--- pkg 0.1.4-6.564 installed u--- python2.4-minimal 2.4.4-6.564 installed u--- updatetool (glassfish.org) 2.0-6.564 installed u--- wxpython2.8-minimal 2.8.7.1-6.564 installed u---
システムから削除するコンポーネントをアンインストールします。
pkg uninstall package-name の構文を使用します。次に例を示します。
pkg uninstall jruby |
変更内容を適用するために、Enterprise Server を再起動します。
「ドメインの再起動」を参照してください。
pkg コマンドを使用する際の完全な構文とオプションは、as-install /pkg/man/ ディレクトリにあるリファレンスページで説明されています。これらのリファレンスページは、man コマンドでは表示されません。代わりに、more または cat などのコマンドを使用してください。
インストールしたコンポーネントが正しく動作しない場合は、コンポーネントを古いバージョンに戻すことができます。古いバージョンのコンポーネントを復元するには、現在のバージョンのコンポーネントをアンインストールしたあと、元に戻す古いバージョンをインストールします。
現在のバージョンのコンポーネントをアンインストールする前に、古いバージョンのコンポーネントがリポジトリにあることを確認する必要があります。
古いバージョンのコンポーネントがまだ使用可能であることを確認します。
pkg list -a |
インストール済みのコンポーネントを一覧表示します。
pkg list |
置換対象の現在インストールされているコンポーネントをアンインストールします。
pkg uninstall package-name の構文を使用します。次に例を示します。
pkg uninstall jersey |
古いバージョンのコンポーネントをインストールします。
pkg install package-name —version version-number の構文を使用します。次に例を示します。
pkg install jersey -version 0.7-0.2 |
古いバージョンがインストールされたことを確認します。
pkg list |
pkg コマンドを使用する際の完全な構文とオプションは、as-install /pkg/man/ ディレクトリにあるリファレンスページで説明されています。これらのリファレンスページは、man コマンドでは表示されません。代わりに、more または cat などのコマンドを使用してください。