管理および設定ガイド


Red Hat JBoss Enterprise Application Platform 6.4

Red Hat JBoss Enterprise Application Platform 6 向け

概要

本書は、Red Hat JBoss Enterprise Application Platform 6 およびそのパッチリリースに関する管理および設定ガイドです。

第1章 はじめに

1.1. Red Hat JBoss Enterprise Application Platform 6

Red Hat JBoss Enterprise Application Platform 6(JBoss EAP 6)は、オープン標準に構築されたミドルウェアプラットフォームで、Java Enterprise Edition 6 仕様に準拠します。JBoss Application Server 7 と高可用性クラスタリング、メッセージング、分散キャッシングなどのテクノロジーを統合します。
JBoss EAP 6 には、必要な場合にのみサービスを有効にできる新しいモジュラー構造が含まれ、起動速度が改善されます。
管理コンソールと管理コマンドラインインターフェースにより、XML 設定ファイルの編集が不必要になり、タスクをスクリプト化および自動化する機能が追加されました。
また、JBoss EAP 6 には、セキュアでスケーラブルな Java EE アプリケーションの迅速な開発を可能にする API と開発フレームワークが含まれます。

1.2. JBoss EAP 6 の機能

Expand
表1.1 JBoss EAP 6 の機能
機能 説明
Java 証明書 認定された Java Enterprise Edition 6 の Full Profile と Web Profile。
管理対象ドメイン
  • 複数のサーバーインスタンスおよび物理ホストを一元管理し、スタンドアロンサーバーで単一のサーバーインスタンスを使用することを可能にします。
  • 設定、デプロイメント、ソケットバインディング、モジュール、拡張機能、およびシステムプロパティーをサーバーグループごとに管理します。
  • アプリケーションのセキュリティー (セキュリティードメインを含む) の管理を一元化および簡略化します。
管理コンソールおよび管理 CLI 新しいドメインまたはスタンドアロンサーバー管理インターフェースです。XML 設定ファイルの編集は不要になりました。管理 CLI には、管理タスクをスクリプト化および自動化できるバッチモードも含まれています。
簡素化されたディレクトリーのレイアウト modules ディレクトリーにすべてのアプリケーションサーバーモジュールが含まれるようになりました。共通ディレクトリーおよびサーバー固有の lib ディレクトリーは非推奨になりました。ドメイン ディレクトリーと スタンドアロン ディレクトリーには、それぞれドメインデプロイメントとスタンドアロンデプロイメントのアーティファクトおよび設定ファイルが含まれます。
モジュラークラスローディングメカニズム モジュールは必要に応じてロードおよびアンロードされます。これにより、パフォーマンスが向上します。
簡略化されたデータソース管理 データベースドライバーは他のサービスと同様にデプロイされます。さらに、データソースは管理コンソールまたは管理 CLI で直接作成および管理されます。
リソース使用の削減と効率化 JBoss EAP 6 はより少ないシステムリソースを使用し、以前のバージョンよりも効率的に使用します。その他の利点の他にも、JBoss EAP 6 は JBoss EAP 5 よりも起動および停止します。

1.3. JBoss EAP 6 の操作モード

JBoss EAP 6 は、JBoss EAP 6 インスタンスに対してスタンドアローンサーバーと管理対象ドメインの 2 つの操作モードを提供します。
2 つのモードはサーバーの管理方法が異なりますが、エンドユーザーの要求に対応する能力ではありません。高可用性(HA)クラスター機能は、どちらの操作モードでも利用できることに注意してください。スタンドアロンサーバーのグループは、HA クラスターを形成するように設定できます。

1.4. スタンドアロンサーバー

スタンドアロンサーバーモードは独立したプロセスで、以前のバージョンの JBoss EAP で唯一存在した実行モードと似ています。
スタンドアロンサーバーとして実行する JBoss EAP のインスタンスは単一インスタンスのみですが、オプションとしてクラスター化された設定で実行することも可能です。

1.5. 管理対象ドメイン

図1.1 管理対象ドメインを表す図

管理対象ドメイン操作モードでは、単一の制御点から複数の JBoss EAP 6 インスタンスを管理できます。
一元管理された JBoss EAP 6 サーバーは、ドメインのメンバーと呼ばれます。ドメインの JBoss EAP 6 インスタンスはすべて共通の管理ポリシーを共有します。
各ドメインは 1 つの<firstterm>ドメインコントローラー</firstterm>、1 つ以上の<firstterm>ホストコントローラー</firstterm>、およびホスト毎に 0 個以上のサーバーグループによって構成されます。
ドメインコントローラーは、ドメインが制御される中心点です。ドメインの管理ポリシーに従って各サーバーが設定されるようにします。ドメインコントローラーはホストコントローラーでもあります。
ホストコントローラーは、domain.sh または domain.bat スクリプトが実行される物理ホストまたは仮想ホストです。ホストコントローラーは、ドメイン管理タスクをドメインコントローラーに委譲するように設定されています。
各ホスト上のホストコントローラーはドメインコントローラーと対話し、ホスト上で実行されているアプリケーションサーバーインスタンスのライフサイクルを制御し、ドメインコントローラーがそれらを管理できるようにします。各ホストに複数のサーバーグループが含まれるようにすることが可能です。
サーバーグループとは、JBoss EAP 6 が JBoss EAP 6 がインストールされ、1 つとして管理および設定されるサーバーインスタンスのセットです。ドメインコントローラーはサーバーグループにデプロイされたアプリケーションとその設定を管理します。そのため、サーバーグループの各サーバーは同じ設定とデプロイメントを共有します。
同じ物理システム上の同じ JBoss EAP 6 インスタンス内で、単一のドメインコントローラー、単一のホストコントローラー、および複数のサーバーを実行できます。
ホストコントローラーは特定の物理(または仮想)ホストに割り当てられます。異なる設定を使用する場合は、同じハードウェア上で複数のホストコントローラーを実行でき、ポートとその他のリソースが競合しないようにします。

1.6. ドメインコントローラー

ドメインコントローラーは、ドメインの集中管理点として動作する JBoss EAP 6 サーバーインスタンスです。1 つのホストコントローラーインスタンスがドメインコントローラーとして動作するよう設定されます。
ドメインコントローラーの主な役割は次のとおりです。
  • ドメインの集中管理ポリシーを維持する。
  • すべてのホストコントローラーが現在のコンテンツを認識するようにする。
  • 実行中のすべての JBoss EAP 6 インスタンスがこのポリシーに従って設定されるよう、ホストコントローラーをサポートする。
デフォルトでは、集中管理ポリシーは domain/configuration/domain.xml ファイルに保存されます。このファイルは、ドメインコントローラーのホストのファイルシステムに展開した JBoss EAP 6 インストールファイルにあります。
domain.xml ファイルは、ドメインコントローラーとして実行するよう設定されたホストコントローラーの domain/configuration/ ディレクトリーに配置する必要があります。このファイルは、ドメインコントローラーとして実行されないホストコントローラーへのインストールには必要ありません。このようなサーバーに domain.xml ファイルが存在すると、害はありません。
domain.xml ファイルには、ドメインのサーバーインスタンスで実行できるプロファイル設定が含まれています。プロファイル設定には、プロファイルを構成するさまざまなサブシステムの詳細設定が含まれます。ドメイン設定には、ソケットグループの定義とサーバーグループの定義も含まれます。

1.7. ドメインコントローラーの検索およびフェールオーバー

管理対象ドメインの設定時、ドメインコントローラーに接続するために必要な情報を使用して各ホストコントローラーを設定する必要があります。JBoss EAP 6 では、ドメインコントローラーを検索する複数のオプションを使用して各ホストコントローラーを設定できます。ホストコントローラーは、適切なオプションが見つかるまでオプションのリストを繰り返し処理します。
これにより、バックアップドメインコントローラーのコンタクト情報とともにホストコントローラーを事前設定できます。プライマリードメインコントローラーに問題がある場合は、バックアップホストコントローラーをマスターに昇格でき、昇格後にホストコントローラーを新規マスターに自動的にフェイルオーバーできます。
以下は、ドメインコントローラー検索の複数のオプションを持つホストコントローラーを設定する方法の例になります。

例1.1 複数のドメインコントローラーオプションで設定されたホストコントローラー

<domain-controller>  
    <remote security-realm="ManagementRealm">  
          <discovery-options>  
              <static-discovery name="primary" host="172.16.81.100" port="9999"/>  
              <static-discovery name="backup" host="172.16.81.101" port="9999"/>  
          </discovery-options>  
    </remote>  
</domain-controller>
Copy to Clipboard Toggle word wrap
静的検出オプションには、以下の必須属性が含まれます。

name
このドメインコントローラー検索オプションの名前。
host
リモートドメインコントローラーのホスト名。
port
リモートドメインコントローラーのポート。
上記の例では、最初の検出オプションが指定されることが予想されます。2 つ目のオプションはフフェイルオーバーの状況で使用される可能性があります。
プライマリードメインコントローラーで問題が発生した場合、--backup オプションで開始されたホストコントローラーを昇格してドメインコントローラーとして動作することができます。
注記
--backup オプションを指定してホストコントローラーを起動すると、そのコントローラーはドメイン設定のローカルコピーを維持します。この設定は、ホストコントローラーがドメインコントローラーとして動作するよう再設定された場合に使用されます。

手順1.1 ホストコントローラーを昇格してドメインコントローラーにする

  1. 元のドメインコントローラーが停止した状態であることを確認します。
  2. 管理 CLI を使用して、新しいドメインコントローラーとなるホストコントローラーへ接続します。
  3. 以下のコマンドを実行してホストコントローラーを設定し、新しいドメインコントローラーとして動作するようにします。
    /host=HOST_NAME:write-local-domain-controller
    Copy to Clipboard Toggle word wrap
  4. 以下のコマンドを実行し、ホストコントローラーをリロードします。
    reload --host=HOST_NAME
    Copy to Clipboard Toggle word wrap
2. で選択したホストコントローラーがドメインコントローラーとして動作するようになります。

1.8. ホストコントローラー

ホストコントローラーは、domain.sh または domain.bat スクリプトをホストで実行する際に起動します。
ホストコントローラーの主な役割はサーバーを管理することです。ドメイン管理タスクを委譲し、ホスト上で実行される個別のアプリケーションサーバープロセスを開始および停止します。
ホストコントローラーはドメインコントローラーと対話し、サーバーとドメインコントローラー間の通信を管理できるようにします。ドメインの複数のホストコントローラーは 1 つのドメインコントローラーのみと対話できます。そのため、単一のドメインモード上で実行されるホストコントローラーおよびサーバーインスタンスはすべて単一のドメインコントローラーを持ち、同じドメインに属する必要があります。
デフォルトでは、各ホストコントローラーは、ホストのファイルシステムの未展開の JBoss EAP 6 インストールファイルにある domain/configuration/host.xml ファイルから設定を読み取ります。host.xml ファイルには、特定のホストに固有する以下の設定情報が含まれます。
  • このインストールから実行される JBoss EAP 6 インスタンスの名前。
  • 次の設定のいずれか。
    • ホストコントローラーがドメインコントローラーへ通知して、ホストコントローラー自体を登録し、ドメイン設定へアクセスする方法。
    • リモートドメインコントローラーの検索および通知方法。
    • ホストコントローラーはドメインコントローラーとして動作する。
  • ローカルの物理インストールに固有する設定。たとえば、domain.xml で宣言された名前付きインターフェース定義は、host.xml の実際のマシン固有の IP アドレスにマップできます。また、domain.xml の抽象パス名を host.xml の実際のファイルシステムパスにマッピングできます。

1.9. サーバーグループ

サーバーグループとは、1 つのグループとして管理および設定される複数のサーバーインスタンスのことです。管理対象ドメインでは、各アプリケーションサーバーインスタンスは唯一のメンバーである場合でも 1 つのサーバーグループに属します。グループのサーバーインスタンスは同じプロファイル設定とデプロイされたコンテンツを共有します。
ドメインコントローラーとホストコントローラーは、ドメインにある各サーバーグループのすべてのインスタンスに標準設定を強制します。
ドメインを複数のサーバーグループで構成できます。異なるサーバーグループを異なるプロファイルやデプロイメントで設定できます。ドメインは、異なるサービスを提供する異なるサーバー層で設定できます。
異なるサーバーグループが同じプロファイルやデプロイメントを持つこともできます。これにより、最初のサーバーグループでアプリケーションがアップグレードされた後に 2 つ目のサーバーグループでアプリケーションがアップデートされるアプリケーションのローリングアップグレードが可能になり、サービスの完全停止を防ぎます。
以下はサーバーグループ定義の例になります。

例1.2 サーバーグループ定義

<server-group name="main-server-group" profile="default">
 <socket-binding-group ref="standard-sockets"/>
  <deployments>
   <deployment name="foo.war_v1" runtime-name="foo.war"/>
   <deployment name="bar.ear" runtime-name="bar.ear"/>
  </deployments>
</server-group>
Copy to Clipboard Toggle word wrap
サーバーグループに含まれる必須の属性は次のとおりです。
  • name: サーバーグループの名前。
  • profile: サーバーグループのプロファイル名。
  • socket-binding-group: グループのサーバーに使用されるデフォルトのソケットバインディンググループ。この名前は、host.xml のサーバーごとに上書きできます。ただし、これはすべてのサーバーグループに必須要素であり、存在しない場合はドメインを開始できません。
サーバーグループに含まれる任意の属性は次のとおりです。
  • deployments: グループのサーバー上にデプロイするデプロイメントコンテンツ。
  • system-properties: グループのサーバーに設定するシステムプロパティー。
  • jvm: グループのすべてのサーバーに対するデフォルトの JVM 設定。ホストコントローラーはこれらの設定を host.xml の他の設定とマージし、サーバーの JVM を起動するために使用される設定を作成します。
  • socket-binding-port-offset: ソケットバインディンググループによって提供されたポート値に追加するデフォルトのオフセット。
  • management-subsystem-endpoint: true に設定され、Remoting サブシステムからエンドポイントを使用してサーバーグループに属するサーバーがホストコントローラーに接続し直します(Remoting サブシステムが機能するためにはサブシステムが存在する必要があります)。

1.10. JBoss EAP 6 プロファイル

以前のバージョンの JBoss EAP で使用されたプロファイルの概念は使用されなくなりました。JBoss EAP 6 は、少数の設定ファイルを使用してその設定に関する情報をすべて保持するようになりました。
モジュールとドライバーが必要に応じて読み込まれるようになりました。そのため、以前のバージョンの JBoss EAP 6 で使用されていたデフォルトのプロファイルの概念により、サーバーをより効率的に起動するのではなく、適用されません。
デプロイメント時に、サーバーまたはドメインコントローラーによってモジュールの依存関係が決定、順序付け、解決され、正しい順序でロードされます。モジュールは、デプロイメントが必要なくなったときにアンロードされます。
設定からサブシステムを削除して、モジュールを無効にしたり、ドライバーやその他のサービスを手作業でアンロードしたりできます。ただし、ほとんどの場合、これは必要ありません。どのアプリケーションもモジュールを使用しない場合はロードされません。

1.11. 異なるバージョンのサーバーの管理

注記
異なるバージョンの JBoss EAP サーバーを管理するには、JBoss EAP の最新リリースがドメインコントローラーとして動作する必要があります。
  • JBoss EAP スキーマは異なるバージョンを使用します。そのため、新しいバージョンの JBoss EAP ドメインコントローラーには、下位バージョンの JBoss EAP ホストを制御する問題は必要ありませんが、domain.xml は使用中のすべてのバージョンが 最も古いもの である必要があります。
  • クラスターがある場合、クラスターのすべてのメンバーサーバーは同じバージョンの JBoss EAP に属する必要があります。
  • ドメインのすべてのホストには、Process Controller、Host Controller、および managed server などの Java プロセスが複数存在します。これらの Java プロセスは JBoss EAP の同じインストールから起動する必要があるため、同じバージョンが使用されます。
警告
しかし、JBoss EAP 6.3 のドメインコントローラーが JBoss EAP 6.2 以上のスレーブを管理する場合は、若干非互換性があります。この問題を修正する必要があります。[named-formatter] 属性はターゲットモデルバージョンで認識されず、古い属性に置き換える必要があります。詳細は以下を参照してください。 https://access.redhat.com/solutions/1238073

第2章 アプリケーションサーバー管理

2.1. JBoss EAP ドキュメントの規則

本ガイドのすべてのインスタンスは、使用するインストール方法によって異なる JBoss EAP ルートインストールディレクトリーを参照します。

zip インストール方法
EAP_HOME は、JBoss EAP ZIP ファイルが抽出されたディレクトリーを参照します。
インストーラーメソッド
EAP_HOME は、JBoss EAP のインストールを選択したディレクトリーを参照します。
RPM インストール方法
EAP_HOME は、/usr/share/jbossas ディレクトリーを参照します。
注記
この表記法 は、JBoss EAP で 説明されている規則と同じ規則に従って、JBoss Warehouse のインストール場所を参照するために使用されます。

2.2. JBoss EAP 6 の起動および停止

2.2.1. JBoss EAP 6 の起動

JBoss EAP は、スタンドアロンサーバーまたは管理対象ドメイン 2 つのモードのいずれかで実行され、Red Hat Enterprise Linux と Microsoft Windows Server の 2 つのプラットフォームでサポートされます。JBoss EAP を起動するコマンドは、基礎となるプラットフォームと目的のモードによって異なります。
Expand
表2.1 JBoss EAP を起動するコマンド
Operating System スタンドアロンサーバー 管理対象ドメイン
Red Hat Enterprise Linux EAP_HOME/bin/standalone.sh EAP_HOME/bin/domain.sh
Microsoft Windows Server EAP_HOME\bin\standalone.bat EAP_HOME\bin\domain.bat
JBoss EAP 6 の起動方法に関する詳細は、「JBoss EAP 6 をスタンドアロンサーバーとして起動」 および 「JBoss EAP 6 を管理対象ドメインとして起動」 を参照してください。

2.2.2. JBoss EAP 6 をスタンドアロンサーバーとして起動

概要

ここでは、JBoss EAP 6 をスタンドアロンサーバーとして起動する手順を説明します。

手順2.1 プラットフォームサービスをスタンドアロンサーバーとして起動

  1. Red Hat Enterprise Linux の場合

    EAP_HOME/bin/standalone.shコマンドを実行します。
  2. Microsoft Windows Server の場合

    EAP_HOME\bin\standalone.batコマンドを実行します。
  3. 他のパラメーターを指定する (任意)

    起動スクリプトで利用可能なパラメーターの一覧を表示するには、-h パラメーターを使用します。

結果

JBoss EAP 6 スタンドアロンサーバーインスタンスが起動します。

2.2.3. 1 台のマシンで複数の JBoss EAP スタンドアロンサーバーを実行

概要

このトピックでは、1 台のマシンで複数の JBoss EAP スタンドアロンサーバーを実行する手順を説明します。

手順2.2 1 台のマシンで JBoss EAP スタンドアロンサーバーの複数のインスタンスを実行

  1. 各スタンドアロンサーバーの EAP_HOME/standalone/ ディレクトリーを直接 EAP_HOME/ の下に作成します。たとえば、スタンドアロンサーバーの node1 および node2 のディレクトリーを作成するには、以下のコマンドを入力します。
    $ cd EAP_HOME
    $ cp -a ./standalone ./node1 
    $ cp -a ./standalone ./node2
    Copy to Clipboard Toggle word wrap
  2. ノード名、IP アドレス、サーバーディレクトリー、オプションのサーバー設定ファイル、および任意のポートオフセットを指定して、各 JBoss EAP スタンドアロンインスタンスを起動します。このコマンドは、以下の構文を使用します。
    $ ./bin/standalone.sh -Djboss.node.name=UNIQUE_NODENAME -Djboss.server.base.dir=EAP_HOME/NODE_DIRECTORY -b IP_ADDRESS -bmanagement MGMT_IP_ADDRESS --server-config=SERVER_CONFIGURATION_FILE -Djboss.socket.binding.port-offset=PORT_OFFSET
    Copy to Clipboard Toggle word wrap
    1. この例では、node1を起動します。
      $ cd EAP_HOME
      $ ./bin/standalone.sh -Djboss.node.name=node1 -Djboss.server.base.dir=EAP_HOME/node1 -b 10.10.10.10 -bmanagement 127.0.0.1
      
      Copy to Clipboard Toggle word wrap
    2. node2 を起動する例は、マシンが複数の IP アドレスをサポートするかどうかによって異なります。
      • マシンが複数の IP アドレスをサポートする場合、以下のコマンドを使用します。
        $ cd EAP_HOME
        $ ./bin/standalone.sh -Djboss.node.name=node2 -Djboss.server.base.dir=EAP_HOME/node2 -b 10.10.10.40 -bmanagement 127.0.0.40
        
        Copy to Clipboard Toggle word wrap
      • マシンが複数の IP アドレスをサポートしない場合は、jboss.socket.binding.port-offset プロパティーを指定してポートの競合を避ける必要があります。
        $ cd EAP_HOME
        $ ./bin/standalone.sh -Djboss.node.name=node2 -Djboss.server.base.dir=EAP_HOME/node2 -b 10.10.10.10 -bmanagement 127.0.0.1 -Djboss.socket.binding.port-offset=100
        
        Copy to Clipboard Toggle word wrap
注記
2 つのノードを同時に管理する場合、または同じ設定を持つ 2 つのノードを管理する場合は、スタンドアロンサーバーを実行するのではなく、管理対象ドメインで実行することが推奨されます。

2.2.4. JBoss EAP 6 を管理対象ドメインとして起動

操作の順序

ドメイン内のサーバーグループのスレーブサーバーを起動する前にドメインコントローラーを起動する必要があります。最初に、最初に、関連するホストコントローラーと、ドメインに関連付けられたその他のホストで使用します。

手順2.3 プラットフォームサービスを管理対象ドメインとして起動

  1. Red Hat Enterprise Linux の場合

    EAP_HOME/bin/domain.shコマンドを実行します。
  2. Microsoft Windows Server の場合

    EAP_HOME\bin\domain.batコマンドを実行します。
  3. 他のパラメーターを起動スクリプトに渡す (任意)

    起動スクリプトで利用可能なパラメーターの一覧を表示するには、-h パラメーターを使用します。

結果

JBoss EAP 6 管理対象ドメインインスタンスが起動します。

2.2.5. 管理対象ドメインのホストの名前設定

概要

管理対象ドメインで実行されている各ホストには一意な名前を付ける必要があります。管理を容易にし、複数のホストで同じホスト設定ファイルを使用できるようにするために、以下の優先順位を用いてホスト名が決定されます。

  1. 設定された場合、 host.xml 設定ファイルのホスト要素 属性。
  2. jboss.host.name システムプロパティーの値。
  3. jboss.qualified.host.name システムプロパティーの最後のピリオド(.)の後に続く値。最後のピリオドがない場合は全体の値。
  4. POSIX ベースのオペレーティングシステムでは、HOSTNAME 環境変数のピリオド(.)の後に続く値。Microsoft Windows の COMPUTERNAME 環境変数、最後のピリオドがない場合は全体の値。

環境変数の設定方法は、お使いのオペレーティングシステムのドキュメントを参照してください。システムプロパティーの設定方法は、「管理 CLI を使用したシステムプロパティーの設定」 を参照してください。
本トピックでは、システムプロパティーまたはハードコードされた名前を使用して、設定ファイルのホストの名前を設定する方法について説明します。

手順2.4 システムプロパティーを用いたホスト名の設定

  1. 編集するホスト設定ファイル(例: host.xml )を開きます。
  2. 以下のように、ファイルで host 要素を見つけます。
    <host name="master" xmlns="urn:jboss:domain:1.6">
    Copy to Clipboard Toggle word wrap
  3. これが存在する場合は、name="HOST_NAME" 属性宣言を削除します。host 要素は以下のようになります。
    <host xmlns="urn:jboss:domain:1.6">
    Copy to Clipboard Toggle word wrap
  4. 以下のように、-Djboss.host.name 引数を渡すサーバーを起動します。
    -Djboss.host.name=HOST_NAME
    Copy to Clipboard Toggle word wrap

手順2.5 特定の名前を用いたホスト名の設定

  1. 以下の構文を使用して、JBoss EAP スレーブホストを起動します。
    bin/domain.sh --host-config=HOST_FILE_NAME
    Copy to Clipboard Toggle word wrap
    以下に例を示します。
    bin/domain.sh --host-config=host-slave01.xml
    Copy to Clipboard Toggle word wrap
  2. 管理 CLI を起動します。
  3. 以下の構文を使用してホスト名を置き換えます。
    /host=EXISTING_HOST_NAME:write-attribute(name="name",value=UNIQUE_HOST_NAME)
    Copy to Clipboard Toggle word wrap
    以下に例を示します。
    /host=master:write-attribute(name="name",value="host-slave01")
    Copy to Clipboard Toggle word wrap
    以下の結果が表示されるはずです。
     "outcome" => "success"
    Copy to Clipboard Toggle word wrap
    これにより、host -slave01.xml ファイルのホスト 属性が以下のように変更されます。
    <host name="host-slave01" xmlns="urn:jboss:domain:1.6">
    Copy to Clipboard Toggle word wrap
  4. この処理を完了するには、変更前のホスト名を使用してサーバー設定をリロードする必要があります。
    reload --host=EXISTING_HOST_NAME
    Copy to Clipboard Toggle word wrap
    以下に例を示します。
    reload --host=master
    Copy to Clipboard Toggle word wrap

2.2.6. 2 台のマシンでの管理対象ドメインの作成

注記
この例の実行には、ファイアウォールの設定が必要になることがあります。
1 台のマシンがドメインコントローラーで、別のマシンがホストである 2 台のマシンで管理対象ドメインを作成できます。詳細は、「ドメインコントローラー」 を参照してください。
  • IP1 = ドメインコントローラーの IP アドレス (マシン 1)
  • IP2 = ホストの IP アドレス (マシン 2)

手順2.6 2 台のマシンで管理対象ドメインを作成

  1. マシン 1 での作業

    1. add-user.sh スクリプトを使用して管理ユーザーを追加します。たとえば、ホストがドメインコントローラーを認証できるため、slave01 です。add-user 出力の SECRET_VALUE をメモします。
    2. 専用のドメインコントローラー向けに事前設定された host-master.xml 設定ファイルを使用してドメインを起動します。
    3. -bmanagement=$IP1 を使用して、ドメインコントローラーを他のマシンが見えるようにします。
      EAP_HOME/bin/domain.sh --host-config=host-master.xml -bmanagement=$IP1
      Copy to Clipboard Toggle word wrap
  2. マシン 2 での作業

    1. EAP_HOME/domain/configuration/host-slave.xml ファイルをユーザークレデンシャルで更新します。
      	<?xml version='1.0' encoding='UTF-8'?>
              <host xmlns="urn:jboss:domain:1.6" name="slave01">   
              <!-- add user name here -->
               <management>
                  <security-realms>
                     <security-realm name="ManagementRealm">
                        <server-identities>
                          <secret value="$SECRET_VALUE" />   
                          <!-- use secret value from add-user.sh output-->
                        </server-identities> 
                        ...
      Copy to Clipboard Toggle word wrap
    2. ホストを起動します。
      EAP_HOME/bin/domain.sh --host-config=host-slave.xml  -Djboss.domain.master.address=$IP1 -b=$IP2
      Copy to Clipboard Toggle word wrap
  3. ドメインを管理します。

    CLI を使用する場合:
    EAP_HOME/bin/jboss-cli.sh -c --controller=$IP1
    
    Copy to Clipboard Toggle word wrap
    Web コンソールを使用する場合:
    http://$IP1:9990
    
    Copy to Clipboard Toggle word wrap
    サーバーのインデックスページへアクセスします。
    http://$IP2:8080/
    http://$IP2:8230/
    
    Copy to Clipboard Toggle word wrap

2.2.7. 1 台のマシンで管理対象ドメインを作成

jboss.domain.base.dir プロパティーを使用すると、複数のホストコントローラーを 1 台のマシンで実行できます。
重要
複数の JBoss EAP ホストコントローラーを 1 台のマシン上でシステムサービスとして設定することはサポートされません。

手順2.7 1 台のマシンで複数のホストコントローラーを実行する

  1. ドメインコントローラーの EAP_HOME/domain ディレクトリーをコピーします。
    cp -r EAP_HOME/domain /path/to/domain1
    Copy to Clipboard Toggle word wrap
  2. ホストコントローラーの EAP_HOME/domain ディレクトリーをコピーします。
    cp -r EAP_HOME/domain /path/to/host1
    Copy to Clipboard Toggle word wrap
  3. /path/to/domain1 を使用してドメインコントローラーを起動します。
    EAP_HOME/bin/domain.sh --host-config=host-master.xml -Djboss.domain.base.dir=/path/to/domain1
    Copy to Clipboard Toggle word wrap
  4. /path/to/host1 を使用してホストコントローラーを起動します。
    EAP_HOME/bin/domain.sh --host-config=host-slave.xml -Djboss.domain.base.dir=/path/to/host1 -Djboss.domain.master.address=IP_ADDRESS -Djboss.management.native.port=PORT
    Copy to Clipboard Toggle word wrap

結果

このように起動された各インスタンスは、ベースインストールディレクトリー( EAP_HOME/モジュール/)の残りのリソースを共有しますが、jboss.domain.base.dir で指定されたディレクトリーからドメイン設定を使用します。

2.2.8. 代替設定を用いた JBoss EAP 6 の起動

設定ファイルを指定しない場合、サーバーはデフォルトファイルで起動します。
設定を手動で指定することもできます。このプロセスは、管理対象ドメインまたはスタンドアロンサーバーとオペレーティングシステムのどちらを使用しているかによって異なります。

前提条件

  • 代替の設定ファイルを使用する前に、デフォルト設定をテンプレートとして使用して準備します。
  • 管理対象ドメインの場合、代替の設定ファイルは EAP_HOME/domain/configuration/ ディレクトリーに保存されます。
  • スタンドアロンサーバーの場合、代替の設定ファイルは EAP_HOME/standalone/configuration/ ディレクトリーに保存されます。
設定例
設定例は EAP_HOME/docs/examples/configs/ ディレクトリーに含まれています。これらの例を使用して、クラスタリングやトランザクション XTS API などの機能を有効にします。

代替設定でインスタンスの起動

スタンドアロンサーバー

スタンドアロンサーバーの場合は、--server-config スイッチを使用して設定ファイルを指定します。設定ファイルは EAP_HOME/standalone/configuration/ ディレクトリーにあり、このディレクトリーに対する相対パスを指定する必要があります。

例2.1 Red Hat Enterprise Linux のスタンドアロンサーバーに別の設定ファイルを使用

[user@host bin]$ ./standalone.sh --server-config=standalone-alternate.xml
Copy to Clipboard Toggle word wrap
この例では、EAP_HOME/standalone/configuration/standalone-alternate.xml 設定ファイルを使用します。

例2.2 Microsoft Windows Server のスタンドアロンサーバーに別の設定ファイルを使用

C:\EAP_HOME\bin> standalone.bat --server-config=standalone-alternate.xml
Copy to Clipboard Toggle word wrap
この例では、EAP_HOME\standalone\configuration\standalone-alternative.xml 設定ファイルを使用します。

管理対象ドメイン

管理対象ドメインの場合は、--domain-config スイッチを使用して設定ファイルを指定します。設定ファイルは EAP_HOME/domain/configuration/ ディレクトリーにあり、そのディレクトリーに対する相対パスを指定する必要があります。

例2.3 Red Hat Enterprise Linux の管理対象ドメインに別の設定ファイルを使用

[user@host bin]$ ./domain.sh --domain-config=domain-alternate.xml
Copy to Clipboard Toggle word wrap
この例では、EAP_HOME/domain/configuration/domain-alternate.xml 設定ファイルを使用します。

例2.4 Microsoft Windows Server の管理対象ドメインに別の設定ファイルを使用

C:\EAP_HOME\bin> domain.bat --domain-config=domain-alternate.xml

Copy to Clipboard Toggle word wrap
この例では、EAP_HOME\domain\configuration\domain-alternate.xml 設定ファイルを使用します。

2.2.9. JBoss EAP 6 の停止

JBoss EAP 6 を停止する方法は、起動方法によって異なります。このタスクでは、対話的に起動したインスタンスを停止し、サービスが開始したインスタンスを停止して、スクリプトによりバックグラウンドにフォークされたインスタンスを停止します。
注記
管理対象ドメインでサーバーまたはサーバーグループを停止する方法は、「管理コンソールを使用したサーバーの停止」 を参照してください。管理 CLI を使用してサーバーを停止する方法は、「管理 CLI を使用したサーバーの起動および停止」 を参照してください。

手順2.8 JBoss EAP 6 のインスタンスの停止

  • コマンドラインプロンプトから対話的に起動したインスタンスの停止

    JBoss EAP 6 が稼働しているターミナルで Ctrl-C を押します。

手順2.9 オペレーティングシステムサービスとして起動されたインスタンスの停止

オペレーティングシステムに応じて、以下のいずれかの手順を実行します。
    • Red Hat Enterprise Linux

      Red Hat Enterprise Linux の場合は、サービススクリプトを記述している場合は、stop 機能を使用します。これはスクリプトに記述する必要があります。次に、service scriptname stop を使用することができます。scriptname はスクリプト名に置き換えます。
    • Microsoft Windows Server

      Microsoft Windows では、net service コマンドを使用するか、コントロールパネルの Services アプレットからサービスを停止します。

手順2.10 バックグラウンドで実行されているインスタンスの停止 (Red Hat Enterprise Linux)

  1. プロセスのプロセス ID(PID)を取得します。
    • 単一のインスタンスのみが実行されている場合 (スタンドアロンモード)

      以下のコマンドのいずれかが、JBoss EAP 6 の単一インスタンスの PID を返します。
      • pidof java
      • jps
        jps コマンドは、jboss-modules.jar 用と jps 自体の 2 つのプロセスの ID を返します。jboss-modules.jar の ID を使用して EAP インスタンスを停止します。
    • 複数の EAP インスタンスが実行されている場合 (ドメインモード)

      複数の EAP インスタンスが実行されている場合、正しいプロセスを識別するには、さらに包括的なコマンドを使用する必要があります。
      • jps コマンドは冗長モードで使用して、見つかった java プロセスに関する詳細情報を提供できます。
        以下は、PID およびロールによって実行されている EAP プロセスを特定する、詳細な jps コマンドからのブリッジ出力です。
        $ jps -v
        12155 jboss-modules.jar -D[Server:server-one] -XX:PermSize=256m -XX:MaxPermSize=256m -Xms1303m 
        ...
        
        12196 jboss-modules.jar -D[Server:server-two] -XX:PermSize=256m -XX:MaxPermSize=256m -Xms1303m 
        ...
        
        12096 jboss-modules.jar -D[Host Controller] -Xms64m -Xmx512m -XX:MaxPermSize=256m 
        ...
        
        11872 Main -Xms128m -Xmx750m -XX:MaxPermSize=350m -XX:ReservedCodeCacheSize=96m -XX:+UseCodeCacheFlushing 
        ...
        
        11248 jboss-modules.jar -D[Standalone] -XX:+UseCompressedOops -verbose:gc 
        ...
        
        12892 Jps 
        ...
        
        12080 jboss-modules.jar -D[Process Controller] -Xms64m -Xmx512m -XX:MaxPermSize=256m 
        ...
        
        Copy to Clipboard Toggle word wrap
      • ps aux コマンドを使用して、複数の EAP インスタンスに関する情報を返すこともできます。
        以下は、PID およびロールによって実行されている EAP プロセスを特定する、冗長 ps aux コマンドの出力です。
        $ ps aux | grep java
        username 12080  0.1  0.9 3606588 36772 pts/0   Sl+  10:09   0:01 /path/to/java -D[Process Controller] -server -Xms128m -Xmx128m -XX:MaxPermSize=256m 
        ...
        
        username 12096  1.0  4.1 3741304 158452 pts/0  Sl+  10:09   0:13 /path/to/java -D[Host Controller] -Xms128m -Xmx128m -XX:MaxPermSize=256m 
        ...
        
        username 12155  1.7  8.9 4741800 344224 pts/0  Sl+  10:09   0:22 /path/to/java -D[Server:server-one] -XX:PermSize=256m -XX:MaxPermSize=256m -Xms1000m -Xmx1000m -server -
        ...
        
        username 12196  1.8  9.4 4739612 364436 pts/0  Sl+  10:09   0:22 /path/to/java -D[Server:server-two] -XX:PermSize=256m -XX:MaxPermSize=256m -Xms1000m -Xmx1000m -server 
        ...
        
        Copy to Clipboard Toggle word wrap
      上記の例では、ドメイン全体を停止するには Process Controller プロセスを停止します。
      grep ユーティリティーは、以下のいずれかのコマンドを使用して Process Controller を特定できます。
      jps -v | grep "Process Controller"
      Copy to Clipboard Toggle word wrap
      ps aux | grep "Process Controller"
      Copy to Clipboard Toggle word wrap
  2. kill PID を実行してプロセス TERM シグナルを送信します。ここで、PID は上記のコマンドの 1 つで識別されるプロセス ID です。

結果

JBoss EAP 6 がクリーンにシャットダウンされ、データは失われません。

2.2.10. Server Runtime で渡されるスイッチおよび引数の参照

アプリケーションサーバーの起動スクリプトは実行時に引数とスイッチを受け入れます。これにより、standalone.xmldomain.xml、および host.xml 設定ファイルに定義される設定の代替設定でサーバーを起動できます。
他の設定には、ソケットバインディングの代替セットを持つサーバーの起動や 2 次設定が含まれていることがあります。
起動時に help スイッチ -h または --help を渡すと、利用可能なパラメーター一覧にアクセスできます。
Expand
表2.2 ランタイムスイッチおよび引数
引数またはスイッチ モード 説明
--admin-only Standalone サーバーの実行タイプを ADMIN_ONLY に設定します。これにより管理インターフェースが開かれ、管理リクエストが許可されますが、他のランタイムサービスは起動されず、エンドユーザーのリクエストは許可されません。
--admin-only Domain ホストコントローラーの実行タイプを ADMIN_ONLY に設定します。これにより管理インターフェースが開かれ、管理要求が許可されますが、サーバーは起動しません。または、このホストコントローラーがドメインのマスターである場合はスレーブホストコントローラーからの受信接続が許可されます。
-b=<value>, -b <value> Standalonem、Domain パブリックインターフェースのバインドアドレスを設定するために使用される jboss.bind.address システムプロパティーを設定します。値の指定がない場合はデフォルトで 127.0.0.1 が指定されます。他のインターフェースにバインドアドレスを設定するには -b<interface>=<value> エントリーを確認します。
-b<interface>=<value> Standalonem、Domain システムプロパティー jboss.bind.address.<interface> を指定の値に設定します。例: -bmanagement=IP_ADDRESS
--backup Domain このホストがドメインコントローラーではない場合でも永続ドメイン設定のコピーを保持します。
-c=<config>, -c <config> Standalone 使用するサーバー設定ファイルの名前。デフォルトは standalone.xml です。
-c=<config>, -c <config> Domain 使用するサーバー設定ファイルの名前。デフォルトは domain.xml です。
--cached-dc Domain ホストがドメインコントローラーではなく、起動時にドメインコントローラーに接続できない場合、ローカルでキャッシュされたドメイン設定のコピーを使用してブートします。
--debug [<port>] Standalone オプションの引数を用いてデバッグモードを有効にし、ポートを指定します。起動スクリプトがサポートする場合のみ動作します。
-D<name>[=<value>] Standalonem、Domain システムプロパティーを設定します。
--domain-config=<config> Domain 使用するサーバー設定ファイルの名前。デフォルトは domain.xml です。
-h, --help Standalonem、Domain ヘルプメッセージを表示し、終了します。
--host-config=<config> Domain 使用するホスト設定ファイルの名前。デフォルトは host.xml です。
--interprocess-hc-address=<address> Domain ホストコントローラーがプロセスコントローラーからの通信をリッスンしなければならないアドレス。
--interprocess-hc-port=<port> Domain ホストコントローラーがプロセスコントローラーからの通信をリッスンしなければならないポート。
--master-address=<address> Domain システムプロパティー jboss.domain.master.address を指定の値に設定します。デフォルトのスレーブホストコントローラー設定では、マスターホストコントローラーのアドレスを設定するために使用されます。
--master-port=<port> Domain システムプロパティー jboss.domain.master.port を指定の値に設定します。デフォルトのスレーブホストコントローラー設定では、マスターホストコントローラーによるネイティブ管理の通信で使用されるポートを設定するために使用されます。
--read-only-server-config=<config> Standalone 使用するサーバー設定ファイルの名前。元のファイルは上書きされないため、--server-config および -c とは異なります。
--read-only-domain-config=<config> Domain 使用するドメイン設定ファイルの名前。最初のファイルは上書きされないため、--domain-config および -c とは異なります。
--read-only-host-config=<config> Domain 使用するホスト設定ファイルの名前。最初のファイルは上書きされないため、--host-config とは異なります。
-P=<url>, -P <url>, --properties=<url> Standalonem、Domain 該当する URL からシステムプロパティーをロードします。
--pc-address=<address> Domain プロセスコントローラーが制御するプロセスからの通信をリッスンするアドレス。
--pc-port=<port> Domain プロセスコントローラーが制御するプロセスからの通信をリッスンするポート。
-S<name>[=<value>] Standalone セキュリティープロパティーを設定します。
--server-config=<config> Standalone 使用するサーバー設定ファイルの名前。デフォルトは standalone.xml です。
-u=<value>, -u <value> Standalonem、Domain 設定ファイルの socket-binding 要素のマルチキャストアドレスを設定するために使用される jboss.default.multicast.address システムプロパティーを設定します。値の指定がない場合はデフォルトで 230.0.0.4 が指定されます。
-v,-V,--version Standalonem、Domain アプリケーションサーバーのバージョンを表示し、終了します。
警告
JBoss EAP 6 に同梱される設定ファイルは、スイッチ( -b-u)を処理するよう設定されます。スイッチによって制御されるシステムプロパティーを使用しないよう設定ファイルを変更した場合は、実行するコマンドにスイッチを追加しても効果はありません。

2.3. サーバーの起動と停止

2.3.1. 管理 CLI を使用したサーバーの起動および停止

サーバーは、管理 CLI または管理コンソールを使用して起動および停止できます。どちらのツールでも、単一のスタンドアロンサーバーインスタンスを制御し、管理対象ドメインのデプロイメント全体で複数のサーバーを管理できます。
管理コンソールを使用する場合は、「管理コンソールを使用したサーバーの起動」 を参照してください。管理 CLI を使用する場合、スタンドアロンサーバーおよび管理対象ドメインインスタンスでプロセスは異なります。

管理 CLI を用いたスタンドアロンサーバーの停止

スクリプトまたはシェルプロンプトで手動で起動するスタンドアロンサーバーは、shutdown コマンドを使用して管理 CLI からシャットダウンできます。

例2.5 管理 CLI よりスタンドアロンサーバーインスタンスを停止する

[standalone@localhost:9999 /] shutdown
Copy to Clipboard Toggle word wrap
JBoss EAP 6 スタンドアロンサーバーインスタンスを再起動するには、「JBoss EAP 6 をスタンドアロンサーバーとして起動」 の説明に従ってインスタンスの起動スクリプトを実行するか、手動で起動します。

管理 CLI を用いた管理対象ドメインの起動および停止

管理コンソールは、ドメイン内の特定サーバーを選択的に起動または停止できます。これには、ドメイン全体にわたるサーバーグループや、ホスト上の特定サーバーインスタンスが含まれます。

例2.6 管理 CLI より管理対象ドメインのサーバーホストを停止する

スタンドアロンサーバーインスタンスと同様に、shutdown コマンドを使用して、宣言された管理対象ドメインホストをシャットダウンします。この例では、シャットダウン操作を呼び出す前にインスタンス名を宣言して master という名前のサーバーホストを停止します。
[domain@localhost:9999 /] shutdown --host=master
Copy to Clipboard Toggle word wrap

例2.7 管理 CLI より管理対象ドメインのサーバーホストを起動および停止する

この例では、start および stop 操作を呼び出す前にグループを宣言することで、main-server-group という名前のデフォルトのサーバーグループを起動します。
[domain@localhost:9999 /] /server-group=main-server-group:start-servers
Copy to Clipboard Toggle word wrap
[domain@localhost:9999 /] /server-group=main-server-group:stop-servers
Copy to Clipboard Toggle word wrap

例2.8 管理 CLI より管理対象ドメインのサーバーインスタンスを起動および停止する

この例では、起動および停止操作を呼び出す前にホストとサーバー設定を宣言することで、マスター ホストの server-one という名前のサーバーインスタンスを 起動 して 停止 します。
[domain@localhost:9999 /] /host=master/server-config=server-one:start
Copy to Clipboard Toggle word wrap
[domain@localhost:9999 /] /host=master/server-config=server-one:stop
Copy to Clipboard Toggle word wrap
注記
タブ キーを使用して文字列を補完し、利用可能なホストおよびサーバー設定の値などの可視変数を表示します。

2.3.2. 管理コンソールを使用したサーバーの起動

手順2.11 管理対象ドメイン向けのサーバーの起動

  1. コンソール上部の ドメイン タブを選択し、TOPOLOGY タブを選択します。左側のナビゲーションバーの DomainOverview を選択します。
  2. Server Instances リストから、起動するサーバーを選択します。実行中のサーバーはチェックマークで表示されます。
    このリストにあるインスタンスにカーソルを合わせ、サーバーの詳細の下に青色でオプションを表示します。
  3. インスタンスを起動するには、表示された時に Start Server テキストをクリックします。確認ダイアログボックスが開きます。確認 をクリックしてサーバーを起動します。

結果

選択したサーバーが起動し、稼働状態になります。

2.3.3. 管理コンソールを使用したサーバーの停止

手順2.12 管理コンソールを使用した管理対象ドメインのサーバーの停止

  1. コンソール上部の ドメイン タブを選択し、TOPOLOGY タブを選択します。左側のナビゲーションバーの DomainOverview を選択します。
  2. 利用可能なサーバーインスタンスの 一覧は 、ホスト、グループ、およびサーバーインスタンス の表に表示されます。実行中のサーバーはチェックマークで表示されます。
  3. 選択したサーバーにカーソルを合わせます。表示される Stop Server テキストをクリックします。確認ダイアログウインドウが表示されます。
  4. 確認 をクリックしてサーバーを停止します。

結果

選択されたサーバーが停止します。

2.4. 設定ファイル

2.4.1. JBoss EAP 6 の設定ファイル

JBoss EAP 6 の設定は以前のバージョンから大幅に変更されました。最も明確な違いの 1 つは、以下のファイルが 1 つ以上含まれる簡素化された設定ファイル構造を使用することです。
Expand
表2.3 設定ファイルの場所
サーバーモード 場所 目的
domain.xml EAP_HOME/domain/configuration/domain.xml これは、管理対象ドメインの主要設定ファイルです。ドメインマスターのみがこのファイルを読み取ります。他のドメインメンバーでは削除できます。
host.xml EAP_HOME/domain/configuration/host.xml このファイルには、管理対象ドメインの物理ホスト固有の設定情報が含まれています (ネットワークインターフェース、ソケットバインディング、ホスト名、その他のホスト固有の詳細など)。host.xml ファイルには、host-master.xmlhost-slave.xml の両方の機能がすべて含まれています。これについては以下で説明します。このファイルはスタンドアロンサーバーには存在しません。
host-master.xml EAP_HOME/domain/configuration/host-master.xml このファイルには、サーバーを管理対象ドメインのマスターサーバーとして実行するために必要な設定情報のみが含まれています。このファイルはスタンドアロンサーバーには存在しません。
host-slave.xml EAP_HOME/domain/configuration/host-slave.xml このファイルには、サーバーを管理対象ドメインのスレーブサーバーとして実行するために必要な設定情報のみが含まれています。このファイルはスタンドアロンサーバーには存在しません。
standalone.xml EAP_HOME/standalone/configuration/standalone.xml スタンドアロンサーバーのデフォルト設定ファイルです。これには、サブシステム、ネットワーキング、デプロイメント、ソケットバインディング、およびその他の設定可能な詳細など、スタンドアロンサーバーに関するすべての情報が含まれます。この設定は、スタンドアロンサーバーの起動時に自動的に使用されます。
standalone-full.xml EAP_HOME/standalone/configuration/standalone-full.xml スタンドアロンサーバーの設定例になります。これには、高可用性に必要なサブシステムを除くすべてのサブシステムのサポートが含まれます。これを使用するには、サーバーを停止し、次のコマンドを使用して再起動します。 EAP_HOME/bin/standalone.sh -c standalone-full.xml
standalone-ha.xml EAP_HOME/standalone/configuration/standalone-ha.xml この設定ファイルの例では、デフォルトのサブシステムをすべて有効にし、高可用性または負荷分散クラスターに参加できるようにスタンドアロンサーバーの mod_cluster および JGroups サブシステムを追加します。このファイルは管理対象ドメインには適用されません。この設定を使用するには、以下のコマンドを実行してサーバーを停止し、再起動します。 EAP_HOME/bin/standalone.sh -c standalone-ha.xml
standalone-full-ha.xml EAP_HOME/standalone/configuration/standalone-full-ha.xml スタンドアロンサーバーの設定例になります。これには、高可用性に必要なサブシステムを含むすべてのサブシステムのサポートが含まれます。これを使用するには、サーバーを停止し、次のコマンドを使用して再起動します。 EAP_HOME/bin/standalone.sh -c standalone-full-ha.xml
これらはデフォルトの場所です。ランタイム時に別の設定ファイルを指定できます。
注記
JBoss EAP 6 の設定データのバックアップに関する詳細は、「JBoss EAP 設定データのバックアップ」 を参照してください。

2.4.2. JBoss EAP 設定データのバックアップ

概要

このトピックでは、後で JBoss EAP サーバー設定を復元するためにバックアップする必要のあるファイルについて説明します。

手順2.13 設定データのバックアップ

  1. ユーザーおよびプロファイルデータ、ドメイン、ホスト、スレーブ、およびロギング設定を保持するには、以下のディレクトリーの内容全体をバックアップします。
    • EAP_HOME/standalone/configuration/
    • EAP_HOME/domain/configuration
  2. EAP_HOME/modules/system/layers/base/ ディレクトリーに作成されたカスタムモジュールをバックアップします。
  3. EAP_HOME/welcome-content/ ディレクトリーの Welcome コンテンツをバックアップします。
  4. EAP_HOME/bin/ ディレクトリーに作成されたカスタムスクリプトをバックアップします。

2.4.3. 記述子ベースのプロパティー置換

アプリケーションの設定(データソース接続パラメーターなど)は、通常は開発、テスト、および実稼働デプロイメントによって異なります。Java EE 仕様にはこれらの設定を外部化するメソッドが含まれていないため、このような違いはビルドシステムスクリプトで対応することがあります。JBoss EAP 6 では、記述子ベースのプロパティー置換 を使用して設定を外部で管理できます。
記述子ベースのプロパティー置換は、記述子を基にプロパティーを置き換えるため、アプリケーションやビルドチェーンから環境に関する仮定を除外できます。環境固有の設定は、アノテーションやビルドシステムスクリプトでなく、デプロイメント記述子に指定できます。設定はファイルに指定したり、パラメーターとしてコマンドラインで提供したりできます。
記述子ベースのプロパティー置換は、standalone.xml または domain.xml を介してグローバルに有効になります。

例2.9 記述子ベースのプロパティー置換

<subsystem xmlns="urn:jboss:domain:ee:1.2">
  <spec-descriptor-property-replacement>
    true
  </spec-descriptor-property-replacement>
  <jboss-descriptor-property-replacement>
    true
  </jboss-descriptor-property-replacement>
</subsystem>
Copy to Clipboard Toggle word wrap
Java EE 記述子置換はデフォルトで 無効 になっています。有効にすると、ejb-jar.xml および persistence.xml 設定ファイルで記述子を置き換えることができます。
JBoss 固有の記述子置換はデフォルトで 有効 になっています。有効にすると、以下の設定ファイルで記述子を置換できます。
  • jboss-ejb3.xml
  • jboss-app.xml
  • jboss-web.xml
  • *-jms.xml
  • *-ds.xml
たとえば、以下のアノテーションを持つ Bean があるとします。

例2.10 アノテーションの例

@ActivationConfigProperty(propertyName = "connectionParameters", propertyValue = "host=192.168.1.1;port=5445")
Copy to Clipboard Toggle word wrap
記述子ベースのプロパティー置換を有効にすると、以下のようにコマンドラインから connectionParameters を指定できます。
./standalone.sh -DconnectionParameters='host=10.10.64.1;port=5445'
Copy to Clipboard Toggle word wrap
システムプロパティーを使用して同じことを実現するには、literal の値の代わりに を使用します。式は ${パラメーター:default} の形式を取ります。式が設定で使用されると、そのパラメーターの値がその意味になります。パラメーターが存在しない場合は、代わりに指定されたデフォルト値が使用されます。

例2.11 記述子で式の使用

<activation-config>
  <activation-config-property>
    <activation-config-property-name>
      connectionParameters
      </activation-config-property-name>
    <activation-config-property-value>
      ${jms.connection.parameters:'host=10.10.64.1;port=5445'}
    </activation-config-property-value>
  </activation-config-property>
</activation-config>
Copy to Clipboard Toggle word wrap
${jms.connection.parameters:'host=10.10.64.1;port=5445'} により、デフォルト値を提供しながらコマンドラインが提供するパラメーターで接続パラメーターを上書きできます。

2.4.4. 記述子ベースのプロパティー置換の有効化または無効化

概要

記述子プロパティー置換の finite コントロールが jboss-as-ee_1_1.xsd に導入されました。ここでは、記述子ベースのプロパティー置換を設定するのに必要な手順を説明します。

記述子ベースのプロパティー置換フラグはブール値を持ちます。
  • true に設定すると、プロパティー置換が有効になります。
  • false に設定すると、プロパティー置換が無効になります。

手順2.14 jboss-descriptor-property-replacement

jboss-descriptor-property-replacement 以下の記述子でプロパティー置換を有効または無効にするために使用されます。
  • jboss-ejb3.xml
  • jboss-app.xml
  • jboss-web.xml
  • *-jms.xml
  • *-ds.xml
jboss-descriptor-property-replacement のデフォルト値は true です。
  1. 管理 CLI で以下のコマンドを実行し、jboss-descriptor-property-replacement の値を確認します。
    /subsystem=ee:read-attribute(name="jboss-descriptor-property-replacement")
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して動作を設定します。
    /subsystem=ee:write-attribute(name="jboss-descriptor-property-replacement",value=VALUE)
    Copy to Clipboard Toggle word wrap

手順2.15 spec-descriptor-property-replacement

spec-descriptor-property-replacement 以下の記述子でプロパティー置換を有効または無効にするために使用されます。
  • ejb-jar.xml
  • persistence.xml
  • application.xml
  • web.xml
spec-descriptor-property-replacement のデフォルト値は false です。
  1. 管理 CLI で以下のコマンドを実行し、spec-descriptor-property-replacement の値を確認します。
    /subsystem=ee:read-attribute(name="spec-descriptor-property-replacement")
    Copy to Clipboard Toggle word wrap
  2. 次のコマンドを実行して動作を設定します。
    /subsystem=ee:write-attribute(name="spec-descriptor-property-replacement",value=VALUE)
    Copy to Clipboard Toggle word wrap

結果

記述子ベースのプロパティー置換が正常に設定されます。

2.4.5. ネストされた式

式はネスト化できるため、固定値の代わりにさらに高度な式を使用できます。ネストされた式の書式は、通常の式の場合と同様ですが、ある式が別の式に組み込まれます。 例を以下に示します。

例2.12 ネストされた式

${system_value_1${system_value_2}}
Copy to Clipboard Toggle word wrap
ネストされた式は、再帰的に評価されるため、最初に 内部の式が評価され、次に 外部の式が評価されます。ネストされた式は式が許可された場所であればどこでも許可されます(ただし、管理 CLI コマンドを除く)。
通常式と同様に、ネストされた式の解決でサポートされるソースはシステムプロパティー、環境変数、および Vault になります。デプロイメントのみの場合、デプロイメントアーカイブの META-INF/jboss.properties ファイルにリストされたプロパティーをソースとすることができます。サブデプロイメントをサポートする EAR またはその他のデプロイメントタイプでは、META-INF/jboss.properties が外部デプロイメント(EAR など)にある場合、解決はすべてのサブデプロイメントにスコープが設定され、META-INF/jboss.properties が EAR 内のサブデプロイメントアーカイブ(例: EAR 内の WAR)にある場合はサブデプロイメントに対してスコープ指定されます。

例2.13 設定ファイルでのネストされた式の使用

ネストされた式の実際のライフサイクルアプリケーションはデータソース定義にあります。データソース定義で使用されるパスワードがマスクされている場合は、データソース定義で生成される行は以下のようになります。
<password>${VAULT::ds_ExampleDS::password::1}</password>
Copy to Clipboard Toggle word wrap
ネストされた式を使用すると、ds_ExampleDS の値をシステムプロパティーに置き換えることができます。システムプロパティー datasource_nameds_ExampleDS の値が割り当てられている場合、データソース定義の行は以下のようになります。
<password>${VAULT::${datasource_name}::password::1}</password>
Copy to Clipboard Toggle word wrap
JBoss EAP は最初に式 ${datasource_name} を評価し、次にこれを大きな式に入力し、結果となる式を評価します。この設定の利点は、データソースの名前が固定された設定から抽象化されることです。
式が再帰的になれば、式が式に解決され、その後解決されます。ネストされた式と再帰式は間接的な形です。管理 CLI コマンドでは再帰式が許可されないことに注意してください。

例2.14 再帰式

前の例を続行すると、式 ${ VAULT::ds_ExampleDS::password::1} に解決される ${ foo} 式が使用され、Vault: シークレット に含まれる値に解決されます。

2.4.6. ファイルの履歴設定

アプリケーションサーバーの設定ファイルには、standalone.xmldomain.xml ファイル、および host.xml ファイルが含まれます。これらのファイルは直接編集して変更できますが、管理 CLI や管理コンソールなど、利用可能な管理操作でアプリケーションサーバーモデルを設定する方法が推奨されます。
サーバーインスタンスの保守および管理を容易にするために、アプリケーションサーバーは起動時に元の設定ファイルのタイムスタンプバージョンを作成します。管理操作によってその他の設定変更が行われると、元のファイルが自動的にバックアップされ、インスタンスの作業用コピーが参照およびロールバック用に保持されます。このアーカイブ機能では、サーバー設定のスナップショットの保存、読み込み、および削除が拡張され、再利用およびロールバックシナリオが可能になります。

2.4.7. 以前の設定でのサーバーの起動

以下の例は、standalone.xml を使用してスタンドアロンサーバーの以前の設定でアプリケーションサーバーを起動する方法を示しています。同じ概念が domain.xmlhost.xml の管理対象ドメインにそれぞれ適用されます。
この例では、管理操作によってサーバーモデルが変更される場合にアプリケーションサーバーにより自動的に保存される以前の設定が呼び出されます。

例2.15 保存した設定でサーバーを起動します。

  1. 起動するバックアップバージョンを特定します。この例では、起動に成功すると最初の変更の前にサーバーモデルのインスタンスが呼び出されます。
    EAP_HOME/standalone/configuration/standalone_xml_history/current/standalone.v1.xml
    Copy to Clipboard Toggle word wrap
  2. jboss.server.config.dir 下で相対ファイル名を渡し、バックアップモデルのこの設定を用いてサーバーを起動します。
    EAP_HOME/bin/standalone.sh --server-config=standalone_xml_history/current/standalone.v1.xml
    Copy to Clipboard Toggle word wrap

結果

アプリケーションサーバーが、選択された設定で起動されます。

注記
ドメイン設定履歴は EAP_HOME/domain/configuration/domain_xml_history/current/domain.v1.xml にあります
jboss.domain.config.dir 下で相対ファイル名を渡し、バックアップモデルのこの設定を用いてサーバーを起動します。
この設定を用いてドメインを起動するには、以下を実行します。
EAP_HOME/bin/domain.sh --domain-config=domain_xml_history/current/domain.v1.xml
Copy to Clipboard Toggle word wrap

2.4.8. 管理 CLI を使用した設定スナップショットの保存

概要

設定スナップショットは、現在のサーバー設定の特定の時点のコピーです。これらのコピーは管理者が保存およびロードできます。

以下の例では、standalone.xml 設定ファイルを使用しますが、同じプロセスが domain.xml および host.xml 設定ファイルにも適用されます。

手順2.16 設定スナップショットの撮影および保存

  • スナップショットの保存

    take-snapshot 操作を実行し、現在のサーバー設定のコピーを取得します。
    [standalone@localhost:9999 /] :take-snapshot
    {
        "outcome" => "success",
        "result" => "/home/User/EAP_HOME/standalone/configuration/standalone_xml_history/snapshot/20110630-172258657standalone.xml"
    
    Copy to Clipboard Toggle word wrap

結果

現在のサーバー設定のスナップショットが保存されます。

2.4.9. 管理 CLI を使用した設定スナップショットのロード

設定スナップショットは、現在のサーバー設定の特定の時点のコピーです。これらのコピーは管理者が保存およびロードできます。スナップショットを読み込むプロセスは、スナップショットの作成、一覧表示、および削除に使用される管理 CLI インターフェースではなく、コマンドラインから使用する方法と似ています。「以前の設定でのサーバーの起動」
以下の例は standalone.xml ファイルを使用しますが、同じプロセスが domain.xml および host.xml ファイルに適用されます。

手順2.17 設定スナップショットのロード

  1. ロードするスナップショットを特定します。この例では、スナップショットディレクトリーから以下のファイルを呼び出します。スナップショットファイルのデフォルトのパスは以下のとおりです。
    EAP_HOME/standalone/configuration/standalone_xml_history/snapshot/20110812-191301472standalone.xml
    Copy to Clipboard Toggle word wrap
    スナップショットは相対パスにより表されます。たとえば、上記の例は次のように記述できます。
    jboss.server.config.dir/standalone_xml_history/snapshot/20110812-191301472standalone.xml
    Copy to Clipboard Toggle word wrap
  2. ファイル名を渡し、選択したスナップショットを用いてサーバーを起動します。
    EAP_HOME/bin/standalone.sh --server-config=standalone_xml_history/snapshot/20110913-164449522standalone.xml
    Copy to Clipboard Toggle word wrap

結果

ロードしたスナップショットに選択された設定を用いてサーバーが再起動します。

2.4.10. 管理 CLI を使用した設定スナップショットの削除

設定スナップショットは、現在のサーバー設定の特定の時点のコピーです。これらのコピーは管理者が保存およびロードできます。
以下の例は standalone.xml ファイルを使用しますが、同じプロセスが domain.xml および host.xml ファイルに適用されます。

手順2.18 特定のスナップショットの削除

  1. 削除するスナップショットを特定します。この例では、スナップショットディレクトリーから以下のファイルを削除します。
    EAP_HOME/standalone/configuration/standalone_xml_history/snapshot/20110630-165714239standalone.xml
    Copy to Clipboard Toggle word wrap
  2. 以下の例のようにスナップショットの名前を指定して、:delete-snapshot コマンドを実行して特定のスナップショットを削除します。
    [standalone@localhost:9999 /] :delete-snapshot(name="20110630-165714239standalone.xml")
    {"outcome" => "success"}
    
    Copy to Clipboard Toggle word wrap

結果

スナップショットが削除されます。

手順2.19 スナップショットすべてを削除

  • 以下の例のように、:delete-snapshot(name="all") コマンドを実行して、すべてのスナップショットを削除します。
    [standalone@localhost:9999 /] :delete-snapshot(name="all")
    {"outcome" => "success"}
    
    Copy to Clipboard Toggle word wrap

結果

スナップショットがすべて削除されます。

2.4.11. 管理 CLI を使用したすべての設定スナップショットのリスト

設定スナップショットは、現在のサーバー設定の特定の時点のコピーです。これらのコピーは管理者が保存およびロードできます。
以下の例は standalone.xml ファイルを使用しますが、同じプロセスが domain.xml および host.xml ファイルに適用されます。

手順2.20 すべての設定スナップショットのリスト

  • すべてのスナップショットのリスト

    :list-snapshots コマンドを実行して、保存されたすべてのスナップショットを一覧表示します。
    [standalone@localhost:9999 /] :list-snapshots
    {
        "outcome" => "success",
        "result" => {
            "directory" => "/home/hostname/EAP_HOME/standalone/configuration/standalone_xml_history/snapshot",
            "names" => [
                "20110818-133719699standalone.xml",
                "20110809-141225039standalone.xml",
                "20110802-152010683standalone.xml",
                "20110808-161118457standalone.xml",
                "20110912-151949212standalone.xml",
                "20110804-162951670standalone.xml"
            ]
        }
    }
    
    Copy to Clipboard Toggle word wrap

結果

スナップショットがリストされます。

2.5. ファイルシステムパス

JBoss EAP 6 は、ファイルシステムパスに論理名を使用します。domain.xmlhost.xml、および standalone.xml 設定ファイルには、パスを宣言するセクションが含まれます。
各ファイルの他のセクションは論理名を使用してパスを参照できます。そのため、各インスタンスに絶対パスを使用する必要がなく、特定のホスト設定が汎用論理名に解決できます。
たとえば、デフォルトの logging サブシステム設定は jboss.server.log.dir をサーバーの ログ ディレクトリーの論理名として宣言します。

例2.16 ロギングディレクトリーの相対パス例

<file relative-to="jboss.server.log.dir" path="server.log"/>
Copy to Clipboard Toggle word wrap
JBoss EAP 6 では、複数の標準的なパスが自動的に提供されるため、ユーザーが設定ファイルでこれらのパスを設定する必要はありません。
Expand
表2.4 標準的なパス
Value 説明
java.ext.dirs Java Development Kit 拡張ディレクトリーパス。
jboss.home.dir JBoss EAP 6 ディストリビューションのルートディレクトリー。
user.home ユーザーのホームディレクトリー。
user.dir ユーザーのカレントワーキングディレクトリー。
java.home Java インストールディレクトリー。
jboss.server.base.dir 各サーバーインスタンスのルートディレクトリー。
jboss.server.data.dir サーバーが永続データファイルストレージに使用するディレクトリー。
jboss.server.config.dir サーバー設定が含まれるディレクトリー。
jboss.server.log.dir サーバーがファイルストレージに使用するディレクトリー。
jboss.server.temp.dir サーバーが一時ファイルストレージに使用するディレクトリー。
jboss.server.deploy.dir サーバーがデプロイされたコンテンツの格納に使用するディレクトリー。
jboss.controller.temp.dir ホストコントローラーが一時的なファイルストレージとして使用するディレクトリー。
jboss.domain.base.dir ドメインコンテンツのベースディレクトリー。
jboss.domain.config.dir ドメイン設定が含まれるディレクトリー。
jboss.domain.data.dir ドメインが永続データファイルの格納に使用するディレクトリー。
jboss.domain.log.dir ドメインが永続ログファイルの格納に使用するディレクトリー。
jboss.domain.temp.dir ドメインが一時ファイルの格納に使用するディレクトリー。
jboss.domain.deployment.dir ドメインがデプロイ済みコンテンツの格納に使用するディレクトリー。
jboss.domain.servers.dir ドメインが管理対象ドメインインスタンスの出力を格納するために使用するディレクトリー。

パスのオーバーライド

スタンドアロンサーバーを実行している場合は、2 つの方法のいずれかですべての jboss.server.* パスを上書きできます。

  • サーバーの起動時にコマンドライン引数を渡すことができます。以下に例を示します。
    bin/standalone.sh -Djboss.server.log.dir=/var/log
    Copy to Clipboard Toggle word wrap
  • サーバー設定ファイルで JAVA_OPTS 変数を変更できます。EAP_HOME/bin/standalone.conf ファイルを開き、ファイルの最後に以下の行を追加します。
    JAVA_OPTS="$JAVA_OPTS -Djboss.server.log.dir=/var/log"
    Copy to Clipboard Toggle word wrap
パスのオーバーライドは、管理対象ドメインで実行しているサーバーでサポートされます。たとえば、jboss.domain.servers.dir を使用して管理対象ドメインのサーバーのベースディレクトリーを変更できます。

カスタムパスの追加

また、独自のカスタムパスを作成することもできます。たとえば、ロギングに使用する相対パスを定義できます。次に、ログハンドラーを変更して my.relative.path を使用することができます。

例2.17 カスタムロギングパス

my.relative.path=/var/log
Copy to Clipboard Toggle word wrap

2.5.1. ディレクトリーのグループ化

ドメインモードでは、各サーバーのファイルは EAP_HOME/domain/ ディレクトリーに保存されます。サブディレクトリーの名前は、server または file タイプのいずれかで directory-grouping 属性に従って付けられます。

サーバーを基にしたディレクトリーのグループ化

デフォルトのディレクトリーグルーピング はサーバー です。管理作業がサーバー中心である場合はこの設定が推奨されます。たとえば、サーバーインスタンスごとにバックアップやログファイルの処理を設定することができます。

例2.18 サーバーを基にしたディレクトリーのグループ化

Zip メソッドを使用して JBoss EAP がインストールされ、すべてのデフォルトオプションが適用されると、ドメインモードのディレクトリー構造は以下のようになります。
EAP_HOME/domain
             └─ servers
                  ├── server-one
                  │   ├── data
                  │   ├── tmp
                  │   └── log
                  └── server-two
                      ├── data
                      ├── tmp
                      └── log
Copy to Clipboard Toggle word wrap
directory-grouping 属性をデフォルトから変更し、リセットする場合は、以下の管理 CLI コマンドを入力します。
/host=master:write-attribute(name="directory-grouping",value="by-server")
Copy to Clipboard Toggle word wrap
これにより、コントローラーの host.xml 設定ファイルが更新されます。
<servers directory-grouping="by-server">
  <server name="server-one" group="main-server-group" >
  </server>
  <server name="server-two" group="main-server-group" auto-start="true">
  </server>
</servers>
Copy to Clipboard Toggle word wrap

タイプを基にしたディレクトリーのグループ化

各サーバーのディレクトリーをサーバーごとにグループ化するのではなく、ファイルタイプでグループ化することもできます。管理作業がファイルタイプ中心である場合は、この設定が推奨されます。たとえば、データファイルのみを含める場合は、バックアップ設定が簡単になります。

タイプ 別にドメインデータディレクトリーをグループ化するには、以下の管理 CLI コマンドを入力します。
/host=master:write-attribute(name="directory-grouping",value="by-type")
Copy to Clipboard Toggle word wrap
これにより、コントローラーの host.xml 設定ファイルが更新されます。
<servers directory-grouping="by-type">
  <server name="server-one" group="main-server-group" >
  </server>
  <server name="server-two" group="main-server-group" auto-start="true">
  </server>
</servers>
Copy to Clipboard Toggle word wrap

例2.19 タイプを基にしたディレクトリーのグループ化

Zip メソッドを使用して JBoss EAP がインストールされ、ドメインのファイルがタイプを基にグループ化された場合、ドメインモードのディレクトリー構造は以下のようになります。
EAP_HOME/domain
            ├── data
            │   └── servers
            │       ├── server-one
            │       └── server-two
            ├── log
            │   └── servers
            │       ├── server-one
            │       └── server-two
            └── tmp
                └── servers
                    ├── server-one
                    └── server-two
Copy to Clipboard Toggle word wrap

2.5.2. ユースケース: ディレクトリーの上書き

この例の目的は、/opt/jboss_eap/data/domain_data ディレクトリーにドメインファイルを格納し、各最上位ディレクトリーにカスタム名を付けることです。使用されるディレクトリーのグループ化は、デフォルトの by-server です。
  • サブディレクトリー all_logsに保存されているログファイル
  • サブディレクトリー all_dataに保存されているデータファイル
  • all_tempサブディレクトリーに格納されている一時ファイル
  • all_serversサブディレクトリーに格納されているサーバーのファイル
この設定を行うには、JBoss EAP の起動時に複数のシステムプロパティーを上書きします。
./domain.sh \
      -Djboss.domain.temp.dir=/opt/jboss_eap/data/domain_data/all_temp \
      -Djboss.domain.log.dir=/opt/jboss_eap/data/domain_data/all_logs \
      -Djboss.domain.data.dir=/opt/jboss_eap/data/domain_data/all_data\
      -Djboss.domain.servers.dir=/opt/jboss_eap/data/domain_data/all_servers
Copy to Clipboard Toggle word wrap
この結果、パス構造は次のようになります。
/opt/jboss_eap/data/domain_data/
├── all_data
│   └── content
├── all_logs
│   ├── host-controller.log
│   └── process-controller.log
├── all_servers
│   ├── server-one
│   │   ├── data
│   │   │   ├── content
│   │   │   ├── logging.properties
│   │   ├── log
│   │   │   └── server.log
│   │   └── tmp
│   │       ├── vfs
│   │       │   └── temp
│   │       └── work
│   │           └── jboss.web
│   │               └── default-host
│   └── server-two
│       ├── data
│       │   ├── content
│       │   ├── logging.properties
│       ├── log
│       │   └── server.log
│       └── tmp
│           ├── vfs
│           │   └── temp
│           └── work
│               └── jboss.web
│                   └── default-host
└── all_temp
    └── auth
          ...
Copy to Clipboard Toggle word wrap

第3章 管理インターフェース

3.1. アプリケーションサーバーの管理

JBoss EAP 6 は、サーバー設定に XML ファイルを使用し、JBoss EAP 6 サーバーの設定および管理の 3 つの方法(Web インターフェース、コマンドラインクライアント、および XML 設定ファイルの直接編集)を提供します。
設定ファイルを編集するのに推奨される方法は、管理 CLI と新しい Web ベースの管理コンソールです。XML 設定ファイルに加えた編集は引き続き可能ですが、管理コンソールと管理 CLI を使用して設定および管理することで、サーバーインスタンスの管理に追加の検証および高度な機能が提供されます。
3 つの方法のいずれかでサーバー設定に加えた編集は、異なるビュー全体で同期されます。
注記
ただし、サーバーインスタンスの実行中に XML 設定ファイルに加えた編集は、サーバーモデルによって上書きされます。サーバーインスタンスの実行中に XML 設定ファイルに追加されたコメントもすべて削除されます。
Web ブラウザーでグラフィカルユーザーインターフェースを使用してサーバーを管理するには、管理コンソールを使用します。コマンドラインインターフェースを使用してサーバーを管理するには、管理 CLI を使用します。
管理コンソールと管理 CLI の推奨管理ツールとして、上級ユーザーが希望する場合に独自のツールを開発できるようにする基礎となる管理 API の例も提供されています。

3.2. 管理アプリケーションプログラミングインターフェース (API)

HTTP API

管理コンソールは、Google Web Toolkit(GWT)で構築された Web インターフェースです。HTTP 管理インターフェースを使用してサーバーと通信します。

HTTP API エンドポイントは、管理レイヤーと統合するために HTTP プロトコルに依存する管理クライアントのエントリーポイントです。
HTTP プロトコルに依存する管理クライアントは、JSON でエンコードされたプロトコルとデタイプを使用しない RPC スタイルの API を使用して、管理対象ドメインまたはスタンドアロンサーバーに対して管理操作を記述および実行します。
HTTP API は管理コンソールによって使用されますが、他のクライアントの統合機能も提供します。
HTTP API エンドポイントはドメインコントローラーまたはスタンドアロンサーバーインスタンスと同じ場所に置かれます。管理操作を実行するコンテキストと、Web インターフェースにアクセスするためのコンテキストが 2 つあります。デフォルトでは、HTTP API エンドポイントはポート 9990 で実行されます。

例3.1 HTTP API 設定ファイルの例

<management-interfaces>
  [...]
  <http-interface security-realm="ManagementRealm">
     <socket-binding http="management-http"/>
  </http-interface>
</management-interfaces>
Copy to Clipboard Toggle word wrap
管理コンソールは、HTTP 管理 API と同じポートで提供されます。デフォルトの localhost でアクセスされる管理コンソール、特定のホストとポートの組み合わせによってリモートでアクセスされる管理コンソール、および公開されるドメイン API を区別することが重要です。
Expand
表3.1 管理コンソールまたは公開される HTTP API へのアクセスに使用する URL
URL 説明
http://localhost:9990/console ローカルホストでアクセスされる管理コンソール (管理対象ドメイン設定を制御します)。
http://hostname:9990/console リモートでアクセスされる管理コンソール (ホストを指定し、管理対象ドメイン設定を制御します)。
http://hostname:9990/management HTTP 管理 API は管理コンソールと同じポートで実行され、API に公開された raw 属性と値を表示します。

例3.2 HTTP API を使用した属性値の取得

以下の URL は HTTP Web コネクター属性値を取得します(デフォルトの操作は read-resourceです)。
http://hostname:9990/management/subsystem/web/connector/http
Copy to Clipboard Toggle word wrap

例3.3 HTTP API を使用した単一の属性値の取得

以下の URL は、ExampleDS データソースの enabled 属性を取得します。
http://hostname:9990/management/subsystem/datasources/data-source/ExampleDS?operation=attribute&name=enabled
Copy to Clipboard Toggle word wrap
HTTP API を使用してアプリケーションをデプロイする方法は、「HTTP API を使用したアプリケーションのデプロイ」 を参照してください。

ネイティブ API

管理 CLI はネイティブ API ツールです。これは管理対象ドメインまたはスタンドアロンサーバーインスタンスで利用でき、管理者はドメインコントローラーまたはスタンドアロンサーバーインスタンスに接続し、デタイプな管理モデルを介して利用可能な管理操作を実行できます。

ネイティブ API エンドポイントは、ネイティブプロトコルに依存して管理レイヤーと統合する管理クライアントのエントリーポイントです。管理操作の記述および実行には、非常に少数の Java タイプに基づいた、オープンバイナリープロトコルと RPC スタイルの API を使用します。これは、管理 CLI 管理ツールによって使用されますが、他のクライアントの統合機能も提供します。
ネイティブ API エンドポイントはホストコントローラーまたはスタンドアロンサーバーと共存します。管理 CLI を使用するには、これを有効にする必要があります。デフォルトでポート 9999 で実行されます。

例3.4 ネイティブ API 設定ファイルの例

<management-interfaces>
  <native-interface security-realm="ManagementRealm">
    <socket-binding native="management-native"/>
  </native-interface>
  [...]
</management-interfaces>
Copy to Clipboard Toggle word wrap

3.3. 管理コンソール

3.3.1. 管理コンソール

管理コンソールは JBoss EAP 6 の Web ベースの管理ツールです。
管理コンソールを使用して、サーバーの起動および停止、アプリケーションのデプロイおよびアンデプロイ、システム設定の調整、サーバー設定への永続的な変更を行います。管理コンソールは管理タスクも実行でき、変更があればサーバーインスタンスの再起動またはリロードが必要な場合はライブ通知も行います。
管理対象ドメインでは、同じドメイン内のサーバーインスタンスやサーバーグループをドメインコントローラーの管理コンソールから集中管理できます。

3.3.2. 管理コンソールへのログイン

前提条件

  • JBoss EAP 6 が稼働している必要があります。
  • コンソールにアクセスするためのパーミッションを持つユーザーがすでに作成されている必要があります。
  1. Web ブラウザーを起動し、以下のアドレスに移動します。 http://localhost:9990/console/App.html
    注記
    ポート 9990 は、管理コンソールソケットバインディングとして事前定義されています。
  2. 管理コンソールにログインするためのユーザー名とパスワードを入力します。

    図3.1 管理コンソールのログイン画面

結果

ログインすると、以下のアドレスにリダイレクトされ、管理コンソールのランディングページが表示されます。 http://localhost:9990/console/App.html#home

3.3.3. 管理コンソールの言語の変更

Web ベースの管理コンソールの言語設定では、デフォルトで英語が使用されます。以下の言語のいずれかを選択できます。

サポートされている言語

  • ドイツ語 (de)
  • 簡体中国語 (zh-Hans)
  • ブラジルポルトガル語 (pt-BR)
  • フランス語 (fr)
  • スペイン語 (es)
  • 日本語 (ja)

手順3.1 Web ベース管理コンソールの言語の変更

  1. 管理コンソールへのログイン

    Web ベースの管理コンソールにログインします。
  2. Settings ダイアログを開きます。

    画面の右下付近には Settings ラベルがあります。クリックして管理コンソールの設定を開きます。
  3. 必要な言語を選択します。

    Locale 選択ボックスから希望の言語を選択します。Save を選択します。確認ボックスに、アプリケーションのリロードが必要であると表示されます。Confirm をクリックします。システムは、Web ブラウザーを自動的に更新し、新しいロケールを使用します。

3.3.4. JBoss EAP コンソールの分析

Google Analytics とは

Google Analytics は、Web サイトに包括的な使用統計を提供する、無料の Web 分析サービスです。サイトへのアクセス、ページビュー、アクセスごとのページ、およびサイトに費やした平均時間など、サイトに関する重要なデータを提供します。Google Analytics を使用すると、Web サイトの存在と、その機能をより明確に把握することができます。

JBoss EAP 管理コンソールの Google Analytics

JBoss EAP 6 では、管理コンソールで Google Analytics を有効または無効にするオプションを利用できます。Google Analytics 機能は、お客様がコンソールをどのように使用するか、コンソールのどの部分がお客様の最も重要かについて、Red Hat EAP チームが理解できるようにしています。この情報は、チームがコンソールの設計、機能、およびコンテンツを顧客の即時のニーズに適応させるのに役立つものです。

備考
デフォルトでは、JBoss EAP 6 コンソールで Google Analytics が無効になり、その使用は任意です。

3.3.5. JBoss EAP コンソールでの Google Analytics の有効化

JBoss EAP 管理コンソールで Google Analytics を有効にするには、以下を行います。
  • 管理コンソールへのログイン
  • 管理 コンソールの設定 をクリック

    図3.2 管理コンソールのログイン画面

  • Settings ダイアログで Enable Usage Data Collection チェックボックスを選択し、Save ボタンをクリックします。アプリケーションのリロードを確認し、新しい設定を有効にします。

    図3.3 Settings ダイアログ(使用率データの収集を有効化)

3.3.6. JBoss EAP コンソールでの Google Analytics の無効化

JBoss EAP 管理コンソールで Google Analytics を無効にするには、以下を行います。
  • 管理コンソールへのログイン
  • 管理 コンソールの設定 をクリック

    図3.4 管理コンソールのログイン画面

  • Settings ダイアログの Enable Usage Data Collection オプションの選択を解除して、選択を削除します。Save ボタンをクリックします。アプリケーションのリロードを確認し、新しい設定を有効にします。

    図3.5 Settings ダイアログ(使用率データの収集を無効化)

3.3.7. 管理コンソールを使用したサーバーの設定

手順3.2 サーバーの設定

  1. コンソールの上部から ドメイン タブを選択します。利用可能なサーバーインスタンスが表に表示されます。
  2. Server Configurations をクリックします。
    関連するホストの Server Configurations パネルが表示されます。
  3. Available Server Configurations テーブルからサーバーインスタンスを選択します。
  4. 選択したサーバーの詳細の上に Edit をクリックします。
  5. 設定属性を変更します。
  6. Save をクリックして終了します。

図3.6 サーバー構成

結果

サーバー設定が変更され、サーバーが次回再起動したときに変更が反映されます。

3.3.8. 管理コンソールでのデプロイメントの追加

  1. コンソールの上部にある Deployments タブを選択します。
  2. コンテンツリポジトリー タブで 追加 を選択します。Create Deployment ダイアログボックスが表示されます。

    図3.7 スタンドアロンデプロイメントの管理

  3. ダイアログボックスで、Browse をクリックします。デプロイするファイルを参照し、これを選択してアップロードします。Next をクリックして先に進みます。

    図3.8 デプロイメントの選択

  4. Create Deployments ダイアログボックスで表示されるデプロイメント名とランタイム名を確認します。名前を確認したら、Save をクリックしてファイルをアップロードします。

結果

選択したコンテンツがサーバーにアップロードされ、デプロイメント可能になります。

3.3.9. 管理コンソールでのサーバーの新規作成

手順3.3 サーバー設定の新規作成

  1. 管理コンソールの Server Configurations ページに移動します。

    コンソールの上部から ドメイン タブを選択します。

    図3.9 サーバー設定

  2. 左側のメニューの Server Configurations をクリックします。
  3. 設定の新規作成

    1. Available Server Configurations の表の上にある Add ボタンを選択します。
    2. 「サーバー構成の 作成 」ダイアログに、基本的なサーバー設定を入力します。
    3. Save ボタンを選択して、新しいサーバー設定を保存します。

    図3.10 設定の新規作成

3.3.10. 管理コンソールを使用したデフォルトログレベルの変更

手順3.4 ロギングレベルの編集

  1. 管理コンソールの Logging パネルに移動します。

    1. 管理対象ドメインを使用している場合は、コンソールの上部にある Configuration タブを選択し、コンソールの左側にあるドロップダウンリストから関連するプロファイルを選択します。
    2. 管理対象ドメインまたはスタンドアロンサーバーの場合は、コンソールの左側にある一覧から Core メニューを展開し、Logging エントリーをクリックします。
    3. コンソールの上部にある Log Categories タブをクリックします。

    図3.11 ロギングパネル

  2. ロガー詳細の編集

    ログカテゴリー テーブルのエントリーの詳細を編集します。
    1. Log Categories テーブルのエントリーを選択し、以下の Details セクションで Edit をクリックします。
    2. Log Level ドロップダウンボックスでカテゴリーのログレベルを設定します。終了したら Save ボタンをクリックします。

結果

該当するカテゴリーのログレベルが更新されます。

3.3.11. 管理コンソールでのサーバーグループの新規作成

手順3.5 サーバーグループの新規作成および追加

  1. Server Groups ビューに移動します。

    コンソールの上部から ドメイン タブを選択します。
  2. 左側の列で Server Groups を選択します。

    図3.12 サーバー グループ ビュー

  3. サーバーグループの追加

    追加 ボタンをクリックして、新しいサーバーグループを追加します。
  4. サーバーグループの設定

    1. サーバーグループ名を入力します。
    2. サーバーグループのプロファイルを選択します。
    3. サーバーグループのソケットバインディングを選択します。
    4. Save ボタンをクリックして、新規グループを保存します。

    図3.13 サーバー グループの作成 ダイアログ

結果

新規サーバーグループが管理コンソールに表示されるようになります。

3.3.12. 管理コンソールでのログの表示

JBoss EAP 6 管理コンソールでサーバーおよびアプリケーションログを表示して、エラー、パフォーマンスの問題、およびその他の問題の診断に役立ちます。管理コンソールログビューアーでログを表示できるようにするには、サーバーの jboss.server.log.dir ディレクトリーにある必要があります。JBoss EAP 6 の Log Viewer はユーザー RBAC ロールの割り当ても考慮するため、管理コンソールにログインしているユーザーはアクセスが許可されているログのみを表示できます。

手順3.6 管理コンソールでの JBoss EAP 6 ログの表示

  1. 管理コンソールの上部から Runtime タブを選択します。
    1. 管理対象ドメインを使用している場合は、左側のメニューの Change Server ボタンを使用して、ログを表示する JBoss EAP 6 サーバーを選択します。
  2. 左側の Platform メニューを展開し、Log Viewer を選択します。
  3. 一覧からログファイルを選択し、表示 ボタンをクリックします。
    Download をクリックして、ログファイルをローカルマシンにダウンロードすることもできます。
    注記
    管理コンソールログビューアーは、15MB を超えるログファイルを開こうとすると確認を表示します。
    管理コンソールログビューアーは、非常に大きなログファイル(>100MB)を表示するテキストエディターの代わりとして使用するものではありません。管理コンソールログビューアーで非常に大きなログファイルを開くと Web ブラウザーがクラッシュする可能性があるため、大きなログファイルを常にダウンロードして、テキストエディターで開く必要があります。
  4. 選択したログは、管理コンソールの新しいタブとして開きます。LOG FILES タブに戻り、直前の手順を繰り返すと、他のタブで複数のログファイルを開くことができます。

3.3.13. 管理コンソールでのカスタマーポータルの統合

access.redhat.com インターフェースを使用して、JBoss EAP インストールの管理コンソールを残さずに Red Hat カスタマーポータルのセクションを参照できます。
管理コンソールのトップナビゲーションバーには、Red Hat Access のドロップダウンメニューが含まれます。このメニューをクリックすると、カスタマーポータルへのタスク固有の 3 つのリンクが表示されます。
  • カスタマーポータルの検索
  • ケースの作成
  • ケースの修正
これらの各リンクの機能は、以下で詳しく説明されています。
注記
これらのリンクのいずれかをクリックすると、カスタマーポータルにログインしていない場合は、ダイアログボックスが表示され、ログインが求められます。管理コンソールへのアクセスに使用するブラウザーセッションで、カスタマーポータルにログインする必要があります。あるブラウザーでカスタマーポータルにログインしていて、別のブラウザーを使用して管理コンソールにアクセスする場合は、ログインするよう要求されます。
カスタマーポータルの検索
Search Customer Portal をクリックすると、検索ボックスが含まれるページが表示されます。検索用語またはフレーズを入力して、ナレッジベースのアーティクルを見つけることができます。
検索を実行したら、結果の一覧から項目を選択し、別のペインに表示される記事全体を表示できます。
ケースの作成
Open Case ページでは、新しいサポートケースを作成できます。
新しいサポートケースを作成するには、完了するフォームが表示されます。推奨されるナレッジベースアーティクルの一覧がフォームのほかに提供されています。この一覧は、サポートケースに指定された詳細に基づいて更新されます。
ケースの修正
Modify Case ページでは、既存のサポートケースを表示および変更できます。
結果を絞り込むには、検索を分類またはグループ化解除します。また、ケースの状態(オープン、クローズ、またはいずれか)で検索を限定することができます。
特定のサポートケースを選択したら、サポートケースの詳細を表示または更新し、コメントを追加できます。

3.4. 管理 CLI

3.4.1. 管理コマンドラインインターフェース (CLI)

管理コマンドラインインターフェース (CLI) は、JBoss EAP 6 のコマンドライン管理ツールです。
管理 CLI を使用して、サーバーの起動および停止、アプリケーションのデプロイおよびアンデプロイ、システム設定の構成、他の管理タスクの実行を行います。操作はバッチモードで実行可能で、複数のタスクをグループとして実行できます。

3.4.2. 管理 CLI の起動

手順3.7 Linux または Microsoft Windows Server での CLI の起動

    • Linux での CLI の起動

      EAP_HOME/bin/jboss-cli.sh ファイルをコマンドラインで入力して実行します。
      $ EAP_HOME/bin/jboss-cli.sh
      Copy to Clipboard Toggle word wrap
    • Microsoft Windows Server での CLI の起動

      EAP_HOME\bin\jboss-cli.bat ファイルをダブルクリックするか、コマンドラインで以下のコマンドを入力して実行します。
      C:\>EAP_HOME\bin\jboss-cli.bat
      Copy to Clipboard Toggle word wrap

3.4.3. 管理 CLI の終了

管理 CLI で、quit コマンドを入力します。
[domain@localhost:9999 /] quit
Copy to Clipboard Toggle word wrap

3.4.4. 管理 CLI を使用した管理対象サーバーインスタンスへの接続

手順3.8 管理対象サーバーインスタンスへの接続

  • connect コマンドの実行

    管理 CLI で connect コマンドを入力します。
    [disconnected /] connect
    Connected to domain controller at localhost:9999
    Copy to Clipboard Toggle word wrap
    • Linux システムで管理 CLI を起動するときに管理対象サーバーに接続するには、--connect パラメーターを使用します。
      $ EAP_HOME/bin/jboss-cli.sh --connect
      Copy to Clipboard Toggle word wrap
    • --connect パラメーターを使用すると、サーバーのホストとポートを指定できます。ポート値 9999 でアドレス 192.168.0.1 に接続するには、以下が適用されます。
      $ EAP_HOME/bin/jboss-cli.sh --connect --controller=192.168.0.1:9999
      Copy to Clipboard Toggle word wrap

3.4.5. 管理 CLI でのヘルプの取得

概要

CLI コマンドを学習したり、何ができるかわからない場合に、ガイダンスが必要になる場合があります。管理 CLI は、一般的なオプションおよびコンテキスト依存オプションに関するヘルプダイアログを特長としています。(操作コンテキストに依存する help コマンドには、スタンドアロンまたはドメインコントローラーへの確立された接続が必要になることに注意してください。接続が確立されない限り、これらのコマンドはリストに表示されません。)

  1. 一般的なヘルプの場合

    管理 CLI で、help コマンドを入力します。
    [standalone@localhost:9999 /] help
    Copy to Clipboard Toggle word wrap
  2. 状況依存ヘルプの取得

    管理 CLI で、help -commands extended コマンドを入力します。
    [standalone@localhost:9999 /] help --commands
    Copy to Clipboard Toggle word wrap
  3. 特定のコマンドの詳細な説明については、コマンドを入力してから --help を付けてください。
    [standalone@localhost:9999 /] deploy --help
    Copy to Clipboard Toggle word wrap

結果

CLI ヘルプ情報が表示されます。

3.4.6. バッチモードでの管理 CLI の使用

概要

バッチ処理により、複数の操作リクエストをシーケンスにグループ化し、ユニットとして一緒に実行できます。シーケンスの操作リクエストのいずれかが失敗すると、操作のグループ全体がロールバックされます。

注記
バッチモードは条件付きステートメントをサポートしません。

手順3.9 バッチモードのコマンドおよび操作

  1. バッチモードの開始

    batch コマンドでバッチモードを 開始 します。
    [standalone@localhost:9999 /] batch
    Copy to Clipboard Toggle word wrap
    バッチモードになると、プロンプトにハッシュ (#) が表示されます。
  2. バッチへの操作要求の追加

    バッチモードでは、通常通りに操作リクエストを入力します。操作リクエストは、入力順にバッチに追加されます。
    操作リクエストのフォーマットに関する詳細は、「管理 CLI での操作およびコマンドの使用」 を参照してください。
  3. バッチの実行

    操作リクエストのシーケンス全体を入力したら、run-batch コマンドでバッチを実行します。
    [standalone@localhost:9999 / #] run-batch
    The batch executed successfully.
    Copy to Clipboard Toggle word wrap
    バッチ処理で使用できるコマンドの完全リストは、「CLI のバッチモードコマンド」 を参照してください。
  4. 外部ファイルに保存されたバッチコマンド

    頻繁に実行する batch コマンドは、外部テキストファイルに保存できます。batch コマンドの引数として完全パスをファイルに渡すか、run- batch コマンドの引数として直接実行することができます。
    テキストエディターを使用して、batch コマンドファイルを作成できます。各コマンドは 1 行で記載する必要があり、CLI はこれにアクセスできる必要があります。
    以下のコマンドは、myscript.txt ファイルをバッチモードで読み込みます。このファイルのすべてのコマンドを編集または削除できるようになりました。新しいコマンドを挿入することもできます。このバッチセッションでの変更は、myscript.txt ファイルに永続化されません。
    [standalone@localhost:9999 /] batch --file=myscript.txt
    Copy to Clipboard Toggle word wrap
    次のコマンドは、myscript.txtファイルに保存されている batch コマンドを即座に実行します。
    [standalone@localhost:9999 /] run-batch --file=myscript.txt
    Copy to Clipboard Toggle word wrap

結果

入力された操作リクエストのシーケンスがバッチとして完了します。

3.4.7. CLI のバッチモードコマンド

以下の表は、JBoss EAP 6 CLI で使用できる有効なバッチコマンドのリストを示しています。これらのコマンドはバッチ処理のみに使用できます。
Expand
表3.2 CLI のバッチモードコマンド
コマンド名 説明
list-batch 現在のバッチのコマンドおよび操作のリスト
edit-batch-line line-number edited-command 編集する行番号と編集されたコマンドを提供して、現在のバッチの行を編集します。例: edit-batch-line 2 data-source disable --name=ExampleDS.
move-batch-line fromline toline 最初の引数としたい行番号と 2 つ目の引数としての新たポジションを指定して、バッチの行の順番を変えます。例: move-batch-line 3 1
remove-batch-line linenumber 指定の行で batch コマンドを削除します。例: remove-batch-line 3
holdback-batch [batchname]
このコマンドを使用すると、現在のバッチを延期または保存できます。バッチ以外の CLI で何かを突然実行する場合は、これを使用します。この保留されたバッチに戻るには、CLI コマンドラインで再度 batch を入力します。
holdback-batch コマンドの使用中にバッチ名を指定すると、バッチはその名前の下に保存されます。名前付きのバッチに戻るには、コマンド batchname を使用します。batchname なしで batch コマンドを呼び出すと、新しい(名前のない)バッチが開始されます。名前のない保留されたバッチは 1 つのみ存在できます。
保留されたすべてのバッチの一覧を表示するには、batch -l コマンドを使用します。
discard-batch 現在アクティブなバッチを破棄します。

3.4.8. 管理 CLI での操作およびコマンドの使用

手順3.10 要求の作成、設定、および実行

  1. 操作要求の構築

    操作リクエストを使用すると、管理モデルとの低レベルの対話が可能になります。サーバー設定を編集する制御方法を提供します。操作リクエストは 3 つの部分で構成されます。
    • スラッシュ(/)で始まる アドレス
    • コロン(:)で始まる 操作名
    • 括弧()内の任意の パラメーター セット。
    1. アドレスの特定

      設定はアドレス指定可能なリソースの階層ツリーとして表されます。各リソースノードは異なる操作のセットを提供します。アドレスは、操作を実行するリソースノードを指定します。アドレスは以下の構文を使用します。
      /node-type=node-name
      Copy to Clipboard Toggle word wrap
      • node-type は、リソースノード種別です。これは、設定 XML の要素名にマッピングされます。
      • node-name はリソースノード名です。これは、設定 XML の要素の name 属性にマッピングされます。
      • リソースツリーの各レベルは、スラッシュ(/)で区切ります。
      設定 XML ファイルを参照して、必要なアドレスを判断します。EAP_HOME/standalone/configuration/standalone.xml ファイルはスタンドアロンサーバーの設定を保持し、EAP_HOME/domain/configuration/domain.xml ファイルおよび EAP_HOME/domain/configuration/host.xml ファイルは管理対象ドメインの設定を保持します。
      注記
      ドメインモードで CLI コマンドを実行するには、ホストおよびサーバー仕様が必要です。例: /host=master/server=server-one/subsystem=logging

      例3.5 操作アドレスの例

      ロギングサブシステムで操作を実行するには、操作要求に以下のアドレスを使用します。
      /subsystem=logging
      Copy to Clipboard Toggle word wrap
      Java データソースに対して操作を実行するには、操作要求に以下のアドレスを使用します。
      /subsystem=datasources/data-source=java
      Copy to Clipboard Toggle word wrap
    2. 操作の特定

      操作は異なるタイプのリソースノードによって異なります。操作では、以下の構文を使用します。
      :operation-name
      Copy to Clipboard Toggle word wrap
      • operation-name はリクエストする操作の名前です。
      スタンドアロンサーバーのリソースアドレスで read-operation-names 操作を使用して、利用可能な操作を一覧表示します。

      例3.6 利用可能な操作

      ロギングサブシステムのすべての利用可能な操作をリストするために、スタンドアロンサーバーの以下の要求を入力します。
      [standalone@localhost:9999 /] /subsystem=logging:read-operation-names
      {
          "outcome" => "success",
          "result" => [
              "add",
              "read-attribute",
              "read-children-names",
              "read-children-resources",
              "read-children-types",
              "read-operation-description",
              "read-operation-names",
              "read-resource",
              "read-resource-description",
              "remove",
              "undefine-attribute",
              "whoami",
              "write-attribute"
          ]
      }
      Copy to Clipboard Toggle word wrap
    3. パラメーターの決定

      各操作では異なるパラメーターが必要な場合があります。
      パラメーターは以下の構文を使用します。
      (parameter-name=parameter-value)
      Copy to Clipboard Toggle word wrap
      • parameter-name は、パラメーターの名前です。
      • parameter-value は、パラメーターの値です。
      • 複数のパラメーターはコンマ (,) で区切られます。
      必要なパラメーターを確認するには、リソースノードで read-operation-description コマンドを実行し、操作名をパラメーターとして渡します。詳細は、例3.7「操作パラメーターの決定」 を参照してください。

      例3.7 操作パラメーターの決定

      ロギングサブシステムで read-children-types 操作に必要なパラメーターを決定するには、以下のように read-operation-description コマンドを入力します。
      [standalone@localhost:9999 /] /subsystem=logging:read-operation-description(name=read-children-types)
      {
          "outcome" => "success",
          "result" => {
              "operation-name" => "read-children-types",
              "description" => "Gets the type names of all the children under the selected resource",
              "reply-properties" => {
                  "type" => LIST,
                  "description" => "The children types",
                  "value-type" => STRING
              },
              "read-only" => true
          }
      }
      Copy to Clipboard Toggle word wrap
  2. 完全操作要求の入力

    アドレス、操作、およびパラメーターが決定されたら、完全操作要求を入力します。

    例3.8 操作要求の例

    [standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource(recursive=true)
    Copy to Clipboard Toggle word wrap

結果

管理インターフェースは、サーバー設定の操作要求を実行します。

3.4.9. 管理 CLI で if-else 制御フローを使用

管理 CLI は、条件に基づいて実行するコマンドおよび操作のセットを選択できる if - other 制御フローをサポートします。if 条件は、of キーワードの後に指定された管理コマンドまたは操作の応答を評価するブール式です。
以下の項目をどれでも式に含めることができます。
  • 条件演算子(&&, ||)
  • 比較演算子(>, >=, <=, ==, !=)
  • 式をグループ化および優先付けするかっこ

例3.9 管理 CLI コマンドでの if ステートメントの使用

この例では、システムプロパティー test の読み取りを試みます。outcomesuccess でない場合 (プロパティーが存在しないことを意味します)、システムプロパティーが追加され、true に設定されます。
if (outcome != success) of /system-property=test:read-resource
    /system-property=test:add(value=true)
end-if
Copy to Clipboard Toggle word wrap
上記の条件は、outcome を使用します。 これは、以下のように of キーワードの後の CLI コマンドが実行されると返されます。
[standalone@localhost:9999 /] /system-property=test:read-resource
{
    "outcome" => "failed",
    "failure-description" => "JBAS014807: Management resource '[(\"system-property\" => \"test\")]' not found",
    "rolled-back" => true
}
Copy to Clipboard Toggle word wrap

例3.10 if-else statement with 管理 CLI コマンドの使用

この例では、サーバープロセスの起動タイプ(STANDALONE または DOMAIN)をチェックし、適切な CLI コマンドを実行して ExampleDS データソースを有効にします。
if (result == STANDALONE) of /:read-attribute(name=launch-type)
    /subsystem=datasources/data-source=ExampleDS:write-attribute(name=enabled, value=true)
else
    /profile=full/subsystem=datasources/data-source=ExampleDS:write-attribute(name=enabled, value=true)
end-if
Copy to Clipboard Toggle word wrap
if-else control flow をファイルに指定すると(各行に 1 つずつ)管理 CLI コマンドを指定し、非対話的に実行するために jboss-cli.sh スクリプトに渡すことができます。
EAP_HOME/bin/jboss-cli.sh --connect --file=CLI_FILE
Copy to Clipboard Toggle word wrap
注記
入れ子の if-else ステートメントの使用はサポートされません。

3.4.10. 管理 CLI 設定オプション

管理 CLI 設定ファイル( jboss-cli.xml )は、CLI が起動されるたびにロードされます。$EAP_HOME/bin ディレクトリー、またはシステムプロパティー jboss.cli.config で指定されたディレクトリーのいずれかに存在する必要があります。
default-controller
connect コマンドがパラメーターなしで実行された場合に 接続 するコントローラーの設定。

default-controller パラメーター

host
コントローラーのホスト名。デフォルト: localhost
port
コントローラーに接続するポート番号。デフォルトは 9999 です。
validate-operation-requests
実行のためにリクエストがコントローラーに送信される前に、操作リクエストのパラメーターリストが検証されるかどうかを示します。Type: Booleanデフォルト: true
history
この要素には、コマンドおよび操作の履歴ログの設定が含まれます。

履歴 パラメーター

enabled
履歴 が有効になっているかどうかを示します。Type: Booleanデフォルト: true
file-name
履歴が保存されるファイルの名前。デフォルト = .jboss-cli-history.
file-dir
履歴が保存されるディレクトリー。Default = $USER_HOME
max-size
履歴ファイルの最大サイズ。デフォルトは 500 です。
resolve-parameter-values
操作リクエストをコントローラーに送信する前にコマンド引数(または操作パラメーター)の値として指定されたシステムプロパティーを解決するか、サーバー側で解決が発生するようにします。Type: BooleanDefault = false.
connection-timeout
コントローラーとの接続を確立できる時間。タイプ: 整数デフォルトは 5000 秒です。
ssl
この要素には、SSL に使用されるキーストアとトラストストアの設定が含まれます。
警告
Red Hat は、影響を受けるすべてのパッケージで TLSv1.1 または TLSv1.2 を利用するために SSL を明示的に無効にすることを推奨します。

SSL パラメーター

vault
タイプ: vaultType
key-store
タイプ: 文字列
key-store-password
タイプ: 文字列
alias
タイプ: 文字列
key-password
タイプ: 文字列
trust-store
タイプ: 文字列
trust-store-password
タイプ: 文字列
modify-trust-store
true に設定すると、認識されない証明書が受信されると、CLI はユーザーにプロンプトを表示し、トラストストアに保存できるようにします。Type: Booleanデフォルト: true

vaultType

code および module の指定がない場合、デフォルトの実装が使用されます。code は指定され、module は指定されていない場合、Picketbox モジュールで指定されたクラスを探します。モジュール コード が指定されている場合、「module」によって指定されたモジュールの コードによって指定されたクラスを探します。
code
タイプ: 文字列
module
型: 文字列
silent
情報およびエラーメッセージをターミナルに出力するかどうかを指定します。false が指定されている場合でも、設定が許可したり、出力ターゲットが > を使用してコマンドラインの一部として指定された場合、メッセージはロガーを使用してログに記録されます。デフォルトは False です。

3.4.11. 管理 CLI コマンドのリファレンス

概要

トピック 「管理 CLI でのヘルプの取得」 では、一般的なオプションおよびコンテキスト機密オプションに関するヘルプダイアログなど、管理 CLI ヘルプ機能にアクセスする方法を説明します。help コマンドは操作コンテキストに依存し、スタンドアロンまたはドメインコントローラーへの接続が確立されている必要があります。接続が確立されない限り、これらのコマンドはリストに表示されません。

Expand
表3.3
コマンド 説明
batch 新しいバッチを作成してバッチモードを開始するか、既存の保留中のバッチに応じてバッチモードを再度アクティブにします。保留されたバッチがない場合は、引数なしで呼び出されると新しいバッチが開始されます。名前のない保留されたバッチがある場合、このコマンドは再度アクティベートします。名前付きの保留されたバッチがある場合は、保留中のバッチ名を引数として指定することでアクティベートできます。
cd 現在のノードパスを引数に変更します。現在のノードパスは、アドレス部分を含まない操作要求のアドレスとして使用されます。操作要求にアドレスが含まれる場合、含まれるアドレスは現在のノードパスに対して相対的であると見なされます。現在のノードパスはノードタイプで終了します。この場合、logging:read-resource などの node-name を指定する操作を実行するには十分です。
明確な 画面を消去します。
command 既存の汎用タイプコマンドを追加、削除、および一覧表示できます。汎用型コマンドは、特定のノード型に割り当てられ、その型のインスタンスで実行できる操作の実行を可能にします。また、既存のインスタンスでその型によって公開されるプロパティーの編集も可能にします。
connect 指定されたホストおよびポートのコントローラに接続します。
connection-factory 接続ファクトリーを定義します。
data-source データソースサブシステムで JDBC データソース設定を管理します。
deploy ファイルパスで指定されたアプリケーションをデプロイするか、リポジトリーで無効にされている既存のアプリケーションを有効にします。引数を付けずに実行すると、既存のデプロイメントがすべて表示されます。
echo
JBoss EAP 6.4 からは、echo コマンドは指定されたテキストに出力されます。テキストはそのまま出力されるため、変数の使用は利用できません。
例:
echo Phase one complete
Copy to Clipboard Toggle word wrap
help ヘルプメッセージを表示します。--commands 引数と共に使用して、指定のコマンドにコンテキストの機密結果を提供できます。
history メモリーの CLI コマンド履歴を表示し、履歴の拡張が有効または無効であるかを表示します。引数と共に使用すると、必要に応じて履歴拡張を消去、無効化、および有効にできます。
jms-queue メッセージングサブシステムで JMS キューを定義します。
jms-topic メッセージングサブシステムで JMS トピックを定義します。
ls ノードパスの内容を一覧表示します。デフォルトでは、ターミナルの幅全体を使用して結果が列に出力されます。-l スイッチを使用すると、1 行に 1 つの名前で結果が出力されます。
pwd 現在の作業ノードの完全ノードパスを出力します。
quit コマンドラインインターフェースを終了します。
read-attribute 値を表示し、引数によっては管理されたリソースの属性の詳細も表示します。
read-operation 指定された操作の詳細を表示します。 指定がない場合は使用できる操作をすべて表示します。
undeploy 目的のアプリケーションの名前を指定して実行する場合にアプリケーションをアンデプロイします。引数を指定して実行し、アプリケーションをリポジトリーから削除することもできます。アプリケーションの指定なしで実行された既存デプロイメントの一覧を出力します。
version アプリケーションサーバーバージョンと環境情報を出力します。
xa-data-source データソースサブシステムで JDBC XA データソース設定を管理します。

3.4.12. 管理 CLI 操作のリファレンス

管理 CLI の操作の公開

管理 CLI の操作は、トピック 「管理 CLI を使用した操作名の表示」 で説明されている read-operation-names 操作を使用すると公開できます。操作の説明は、トピック 「管理 CLI を使用した操作説明の表示」 で説明されている read-operation-descriptions 操作を使用すると表示できます。

Expand
表3.4 管理 CLI の操作
操作名 説明
add-namespace namespaces 属性のマップに名前空間接頭辞のマッピングを追加します。
add-schema-location schema-locations 属性のマップにスキーマロケーションマッピングを追加します。
delete-snapshot snapshots ディレクトリーからサーバー設定のスナップショットを削除します。
full-replace-deployment 以前にアップロードしたデプロイメントコンテンツを使用可能なコンテンツの一覧に追加し、ランタイムの同じ名前の既存コンテンツを置き換え、利用可能なコンテンツの一覧から置き換えたコンテンツを削除します。詳細は、リンクを参照してください。
list-snapshots snapshots ディレクトリーに保存されているサーバー設定のスナップショットを一覧表示します。
read-attribute 選択したリソースの属性の値を表示します。
read-children-names 指定の型を持つ選択したリソースの配下にある子の名前をすべて表示します。
read-children-resources 指定のタイプであるすべての子リソースに関する情報を表示します。
read-children-types 選択したリソースの配下にある子すべての型名を表示します。
read-config-as-xml 現在の設定を読み込み、XML 形式で表示します。
read-operation-description 特定のリソースに対する操作の詳細を表示します。
read-operation-names 特定のリソースに対する全操作の名前を表示します。
read-resource モデルリソースの属性値および任意の子リソースの基本情報もしくは詳細情報を表示します。
read-resource-description リソースの属性、子リソースのタイプ、および操作についての詳細を表示します。
reload すべてのサービスを終了し、再起動することでサーバーをリロードします。
remove-namespace namespaces 属性マップから名前空間接頭辞のマッピングを削除します。
remove-schema-location schema-locations 属性マップからスキーマロケーションマッピングを削除します。
replace-deployment ランタイムの既存のコンテンツを新しいコンテンツに置き換えます。新しいコンテンツを事前にデプロイメントコンテンツリポジトリーにアップロードする必要があります。
resolve-expression 式を、式へ解析可能な入力または文字列として許可し、ローカルのシステムプロパティーおよび環境変数に対して解決する操作です。
resolve-internet-address インターフェース解決基準を取り、その基準と一致するローカルマシンの IP アドレスを見つけます。一致する IP アドレスが見つからない場合は失敗します。
server-set-restart-required 再起動が必要なモードにサーバーを設定します。
shutdown System.exit(0)への呼び出しにより、サーバーをシャットダウンします
start-servers 現在実行されていないすべての設定済みサーバーを管理対象ドメインで起動します。
stop-servers 管理対象ドメインで現在実行しているすべてのサーバーを停止します。
take-snapshot サーバー設定のスナップショットを作成し、snapshots ディレクトリーに保存します。
upload-deployment-bytes 含まれたバイトアレイのデプロイメントコンテンツをデプロイメントコンテンツリポジトリーに追加すべきであることを示します。この操作は、コンテンツをランタイムにデプロイすべきかは指定していません。
upload-deployment-stream 対象入力ストリームインデックスで利用可能なデプロイメントコンテンツをデプロイメントコンテンツレポジトリーに追加すべきか指定します。この操作は、コンテンツをランタイムにデプロイすべきかは指定していません。
upload-deployment-url 対象の URL で利用可能なデプロイメントコンテンツをデプロイメントコンテンツリポジトリーに追加すべきかを指定します。この操作は、コンテンツをランタイムにデプロイすべきかは指定していません。
validate-address 操作のアドレスを検証します。
write-attribute 選択したリソースの属性値を設定します。

3.4.13. 管理 CLI におけるプロパティーの置換

JBoss EAP 6 は、管理インターフェースの Preset 要素およびプロパティー式の使用をサポートします。これらの式は、コマンドの実行中に定義された値に解決されます。
以下のプロパティーは式に置き換えることができます。
  • 操作リクエストの操作アドレス部分(ノードタイプまたは名前として)。
  • 操作名。
  • 操作パラメーター名。
  • ヘッダー名および値。
  • コマンド名。
  • コマンド引数名。
デフォルトでは、CLI は引数またはパラメーターの値以外の各行に対してプロパティー置換を実行します。引数およびパラメーターの値は起動時にサーバーで解決されます。引数またはパラメーターの値のプロパティー置換を管理 CLI クライアントで行い、解決された値をサーバーに送信する必要がある場合は、以下の手順を実行します。

手順3.11 管理 CLI でのプロパティー置換の有効化

  1. EAP_HOME/bin/jboss-cli.xml ファイルを開きます。
  2. resolve-parameter-values パラメーターを見つけ、値を true に変更します(デフォルトは falseです)。
    <!-- whether to resolve system properties specified as command argument or operation parameter values in the Management CLI VM before sending the operation requests to the controller -->
        <resolve-parameter-values>true</resolve-parameter-values>
    
    Copy to Clipboard Toggle word wrap
この要素は、操作リクエストのパラメーターの値とコマンド引数の値のみに影響します。他のコマンドラインには影響しません。これは、パラメーター/引数の値でない限り、resolve-parameter-values 要素の値に関係なく、コマンドラインに存在するシステムプロパティーが行の解析中に解決されることを意味します。
他の管理 CLI の設定オプションについては、「管理 CLI 設定オプション」 を参照してください。
管理 CLI コマンドで使用されるシステム値は、すでに定義されている必要があることに注意してください。管理 CLI インスタンスの起動時に、--properties=/path/to/file.properties 引数または 1 つ以上の -Dkey=VALUE パラメーターを含める必要があります。プロパティーファイルは標準の key=value 構文を使用します。
プロパティーキーは、構文 ${MY_VAR} を使用して管理 CLI コマンドに表示されます。

例3.11 例: 管理 CLI コマンドでのプロパティーの使用

/subsystem=datasources/data-source=${datasourcename}:add(connection-url=jdbc:oracle:thin:@server:1521:ora1, jndi-name=java:/jboss/${name}, driver-name=${drivername})
Copy to Clipboard Toggle word wrap

3.5. 管理 CLI 操作

3.5.1. 管理 CLI によるリソースの属性の表示

概要

read-attribute 操作は、選択した属性の現在のランタイム値を読み取るために使用されるグローバル操作です。これは、ユーザーが設定した値のみを公開するために使用できます(デフォルト値または未定義の値を無視します)。要求プロパティーには、以下のパラメーターが含まれます。

要求プロパティー

name
選択したリソース下で値を取得する属性の名前。
include-defaults
ユーザーが設定した属性のみを表示したり、デフォルト値を無視するように操作結果を制限したりするために false に設定されるブール値パラメーターです。

手順3.12 選択した属性の現在のランタイム値を表示

  • read-attribute 操作の実行

    管理 CLI で read-attribute 操作を使用してリソース属性の値を表示します。操作リクエストの詳細は、「管理 CLI での操作およびコマンドの使用」 のトピックを参照してください。
    [standalone@localhost:9999 /]:read-attribute(name=name-of-attribute)
    Copy to Clipboard Toggle word wrap
read-attribute 操作の利点は、特定の属性の現在のランタイム値を公開する機能です。read-resource 操作でも同様の結果が得られますが、include-runtime 要求プロパティーを追加した場合のみ、そのノードで利用可能な全リソース一覧の一部としてしか実行できません。read-attribute 操作は、以下の例のように、詳細な属性クエリーを行うことを目的としています。

例3.12 read-attribute 操作を実行してパブリックインターフェース IP を公開します。

公開する属性の名前が分かっている場合は、read-attribute を使用して現在のランタイムの正確な値を返すことができます。
[standalone@localhost:9999 /] /interface=public:read-attribute(name=resolved-address)
{
    "outcome" => "success",
    "result" => "127.0.0.1"
}
Copy to Clipboard Toggle word wrap
resolved-address 属性はランタイムの値であるため、標準の read-resource 操作の結果には表示されません。
[standalone@localhost:9999 /] /interface=public:read-resource                        
{
    "outcome" => "success",
    "result" => {
        "any" => undefined,
        "any-address" => undefined,
        "any-ipv4-address" => undefined,
        "any-ipv6-address" => undefined,
        "inet-address" => expression "${jboss.bind.address:127.0.0.1}",
        "link-local-address" => undefined,
        "loopback" => undefined,
        "loopback-address" => undefined,
        "multicast" => undefined,
        "name" => "public",
        "nic" => undefined,
        "nic-match" => undefined,
        "not" => undefined,
        "point-to-point" => undefined,
        "public-address" => undefined,
        "site-local-address" => undefined,
        "subnet-match" => undefined,
        "up" => undefined,
        "virtual" => undefined
    }
}
Copy to Clipboard Toggle word wrap
resolved-address およびその他のランタイム値を表示するには、include-runtime リクエストプロパティーを使用する必要があります。
[standalone@localhost:9999 /] /interface=public:read-resource(include-runtime=true)
{
    "outcome" => "success",
    "result" => {
        "any" => undefined,
        "any-address" => undefined,
        "any-ipv4-address" => undefined,
        "any-ipv6-address" => undefined,
        "inet-address" => expression "${jboss.bind.address:127.0.0.1}",
        "link-local-address" => undefined,
        "loopback" => undefined,
        "loopback-address" => undefined,
        "multicast" => undefined,
        "name" => "public",
        "nic" => undefined,
        "nic-match" => undefined,
        "not" => undefined,
        "point-to-point" => undefined,
        "public-address" => undefined,
        "resolved-address" => "127.0.0.1",
        "site-local-address" => undefined,
        "subnet-match" => undefined,
        "up" => undefined,
        "virtual" => undefined
    }
}
Copy to Clipboard Toggle word wrap

結果

現在のランタイム属性値が表示されます。

3.5.2. 管理 CLI でのアクティブユーザーの表示

概要

whoami 操作は、現在アクティブなユーザーの属性を識別するために使用されるグローバル操作です。この操作は、ユーザー名の ID と、割り当てられたレルムを公開します。whoami 操作は、管理者が複数のレルムで複数のユーザーアカウントを管理する場合や、複数のターミナルセッションおよびユーザーアカウントを持つドメインインスタンス全体でアクティブなユーザーを追跡するのに役立ちます。

手順3.13 whoami 操作を使用した管理 CLI でのアクティブユーザーの表示

  • whoami 操作の実行

    管理 CLI で whoami 操作を使用してアクティブなユーザーアカウントを表示します。
    [standalone@localhost:9999 /] :whoami
    Copy to Clipboard Toggle word wrap
    以下の例は、スタンドアロンサーバーインスタンスで whoami 操作を使用して、アクティブなユーザーが username で、ユーザーが ManagementRealm レルムに割り当てられていることを示しています。

    例3.13 スタンドアロンインスタンスでの whoami の使用

    [standalone@localhost:9999 /]:whoami
    {
        "outcome" => "success",
        "result" => {"identity" => {
            "username" => "username",
            "realm" => "ManagementRealm"
        }}
    }
    
    Copy to Clipboard Toggle word wrap

結果

現在アクティブなユーザーのアカウントが表示されます。

3.5.3. 管理 CLI でのシステムおよびサーバー情報の表示

手順3.14 管理 CLI でのシステムおよびサーバー情報の表示

  • version コマンドの実行

    管理 CLI で version コマンドを入力します。
    [domain@localhost:9999 /] version
    Copy to Clipboard Toggle word wrap

結果

アプリケーションサーバーのバージョンと環境情報が表示されます。

3.5.4. 管理 CLI を使用した操作説明の表示

手順3.15 管理 CLI でのコマンドの実行

  • read-operation-description 操作を実行します。

    管理 CLI から read-operation-description を使用して、操作に関する情報を表示します。操作には、表示する操作を示すために、キーと値のペアの形式で追加のパラメーターが必要です。操作リクエストの詳細は、「管理 CLI での操作およびコマンドの使用」 のトピックを参照してください。
    [standalone@localhost:9999 /]:read-operation-description(name=name-of-operation)
    Copy to Clipboard Toggle word wrap

例3.14 list-snapshots 操作の説明表示

以下の例は、list-snapshots 操作を説明する方法を示しています。
[standalone@localhost:9999 /] :read-operation-description(name=list-snapshots)
{
    "outcome" => "success",
    "result" => {
        "operation-name" => "list-snapshots",
        "description" => "Lists the snapshots",
        "request-properties" => {},
        "reply-properties" => {
            "type" => OBJECT,
            "value-type" => {
                "directory" => {
                    "type" => STRING,
                    "description" => "The directory where the snapshots are stored",
                    "expressions-allowed" => false,
                    "required" => true,
                    "nillable" => false,
                    "min-length" => 1L,
                    "max-length" => 2147483647L
                },
                "names" => {
                    "type" => LIST,
                    "description" => "The names of the snapshots within the snapshots directory",
                    "expressions-allowed" => false,
                    "required" => true,
                    "nillable" => false,
                    "value-type" => STRING
                }
            }
        },
        "access-constraints" => {"sensitive" => {"snapshots" => {"type" => "core"}}},
        "read-only" => false
    }
}
Copy to Clipboard Toggle word wrap

結果

選択した操作に関する説明が表示されます。

3.5.5. 管理 CLI を使用した操作名の表示

手順3.16 管理 CLI でのコマンドの実行

  • read-operation-names 操作を実行します。

    管理 CLI から read-operation-names 操作を使用して、利用可能な操作の名前を表示します。操作リクエストの詳細は、「管理 CLI での操作およびコマンドの使用」 のトピックを参照してください。
    [standalone@localhost:9999 /]:read-operation-names
    Copy to Clipboard Toggle word wrap

例3.15 管理 CLI を使用した操作名の表示

以下の例は、read-operation-names 操作を説明する方法を示しています。
[standalone@localhost:9999 /]:read-operation-names
{
    "outcome" => "success",
    "result" => [
        "add-namespace",
        "add-schema-location",
        "delete-snapshot",
        "full-replace-deployment",
        "list-snapshots",
        "read-attribute",
        "read-children-names",
        "read-children-resources",
        "read-children-types",
        "read-config-as-xml",
        "read-operation-description",
        "read-operation-names",
        "read-resource",
        "read-resource-description",
        "reload",
        "remove-namespace",
        "remove-schema-location",
        "replace-deployment",
        "resolve-expression",
        "resolve-internet-address",
        "server-set-restart-required",
        "shutdown",
        "take-snapshot",
        "undefine-attribute",
        "upload-deployment-bytes",
        "upload-deployment-stream",
        "upload-deployment-url",
        "validate-address",
        "validate-operation",
        "whoami",
        "write-attribute"
    ]
}
Copy to Clipboard Toggle word wrap

結果

利用可能な操作名が表示されます。

3.5.6. 管理 CLI を使用した利用可能なリソースの表示

概要

read-resource 操作は、リソース値を読み取るために使用されるグローバル操作です。これは、現在のノードまたは子ノードのリソースに関する基本情報または完全な情報のいずれかを、操作結果の範囲を拡張するか、または制限する要求プロパティーの範囲を公開するために使用できます。要求プロパティーには、以下のパラメーターが含まれます。

要求プロパティー

recursive
子リソースに関する詳細情報を再帰的に含めるかどうか。
recursive-depth
含まれる子リソースの情報の深さ。
proxies
再帰クエリーにリモートリソースを含めるかどうか。たとえば、ドメインコントローラーのクエリーにスレーブホストコントローラーからのホストレベルのリソースを追加します。
include-runtime
永続設定から取得されない属性値などの応答にランタイム属性を含めるかどうか。この要求プロパティーはデフォルトで false に設定されます。
include-defaults
デフォルト属性の読み取りを有効または無効にするブール値要求プロパティー。false に設定すると、ユーザーが設定した属性のみが返され、未定義のままの属性は無視されます。

管理 CLI でのコマンドの実行

read-resource 操作を実行します。

管理 CLI で read-resource 操作を使用して利用可能なリソースを表示します。

[standalone@localhost:9999 /]:read-resource
Copy to Clipboard Toggle word wrap
以下の例は、スタンドアロンサーバーインスタンスで read-resource 操作を使用して一般的なリソース情報を公開する方法を示しています。結果は standalone.xml 設定ファイルに類似し、サーバーインスタンスにインストールまたは設定されたシステムリソース、拡張、インターフェース、およびサブシステムを表示します。これらはさらに直接クエリーできます。

例3.16 ルートレベルでの read-resource 操作の使用

[standalone@localhost:9999 /]:read-resource
{
    "outcome" => "success",
    "result" => {
        "management-major-version" => 1,
        "management-micro-version" => 0,
        "management-minor-version" => 7,
        "name" => "localhost",
        "namespaces" => [],
        "product-name" => "EAP",
        "product-version" => "6.4.0.GA",
        "profile-name" => undefined,
        "release-codename" => "Janus",
        "release-version" => "7.5.0.Final-redhat-17",
        "schema-locations" => [],
        "core-service" => {
            "service-container" => undefined,
            "server-environment" => undefined,
            "module-loading" => undefined,
            "platform-mbean" => undefined,
            "management" => undefined,
            "patching" => undefined
        },
        "deployment" => undefined,
        "deployment-overlay" => undefined,
        "extension" => {
            "org.jboss.as.clustering.infinispan" => undefined,
            "org.jboss.as.connector" => undefined,
            "org.jboss.as.deployment-scanner" => undefined,
            "org.jboss.as.ee" => undefined,
            "org.jboss.as.ejb3" => undefined,
            "org.jboss.as.jaxrs" => undefined,
            "org.jboss.as.jdr" => undefined,
            "org.jboss.as.jmx" => undefined,
            "org.jboss.as.jpa" => undefined,
            "org.jboss.as.jsf" => undefined,
            "org.jboss.as.logging" => undefined,
            "org.jboss.as.mail" => undefined,
            "org.jboss.as.naming" => undefined,
            "org.jboss.as.pojo" => undefined,
            "org.jboss.as.remoting" => undefined,
            "org.jboss.as.sar" => undefined,
            "org.jboss.as.security" => undefined,
            "org.jboss.as.threads" => undefined,
            "org.jboss.as.transactions" => undefined,
            "org.jboss.as.web" => undefined,
            "org.jboss.as.webservices" => undefined,
            "org.jboss.as.weld" => undefined
        },
        "interface" => {
            "management" => undefined,
            "public" => undefined,
            "unsecure" => undefined
        },
        "path" => {
            "jboss.server.temp.dir" => undefined,
            "user.home" => undefined,
            "jboss.server.base.dir" => undefined,
            "java.home" => undefined,
            "user.dir" => undefined,
            "jboss.server.data.dir" => undefined,
            "jboss.home.dir" => undefined,
            "jboss.server.log.dir" => undefined,
            "jboss.server.config.dir" => undefined,
            "jboss.controller.temp.dir" => undefined
        },
        "socket-binding-group" => {"standard-sockets" => undefined},
        "subsystem" => {
            "jaxrs" => undefined,
            "jsf" => undefined,
            "jca" => undefined,
            "jmx" => undefined,
            "threads" => undefined,
            "webservices" => undefined,
            "sar" => undefined,
            "remoting" => undefined,
            "infinispan" => undefined,
            "weld" => undefined,
            "ejb3" => undefined,
            "transactions" => undefined,
            "datasources" => undefined,
            "deployment-scanner" => undefined,
            "logging" => undefined,
            "jdr" => undefined,
            "pojo" => undefined,
            "jpa" => undefined,
            "naming" => undefined,
            "ee" => undefined,
            "mail" => undefined,
            "web" => undefined,
            "resource-adapters" => undefined,
            "security" => undefined
        },
        "system-property" => undefined
    }
}
Copy to Clipboard Toggle word wrap

子ノードに対する read-resource 操作を実行します。

read-resource 操作を実行して、ルートから子ノードをクエリーできます。オペレーションの構造は最初に公開するノードを定義し、続いてこれに対して実行する操作を追加します。

[standalone@localhost:9999 /]/subsystem=web/connector=http:read-resource
Copy to Clipboard Toggle word wrap
以下の例では、特定の Web サブシステムノードに read-resource 操作を行うと、Web サブシステムコンポーネントに関する特定のリソース情報を公開できます。

例3.17 ルートノードからの子ノードリソースの公開

[standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource                      
{
    "outcome" => "success",
    "result" => {
        "configuration" => undefined,
        "enable-lookups" => false,
        "enabled" => true,
        "executor" => undefined,
        "max-connections" => undefined,
        "max-post-size" => 2097152,
        "max-save-post-size" => 4096,
        "name" => "http",
        "protocol" => "HTTP/1.1",
        "proxy-name" => undefined,
        "proxy-port" => undefined,
        "redirect-port" => 443,
        "scheme" => "http",
        "secure" => false,
        "socket-binding" => "http",
        "ssl" => undefined,
        "virtual-server" => undefined
    }
}
Copy to Clipboard Toggle word wrap
cd コマンドを使用して子ノードに移動し、read-resource 操作を直接実行しても、同じ結果が得られます。

例3.18 ディレクトリーの変更による子ノードリソースの公開

[standalone@localhost:9999 /] cd subsystem=web
Copy to Clipboard Toggle word wrap
[standalone@localhost:9999 subsystem=web] cd connector=http
Copy to Clipboard Toggle word wrap
[standalone@localhost:9999 connector=http] :read-resource
{
    "outcome" => "success",
    "result" => {
        "configuration" => undefined,
        "enable-lookups" => false,
        "enabled" => true,
        "executor" => undefined,
        "max-connections" => undefined,
        "max-post-size" => 2097152,
        "max-save-post-size" => 4096,
        "name" => "http",
        "protocol" => "HTTP/1.1",
        "proxy-name" => undefined,
        "proxy-port" => undefined,
        "redirect-port" => 443,
        "scheme" => "http",
        "secure" => false,
        "socket-binding" => "http",
        "ssl" => undefined,
        "virtual-server" => undefined
    }
}
Copy to Clipboard Toggle word wrap

再帰的なパラメーターを使用して結果にアクティブな値を含める

再帰的なパラメーターを使用すると、すべての属性の値 (永続的でない値、起動時に渡された値、ランタイムモデルでアクティブな他の属性など) を公開できます。

[standalone@localhost:9999 /]/interface=public:read-resource(include-runtime=true)
Copy to Clipboard Toggle word wrap
以前の例と比較すると、include-runtime 要求プロパティーを含めると、HTTP コネクターによって送受信されたバイトなどの追加のアクティブな属性が公開されます。

例3.19 include-runtime パラメーターを使用して追加のアクティブな値を公開

[standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource(include-runtime=true)
{
    "outcome" => "success",
    "result" => {
        "any" => undefined,
        "any-address" => undefined,
        "any-ipv4-address" => undefined,
        "any-ipv6-address" => undefined,
        "inet-address" => expression "${jboss.bind.address:127.0.0.1}",
        "link-local-address" => undefined,
        "loopback" => undefined,
        "loopback-address" => undefined,
        "multicast" => undefined,
        "name" => "public",
        "nic" => undefined,
        "nic-match" => undefined,
        "not" => undefined,
        "point-to-point" => undefined,
        "public-address" => undefined,
        "resolved-address" => "127.0.0.1",
        "site-local-address" => undefined,
        "subnet-match" => undefined,
        "up" => undefined,
        "virtual" => undefined
    }
}
Copy to Clipboard Toggle word wrap

3.5.7. 管理 CLI を使用した利用可能なリソース説明の表示

管理 CLI でのコマンドの実行

read-resource-description 操作を実行します。

管理 CLI から read-resource-description 操作を使用して、利用可能なリソースを読み取りおよび表示します。操作リクエストの詳細は、「管理 CLI での操作およびコマンドの使用」 のトピックを参照してください。

[standalone@localhost:9999 /]:read-resource-description
Copy to Clipboard Toggle word wrap

オプションパラメーターの使用

read-resource-description 操作では、追加のパラメーターを使用できます。

  • operations パラメーターを使用して、リソースの操作の説明を追加します。
    [standalone@localhost:9999 /]:read-resource-description(operations=true)
    Copy to Clipboard Toggle word wrap
  • 継承された パラメーターを使用して、リソースの継承された操作の説明を追加または除外します。デフォルトの状態は true です。
    [standalone@localhost:9999 /]:read-resource-description(inherited=false)
    Copy to Clipboard Toggle word wrap
  • recursive パラメーターを使用して、子リソースの再帰的な記述を追加します。
    [standalone@localhost:9999 /]:read-resource-description(recursive=true)
    Copy to Clipboard Toggle word wrap
  • locale パラメーターを使用して、リソースの説明を取得します。null の場合、デフォルトのロケールが使用されます。
    [standalone@localhost:9999 /]:read-resource-description(locale=true)
    Copy to Clipboard Toggle word wrap
  • access-control パラメーターを使用して、このリソースの現在の呼び出し元が持つパーミッションに関する情報を取得します。
    [standalone@localhost:9999 /]:read-resource-description(access-control=none)
    Copy to Clipboard Toggle word wrap

結果

利用可能なリソースの説明が表示されます。

3.5.8. 管理 CLI を使用したアプリケーションサーバーのリロード

管理 CLI で reload 操作を使用してすべてのサービスをシャットダウンし、JBoss EAP インスタンスを再起動します。JVM 自体は再起動されないことに注意してください。リロード が完了すると、管理 CLI は自動的に再接続します。
操作リクエストの詳細は、「管理 CLI での操作およびコマンドの使用」 を参照してください。

例3.20 アプリケーションのリロード

[standalone@localhost:9999 /]reload
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap

3.5.9. 管理 CLI を使用したアプリケーションサーバーのシャットダウン

手順3.17 アプリケーションサーバーのシャットダウン

  • シャットダウン 操作の実行

    • 管理 CLI で シャットダウン 操作を使用し、System.exit(0) システムコールを介してサーバーをシャットダウンします。操作リクエストの詳細は、「管理 CLI での操作およびコマンドの使用」 のトピックを参照してください。
      • スタンドアロンモードでは、次のコマンドを使用します。
        [standalone@localhost:9999 /]shutdown
        Copy to Clipboard Toggle word wrap
      • ドメインモードでは、適切なホスト名を指定して次のコマンドを使用します。
        [domain@localhost:9999 /]shutdown --host=master
        Copy to Clipboard Toggle word wrap
    • デタッチした CLI インスタンスへ接続し、サーバーをシャットダウンするには、次のコマンドを実行します。
      jboss-cli.sh --connect command=shutdown
      
      Copy to Clipboard Toggle word wrap
    • リモート CLI インスタンスへ接続し、サーバーをシャットダウンするには、次のコマンドを実行します。
      [disconnected /] connect IP_ADDRESS
      [standalone@IP_ADDRESS:9999 /] shutdown
      
      Copy to Clipboard Toggle word wrap
      IP_ADDRESS はインスタンスの IP アドレスに置き換えます。
注記
shutdown コマンドに --restart=true 引数を追加すると(以下に示されるように)、サーバーを再起動するよう要求されます。
[standalone@localhost:9999 /]shutdown --restart=true
Copy to Clipboard Toggle word wrap

結果

アプリケーションサーバーがシャットダウンしている。ランタイムが利用できないため、管理 CLI は切断されます。

3.5.10. 管理 CLI での属性の設定

概要

write-attribute 操作は、選択したリソース属性の書き込みまたは変更に使用されるグローバル操作です。操作を使用して永続的な変更を行い、管理対象サーバーインスタンスの設定を変更できます。要求プロパティーには、以下のパラメーターが含まれます。

要求プロパティー

名前
選択されたリソース下で値を設定する属性の名前。
選択したリソース下の属性の必要な値。基礎となるモデルが null 値をサポートする場合は null にすることができます。

手順3.18 管理 CLI でのリソース属性の設定

  • write-attribute 操作の実行

    管理 CLI で write-attribute 操作を使用してリソース属性の値を変更します。操作は、リソースの子ノードまたは完全なリソースパスが指定された管理 CLI のルートノードで実行できます。

例3.21 write-attribute 操作を使用したデプロイメントスキャナーの無効化

以下の例は、write-attribute 操作を使用してデプロイメントスキャナーを無効にします。タブ補完を使用して正しいリソースパスの設定を支援することにより、操作はルートノードから実行されます。
[standalone@localhost:9999 /] /subsystem=deployment-scanner/scanner=default:write-attribute(name=scan-enabled,value=false)
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
操作の結果は、read-attribute 操作を直接使用して確認できます。
[standalone@localhost:9999 /] /subsystem=deployment-scanner/scanner=default:read-attribute(name=scan-enabled)
{
    "outcome" => "success",
    "result" => false
}
Copy to Clipboard Toggle word wrap
結果は、read-resource 操作ですべてのノードで利用可能なリソース属性を一覧表示することによって確認することもできます。以下の例では、この特定の設定は scan-enabled 属性が false に設定されていることを示しています。
[standalone@localhost:9999 /] /subsystem=deployment-scanner/scanner=default:read-resource                                 
{
    "outcome" => "success",
    "result" => {
        "auto-deploy-exploded" => false,
        "auto-deploy-xml" => true,
        "auto-deploy-zipped" => true,
        "deployment-timeout" => 600,
        "path" => "deployments",
        "relative-to" => "jboss.server.base.dir",
        "scan-enabled" => false,
        "scan-interval" => 5000
    }
}
Copy to Clipboard Toggle word wrap

結果

リソース属性が更新されます。

3.5.11. 管理 CLI を使用したシステムプロパティーの設定

手順3.19 管理 CLI を使用したシステムプロパティーの設定

  1. JBoss EAP サーバーを起動します。
  2. ご使用のオペレーティングシステム向けのコマンドを使用して、管理 CLI を起動します。
    Linux の場合
    EAP_HOME/bin/jboss-cli.sh --connect
    Copy to Clipboard Toggle word wrap
    Windows の場合:
    EAP_HOME\bin\jboss-cli.bat --connect
    Copy to Clipboard Toggle word wrap
  3. システムプロパティーを追加します。
    使用するコマンドは、スタンドアロンサーバーと管理対象ドメインのどちらを実行しているかによって異なります。管理対象ドメインを実行している場合は、そのドメインで実行しているすべてのサーバーへシステムプロパティーを追加できます。
    • 以下の構文を使用して、スタンドアロンサーバーにシステムプロパティーを追加します。
      /system-property=PROPERTY_NAME:add(value=PROPERTY_VALUE)
      Copy to Clipboard Toggle word wrap

      例3.22 システムプロパティーをスタンドアロンサーバーへ追加

      [standalone@localhost:9999 /] /system-property=property.mybean.queue:add(value=java:/queue/MyBeanQueue)
      {"outcome" => "success"}
      Copy to Clipboard Toggle word wrap
    • 以下の構文を使用して、管理対象ドメインのすべてのホストおよびサーバーにシステムプロパティーを追加します。
      /system-property=PROPERTY_NAME:add(value=PROPERTY_VALUE)
      Copy to Clipboard Toggle word wrap

      例3.23 管理対象ドメインのすべてのサーバーへシステムプロパティーを追加

      [domain@localhost:9999 /] /system-property=property.mybean.queue:add(value=java:/queue/MyBeanQueue)
      {
          "outcome" => "success",
          "result" => undefined,
          "server-groups" => {"main-server-group" => {"host" => {"master" => {
              "server-one" => {"response" => {"outcome" => "success"}},
              "server-two" => {"response" => {"outcome" => "success"}}
          }}}}
      }
      Copy to Clipboard Toggle word wrap
    • 以下の構文を使用して、管理対象ドメインのホストおよびそのサーバーインスタンスにシステムプロパティーを追加します。
      /host=master/system-property=PROPERTY_NAME:add(value=PROPERTY_VALUE)
      Copy to Clipboard Toggle word wrap

      例3.24 システムプロパティーをドメインのホストおよびそのサーバーへ追加

      [domain@localhost:9999 /] /host=master/system-property=property.mybean.queue:add(value=java:/queue/MyBeanQueue)
      {
          "outcome" => "success",
          "result" => undefined,
          "server-groups" => {"main-server-group" => {"host" => {"master" => {
              "server-one" => {"response" => {"outcome" => "success"}},
              "server-two" => {"response" => {"outcome" => "success"}}
          }}}}
      }
      Copy to Clipboard Toggle word wrap
    • 以下の構文を使用して、管理対象ドメインのサーバーインスタンスにシステムプロパティーを追加します。
      /host=master/server-config=server-one/system-property=PROPERTY_NAME:add(value=PROPERTY_VALUE)
      Copy to Clipboard Toggle word wrap

      例3.25 システムプロパティーを管理対象ドメインのサーバーインスタンスへ追加

      [domain@localhost:9999 /] /host=master/server-config=server-one/system-property=property.mybean.queue:add(value=java:/queue/MyBeanQueue)
      {
          "outcome" => "success",
          "result" => undefined,
          "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {"outcome" => "success"}}}}}}
      }
      
      Copy to Clipboard Toggle word wrap
  4. システムプロパティーを読み取ります。
    使用するコマンドは、スタンドアロンサーバーと管理対象ドメインのどちらを実行しているかによって異なります。
    • 以下の構文を使用して、スタンドアロンサーバーからシステムプロパティーを読み取ります。
      /system-property=PROPERTY_NAME:read-resource
      Copy to Clipboard Toggle word wrap

      例3.26 スタンドアロンサーバーからシステムプロパティーの読み取り

      [standalone@localhost:9999 /] /system-property=property.mybean.queue:read-resource
      {
          "outcome" => "success",
          "result" => {"value" => "java:/queue/MyBeanQueue"}
      }
      
      Copy to Clipboard Toggle word wrap
    • 以下の構文を使用して、管理対象ドメインのすべてのホストおよびサーバーからシステムプロパティーを読み取ります。
      /system-property=PROPERTY_NAME:read-resource
      Copy to Clipboard Toggle word wrap

      例3.27 管理対象ドメインのすべてのサーバーからシステムプロパティーを読み取り

      [domain@localhost:9999 /] /system-property=property.mybean.queue:read-resource
      {
          "outcome" => "success",
          "result" => {
              "boot-time" => true,
              "value" => "java:/queue/MyBeanQueue"
          }
      }
      Copy to Clipboard Toggle word wrap
    • 以下の構文を使用して、管理対象ドメインのホストおよびそのサーバーインスタンスからシステムプロパティーを読み取ります。
      /host=master/system-property=PROPERTY_NAME:read-resource
      Copy to Clipboard Toggle word wrap

      例3.28 ドメインのホストおよびそのサーバーからシステムプロパティーを読み取り

      [domain@localhost:9999 /] /host=master/system-property=property.mybean.queue:read-resource
      {
          "outcome" => "success",
          "result" => {
              "boot-time" => true,
              "value" => "java:/queue/MyBeanQueue"
          }
      }
      
      Copy to Clipboard Toggle word wrap
    • 以下の構文を使用して、管理対象ドメインのサーバーインスタンスからシステムプロパティーを読み取ります。
      /host=master/server-config=server-one/system-property=PROPERTY_NAME:read-resource
      Copy to Clipboard Toggle word wrap

      例3.29 管理対象ドメインのサーバーインスタンスからシステムプロパティーを読み取り

      [domain@localhost:9999 /] /host=master/server-config=server-one/system-property=property.mybean.queue:read-resource
      {
          "outcome" => "success",
          "result" => {
              "boot-time" => true,
              "value" => "java:/queue/MyBeanQueue"
          }
      }
      Copy to Clipboard Toggle word wrap
  5. システムプロパティーを削除します。
    使用するコマンドは、スタンドアロンサーバーと管理対象ドメインのどちらを実行しているかによって異なります。
    • 以下の構文を使用して、スタンドアロンサーバーからシステムプロパティーを削除します。
      /system-property=PROPERTY_NAME:remove
      Copy to Clipboard Toggle word wrap

      例3.30 スタンドアロンサーバーからシステムプロパティーを削除

      [standalone@localhost:9999 /] /system-property=property.mybean.queue:remove
      {"outcome" => "success"}
      Copy to Clipboard Toggle word wrap
    • 以下の構文を使用して、管理対象ドメインのすべてのホストおよびサーバーからシステムプロパティーを削除します。
      /system-property=PROPERTY_NAME:remove
      Copy to Clipboard Toggle word wrap

      例3.31 ドメインのホストおよびそのサーバーからシステムプロパティーを削除

      [domain@localhost:9999 /] /system-property=property.mybean.queue:remove
      {
          "outcome" => "success",
          "result" => undefined,
          "server-groups" => {"main-server-group" => {"host" => {"master" => {
              "server-one" => {"response" => {"outcome" => "success"}},
              "server-two" => {"response" => {"outcome" => "success"}}
          }}}}
      }
      
      Copy to Clipboard Toggle word wrap
    • 以下の構文を使用して、管理対象ドメインのホストおよびそのサーバーインスタンスからシステムプロパティーを削除します。
      /host=master/system-property=PROPERTY_NAME:remove
      Copy to Clipboard Toggle word wrap

      例3.32 ドメインのホストおよびそのインスタンスからシステムプロパティーを削除

      [domain@localhost:9999 /] /host=master/system-property=property.mybean.queue:remove
      {
          "outcome" => "success",
          "result" => undefined,
          "server-groups" => {"main-server-group" => {"host" => {"master" => {
              "server-one" => {"response" => {"outcome" => "success"}},
              "server-two" => {"response" => {"outcome" => "success"}}
          }}}}
      }
      
      Copy to Clipboard Toggle word wrap
    • 以下の構文を使用して、管理対象ドメインのサーバーインスタンスからシステムプロパティーを削除します。
      /host=master/server-config=server-one/system-property=PROPERTY_NAME:remove
      Copy to Clipboard Toggle word wrap

      例3.33 管理対象ドメインのサーバーからシステムプロパティーを削除

      [domain@localhost:9999 /] /host=master/server-config=server-one/system-property=property.mybean.queue:remove
      {
          "outcome" => "success",
          "result" => undefined,
          "server-groups" => {"main-server-group" => {"host" => {"master" => {"server-one" => {"response" => {"outcome" => "success"}}}}}}
      }
      
      Copy to Clipboard Toggle word wrap
「パスワード」システムプロパティーのマスク
テキストパスワードが含まれるシステムプロパティー(大文字と小文字を区別しない)は、ロギングによる出力時に リダクション されたテキストに置き換えられます。これにより、ログファイルにパスワードをプレーンテキストで出力しないようにするため、セキュリティーが向上します。

3.5.12. 管理 CLI を使用したサーバーの新規作成

以下の例では、ホスト マスター に新しいサーバーを作成し、clustered-server-group に追加します。
[domain@localhost:9999 /] /host=master/server-config=clustered-server-1:add(group=clustered-server-group)
Copy to Clipboard Toggle word wrap

3.6. 管理 CLI コマンド履歴

3.6.1. 管理 CLI コマンド履歴

管理 CLI にはコマンド履歴機能があり、アプリケーションサーバーインストールではデフォルトで有効になっています。履歴は、アクティブな CLI セッションの揮発性メモリーにレコードとして保持され、.jboss-cli-history としてユーザーのホームディレクトリーに自動的に保存されるログファイルに追加されます。この履歴ファイルは、デフォルトで最大 500 の CLI コマンドを記録するように設定されています。
history コマンド自体は現在のセッションの履歴を返します。また、管理 CLI にはキーボードの矢印キーを使用してコマンドおよび操作の履歴を移動できる機能も含まれています。

3.6.2. 管理 CLI コマンド履歴の表示

手順3.20 管理 CLI コマンド履歴の表示

  • history コマンドを実行します。

    管理 CLI で 履歴 コマンドを入力します。
    [standalone@localhost:9999 /] history
    Copy to Clipboard Toggle word wrap

結果

CLI の起動後または履歴削除コマンドの実行後にメモリーに格納された CLI コマンドの履歴が表示されます。

3.6.3. 管理 CLI コマンド履歴の消去

手順3.21 管理 CLI コマンド履歴の消去

  • history --clear コマンドを実行します。

    管理 CLI で 履歴 --clear コマンドを入力します。
    [standalone@localhost:9999 /] history --clear
    Copy to Clipboard Toggle word wrap

結果

CLI の起動後に記録されたコマンドの履歴がセッションメモリーから削除されます。コマンド履歴は、ユーザーのホームディレクトリーに保存されている .jboss-cli-history ファイルに残ります。

3.6.4. 管理 CLI コマンド履歴の無効化

手順3.22 管理 CLI コマンド履歴の無効化

  • history --disable コマンドを実行します。

    管理 CLI で history --disable コマンドを入力します。
    [standalone@localhost:9999 /] history --disable
    Copy to Clipboard Toggle word wrap

結果

CLI で実行されたコマンドは、メモリー内またはユーザーのホームディレクトリーに保存された .jboss-cli-history ファイルに記録されません。

3.6.5. 管理 CLI コマンド履歴の有効化

手順3.23 管理 CLI コマンド履歴の有効化

  • history --enable コマンドを実行します。

    管理 CLI で history --enable コマンドを入力します。
    [standalone@localhost:9999 /] history --enable
    Copy to Clipboard Toggle word wrap

結果

CLI で実行されたコマンドは、メモリーと、ユーザーのホームディレクトリーに保存された .jboss-cli-history ファイルに記録されます。

3.7. 管理インターフェース監査ロギング

3.7.1. 管理インターフェース監査ロギング

監査ロギングを有効にすると、管理コンソール、管理 CLI インターフェース、またはカスタム作成の管理アプリケーションを使用して実行されるすべての操作は監査ロギングの対象となります。
監査ログエントリーは JSON 形式で保存され、設定に基づいて、syslog サーバーまたは両方に送信するファイルに格納できます。監査ロギングは管理 CLI を使用してのみ設定でき、デフォルトでは無効になっています。
EAP には 'authenticated session' がないため、ログインおよびログアウトイベントは監査できません。代わりに、ユーザーから操作を受信すると監査メッセージがログに記録されます。
注記
デフォルトでは、監査ロギングはアクティブではありません。監査ロギングは管理 CLI を使用してのみ設定できます。
利用可能な管理インターフェース監査ロギング設定オプションとその現在の値を一覧表示するには、以下の管理 CLI コマンドを入力します。
注記
管理対象ドメインのコマンドに、プレフィックス /host=HOST_NAME を追加します。
[... /] /core-service=management/access=audit:read-resource(recursive=true)
Copy to Clipboard Toggle word wrap

3.7.2. ファイルへの管理インターフェース監査ロギングの有効化

ファイルへの監査ロギング出力を有効にするには、以下の管理 CLI コマンドを入力します。
注記
管理対象ドメインに変更を適用する場合は、以下のコマンドにプレフィックス /host=HOST_NAME を追加します。
/core-service=management/access=audit/logger=audit-log:write-attribute(name=enabled,value=true)
Copy to Clipboard Toggle word wrap
管理操作がファイルに記録されるようになりました。
  • スタンドアロンモード: EAP_HOME/standalone/data/audit-log.log
  • ドメインモード: EAP_HOME/domain/data/audit-log.log
すべてのファイルハンドラー属性の詳細は、「管理インターフェース監査ロギングリファレンス」 を参照してください。

3.7.3. syslog サーバーへの管理インターフェース監査ロギングの有効化

デフォルトでは、監査ロギングが有効である場合にファイルへ出力するよう事前設定されています。この手順では、syslog サーバーへ出力を設定し、ファイルへの監査ロギングを有効にします。すべての Syslog ハンドラー属性の詳細は、「管理インターフェース監査ロギングリファレンス」 を参照してください。
注記
管理対象ドメインに変更を適用する場合は、プレフィックス /host=HOST_NAME/core-service コマンドに追加します。

手順3.24 Syslog サーバーへの監査ロギングの有効化

  1. 監査ロギングの有効化

    以下のコマンドを実行します。
    [.. /]/core-service=management/access=audit/logger=audit-log:write-attribute(name=enabled,value=true)
    Copy to Clipboard Toggle word wrap
  2. syslog ハンドラーの作成

    この例では、syslog サーバーが JBoss EAP インスタンスと同じサーバーで、ポート 514 で実行します。ホスト 属性の値を、実際の環境に適した値に置き換えます。

    例3.34 syslog ハンドラーの例

    [.. /]batch
    [.. / #]/core-service=management/access=audit/syslog-handler=mysyslog:add(formatter=json-formatter)
    [.. / #]/core-service=management/access=audit/syslog-handler=mysyslog/protocol=udp:add(host=localhost,port=514)
    [.. /]run-batch
    Copy to Clipboard Toggle word wrap
  3. syslog ハンドラーへの参照の追加

    以下のコマンドを実行します。
    [.. /]/core-service=management/access=audit/logger=audit-log/handler=mysyslog:add
    Copy to Clipboard Toggle word wrap

結果

管理インターフェースの監査ログエントリーが syslog サーバーに記録されます。

注記
オペレーティングシステムでロギングが有効になっていない限り、JBoss EAP の Syslog サーバーへの監査ロギングを有効にしても動作しません。
Red Hat Enterprise Linux の rsyslog 設定に関する詳細は、Red Hat Enterprise Linux の『 システム管理者 のガイド』の「rsyslog の 基本設定」 セクションを参照してください。 https://access.redhat.com/documentation/ja-JP/Red_Hat_Enterprise_Linux/

3.7.4. 管理インターフェース監査ロギングの無効化

ファイルまたは syslog サーバーへの監査ロギングは、以下のコマンドを実行して無効にできます。
/core-service=management/access=audit/logger=audit-log:write-attribute(name=enabled,value=false)
Copy to Clipboard Toggle word wrap

3.7.5. 管理インターフェース監査ログの読み取り

ファイルに出力される監査ログエントリーは、テキスト ビューアー で参照するのが最適ですが、syslog サーバーへ出力される監査ログエントリーは syslog ビューアーアプリケーションを使用して参照するのが最適です。
注記
ログファイルの参照にテキストエディターを使用することは推奨されません。 これは、追加のログエントリーがログファイルに書き込まれなくなることがあるためです。
管理インターフェース監査ログは JSON 形式で出力されます。各ログエントリーは任意のタイムスタンプで始まり、『管理インターフェースの監査ログフィールド の表に記載されている』 フィールドです。
Expand
表3.5 管理インターフェース監査ログフィールド
フィールド名 説明
type 管理操作であることを示す core または jmx は JMX サブシステムからの意味を持つことができます(JMX サブシステムの監査ロギングの設定については JMX サブシステムを参照してください)。
r/o 操作によって管理モデルが変更されない場合は、値が true になります。そうでない場合は false になります。
起動 起動プロセス中に操作が実行された場合は、値が true になります。サーバーの起動後に操作が実行された場合は false になります。
version JBoss EAP インスタンスのバージョン番号。
user 認証されたユーザーのユーザー名。実行中のサーバーと同じマシンの管理 CLI で操作を行う場合は、特別な $local ユーザーが使用されます。
domainUUID ドメインコントローラーからサーバー、スレーブホストコントローラー、およびスレーブホストコントローラーサーバーへ伝播されるすべての操作をリンクする ID。
access 以下のいずれかの値を使用できます。
  • NATIVE - 操作が管理 CLI などのネイティブ管理インターフェースから実行されます。
  • HTTP - 操作が管理コンソールなどのドメイン HTTP インターフェースから実行されます。
  • JMX - 操作が JMX サブシステムから実行されます。JMX の監査ロギングの設定方法は JMX を参照してください。
remote-address この操作を実行するクライアントのアドレス。
success 操作に成功した場合は値が true になります。ロールバックされた場合は false になります。
ops 実行される操作。JSON へシリアライズ化された操作のリストになります。起動時は、XML の解析で生じた演算です。通常、一覧を起動するとエントリーが 1 つ含まれます。

第4章 ユーザー管理

4.1. JBoss EAP ユーザー管理

JBoss EAP 6 のインストール方法によっては、管理インターフェースにアクセスできるユーザーアカウントが初期設定できない場合があります。
グラフィカルインストーラーを使用してプラットフォームをインストールする場合は、インストール時に JBoss EAP 6 管理インターフェースにアクセスするために必要な権限を持つユーザーアカウント 1 つのみが作成されます。
ZIP アーカイブを使用してプラットフォームを手動でインストールした場合には、インストール時に適切な権限を持つユーザーアカウントが作成されません。
コンソールで JAR インストーラーを使用してプラットフォームを手動でインストールする場合は、インストール時に適切な権限を持つユーザーアカウントを 1 つ作成します。
トラフィックの送信元がローカルホストであっても、JBoss EAP 6 との HTTP ベースの通信はリモートアクセスと見なされます。したがって、管理コンソールを使用するには、少なくとも 1 人の管理ユーザーを作成する必要があります。ユーザーを追加する前に管理コンソールにアクセスしようとすると、ユーザーが追加されるまでデプロイされないのでエラーが発生します。
本ガイドでは、add-user.sh スクリプトを使用して JBoss EAP 6 の簡単なユーザー管理について説明します。LDAP やロールベースアクセス制御(RBAC)などの高度な認証および承認オプションは、JBoss EAP『 『セキュリティーアーキテクチャー』 』の「 『コア管理認証』 」を参照してください。

4.2. ユーザーの作成

4.2.1. 管理インターフェースのユーザーの追加

以下の手順では、選択したインストール方法でユーザーが作成されていない場合に、最初の管理ユーザーを作成する方法を説明します。この初期管理ユーザーは、Web ベースの管理コンソールおよび管理 CLI のリモートインスタンスを使用して、リモートシステムから JBoss EAP 6 を設定および管理できます。

手順4.1 リモート管理インターフェース用の最初の管理ユーザーを作成

  1. add-user.sh または add-user.bat スクリプトを実行します。

    EAP_HOME/bin/ ディレクトリーに移動します。オペレーティングシステムに適したスクリプトを実行します。
    Red Hat Enterprise Linux
    [user@host bin]$ ./add-user.sh
    Copy to Clipboard Toggle word wrap
    Microsoft Windows Server
    C:\bin>  add-user.bat
    Copy to Clipboard Toggle word wrap
  2. 管理ユーザーの追加を選択します。

    ENTER を押して、デフォルトのオプション a を選択し、管理ユーザーを追加します。
    このユーザーは ManagementRealm に追加され、Web ベースの管理コンソールまたはコマンドラインベースの管理 CLI を使用して管理操作を実行することが承認されます。もう 1 つの選択肢は b で、ユーザーを ApplicationRealm に追加し、特定のパーミッションは提供されません。そのレルムはアプリケーションで使用するために提供されます。
  3. ユーザー名とパスワードを入力します。

    プロンプトが表示されたら、ユーザー名とパスワードを入力します。入力後、パスワードを確認するよう指示されます。
  4. グループ情報を入力します。

    ユーザーが属するグループを追加します。ユーザーが複数のグループに属する場合は、コンマ区切りリストを入力します。ユーザーがグループに属さない場合は空白のままにします。
  5. 情報を確認します。

    情報を確認するよう求められます。問題がなければ、yes を入力します。
  6. ユーザーがリモート JBoss EAP 6 サーバーインスタンスを表すかどうかを選択します。

    管理者以外に、ManagementRealm の JBoss EAP 6 の別のインスタンスを表すユーザーである で JBoss EAP 6 に追加する必要がある他のタイプのユーザーは、メンバーとしてクラスターに参加することを認証できる必要があります。次のプロンプトでは、この目的のために追加したユーザーを指定できます。yes を選択すると、ユーザーのパスワードを表すハッシュ化された secret 値が表示されます。これは別の設定ファイルに追加する必要があります。このタスクの目的上、この質問には no と回答します。
  7. 追加ユーザーを入力します。

    必要な場合は、この手順を繰り返すと追加のユーザーを入力できます。実行中のシステムのいつでも追加することもできます。デフォルトのセキュリティーレルムを選択する代わりに、他のレルムにユーザーを追加すると、承認を微調整できます。
  8. 非対話的にユーザーを作成します。

    コマンドラインで各パラメーターを渡すと、非対話的にユーザーを作成できます。ログや履歴ファイルにパスワードが表示されるため、この方法は共有システムでは推奨されません。管理レルムを使用したコマンドの構文は次のとおりです。
    [user@host bin]$ ./add-user.sh username password
    Copy to Clipboard Toggle word wrap
    アプリケーションレルムを使用するには、-a パラメーターを使用します。
    [user@host bin]$ ./add-user.sh -a username password
    Copy to Clipboard Toggle word wrap
  9. --silent パラメーターを渡すと、add-user スクリプトの通常の出力は抑制できます。これは、最小限のパラメーターの username および password が指定されている場合にのみ該当します。エラーメッセージが表示されます。

結果

追加したユーザーは、指定したセキュリティーレルム内でアクティベートされます。ManagementRealm レルム内でアクティブなユーザーは、リモートシステムから JBoss EAP 6 を管理できます。

4.2.2. ユーザー管理の add-user スクリプトへ引数を渡す

add-user.sh または add-user.bat コマンドを対話的に実行することも、コマンドラインで引数を渡すこともできます。本セクションでは、コマンドライン引数を add-user スクリプトに渡す際に利用可能なオプションを説明します。
add-user.sh または add-user.bat コマンドで使用できるコマンドライン引数の一覧は、「add-user コマンド引数」 を参照してください。
代替のプロパティーファイルおよび場所を指定する方法は、「ユーザー管理情報の代替プロパティーファイルの指定」 を参照してください。

4.2.3. add-user コマンド引数

以下の表は、add-user.sh または add-user.bat コマンドで使用できる引数を示しています。
Expand
表4.1 add-user コマンド引数
コマンドライン引数 引数の値 説明
-a
該当なし
この引数は、アプリケーションレルムでユーザーを作成するように指定します。省略した場合、デフォルトでは管理レルムでユーザーが作成されます。
-dc
DOMAIN_CONFIGURATION_DIRECTORY
この引数は、プロパティーファイルが含まれるドメイン設定ディレクトリーを指定します。省略した場合、デフォルトのディレクトリーは EAP_HOME/domain/configuration/ になります。
-sc
SERVER_CONFIGURATION_DIRECTORY
この引数は、プロパティーファイルが含まれる代替のスタンドアロンサーバー設定ディレクトリーを指定します。省略した場合、デフォルトのディレクトリーは EAP_HOME/standalone/configuration/ になります。
-up
--user-properties
USER_PROPERTIES_FILE
この引数は、代替のユーザープロパティーファイルの名前を指定します。絶対パスを使用でき、代替の設定ディレクトリーを指定する -sc または -dc 引数と共に使用されるファイル名を使用することもできます。
-g
--group
GROUP_LIST
このユーザーに割り当てるグループのコンマ区切りリスト。
-gp
--group-properties
GROUP_PROPERTIES_FILE
この引数は、代替のグループプロパティーファイルの名前を指定します。絶対パスを使用でき、代替の設定ディレクトリーを指定する -sc または -dc 引数と共に使用されるファイル名を使用することもできます。
-p
--password
PASSWORD
ユーザーのパスワード。パスワードは以下の要件を満たす必要があります。
  • 8 文字以上でなければなりません。
  • 1 文字以上のアルファベットが含まれなくてはなりません。
  • 1 文字以上の数字が含まれなければなりません。
  • 英数字以外の記号が 1 つ以上含まれなければなりません。
-u
--user
USER_NAME
ユーザーの名前。英数字と以下のシンボルのみを使用できます: ,./=@\.
-r
--realm
REALM_NAME
管理インターフェースをセキュアにするために使用されるレルムの名前。省略した場合、デフォルト値は ManagementRealm です。
-s
--silent
該当なし
コンソールへ出力せずに add-user スクリプトを実行します。
-h
--help
該当なし
add-user スクリプトの使用情報を表示します。

4.2.4. ユーザー管理情報の代替プロパティーファイルの指定

概要

デフォルトでは、add-user.sh または add-user.bat スクリプトを使用して作成されたユーザーおよびロール情報は、サーバー設定ディレクトリーにあるプロパティーファイルに保存されます。サーバー設定情報は EAP_HOME/standalone/configuration/ ディレクトリーに保存され、ドメイン設定情報は EAP_HOME/domain/configuration/ ディレクトリーに保存されます。このトピックでは、デフォルトのファイル名および場所を上書きする方法について説明します。

代替プロパティーファイルの指定

  • サーバー設定の代替ディレクトリーを指定するには、-sc 引数を使用します。この引数は、サーバー設定プロパティーファイルが含まれる代替のディレクトリーを指定します。
  • ドメイン設定の代替ディレクトリーを指定するには、-dc 引数を使用します。この引数は、ドメイン設定プロパティーファイルを含む代替ディレクトリーを指定します。
  • 代替のユーザー設定プロパティーファイルを指定するには、-up 引数または --user-properties 引数を使用します。絶対パスを使用でき、代替の設定ディレクトリーを指定する -sc または -dc 引数と共に使用されるファイル名を使用することもできます。
  • 代替のグループ設定プロパティーファイルを指定するには、-gp 引数または --group-properties 引数を使用します。絶対パスを使用でき、代替の設定ディレクトリーを指定する -sc または -dc 引数と共に使用されるファイル名を使用することもできます。
注記
add-user コマンドは、既存のプロパティーファイルでの操作を行うことを目的としています。コマンドライン引数に指定された代替のプロパティーファイルが存在しない場合は、以下のエラーが表示されます。
JBAS015234: No appusers.properties files found
Copy to Clipboard Toggle word wrap
コマンド引数の詳細は、「add-user コマンド引数」 を参照してください。

4.3. add-user スクリプトのコマンドラインの例

例4.1 単一グループに属するユーザーの作成

EAP_HOME/bin/add-user.sh -a -u 'appuser1' -p 'password1!' -g 'guest'
Copy to Clipboard Toggle word wrap
この例では、以下の結果を表示しています。
  • ユーザー appuser1 は、ユーザー情報が保存される以下のデフォルトプロパティーファイルに追加されます。
    EAP_HOME/standalone/configuration/application-users.properties
    EAP_HOME/domain/configuration/application-users.properties
  • グループ guest を持つユーザー appuser1 が、グループ情報を格納するデフォルトのプロパティーファイルに追加されます。
    EAP_HOME/standalone/configuration/application-roles.properties
    EAP_HOME/domain/configuration/application-roles.properties

4.3.2. デフォルトのプロパティーファイルを使用した複数のグループへのユーザーの作成

例4.2 複数のグループに属するユーザーの作成

EAP_HOME/bin/add-user.sh -a -u 'appuser1' -p 'password1!' -g 'guest,app1group,app2group'
Copy to Clipboard Toggle word wrap
この例では、以下の結果を表示しています。
  • ユーザー appuser1 は、ユーザー情報が保存される以下のデフォルトプロパティーファイルに追加されます。
    EAP_HOME/standalone/configuration/application-users.properties
    EAP_HOME/domain/configuration/application-users.properties
  • グループ guestapp1group、および app2group を持つユーザー appuser1 が、グループ情報を格納するデフォルトのプロパティーファイルに追加されます。
    EAP_HOME/standalone/configuration/application-roles.properties
    EAP_HOME/domain/configuration/application-roles.properties

例4.3 デフォルトレルムで管理者権限を持つユーザーの作成

EAP_HOME/bin/add-user.sh -u 'adminuser1' -p 'password1!' -g 'admin'
Copy to Clipboard Toggle word wrap
この例では、以下の結果を表示しています。
  • ユーザー adminuser1 は、ユーザー情報が保存される以下のデフォルトプロパティーファイルに追加されます。
    EAP_HOME/standalone/configuration/mgmt-users.properties
    EAP_HOME/domain/configuration/mgmt-users.properties
  • グループ admin のユーザー adminuser1 は、グループ情報を格納するデフォルトのプロパティーファイルに追加されます。
    EAP_HOME/standalone/configuration/mgmt-groups.properties
    EAP_HOME/domain/configuration/mgmt-groups.properties

例4.4 代替のプロパティーファイルを使用した単一グループに属するユーザーの作成

EAP_HOME/bin/add-user.sh -a -u appuser1 -p password1! -g app1group -sc /home/someusername/userconfigs/ -up appusers.properties -gp appgroups.properties 
Copy to Clipboard Toggle word wrap
この例では、以下の結果を表示しています。
  • ユーザー appuser1 は以下のプロパティーファイルに追加され、このファイルがユーザー情報を保存するデフォルトファイルになります。
    /home/someusername/userconfigs/appusers.properties
  • app1group グループを持つユーザー appuser1 が以下のプロパティーファイルに追加され、このファイルがグループ情報を保存するデフォルトファイルになりました。
    /home/someusername/userconfigs/appgroups.properties

第5章 ネットワークおよびポート設定

5.1. インターフェース

5.1.1. インターフェース

JBoss EAP は設定全体で名前付きインターフェース参照を使用します。これにより、使用ごとにインターフェースの完全な詳細を必要とせずに、論理名で個々のインターフェース宣言を参照する機能が提供されます。
論理名を使用すると、名前付きインターフェースへのグループ参照の整合性も可能にします。この場合、管理対象ドメインのサーバーインスタンスには複数のマシン間でさまざまなインターフェースの詳細が含まれる可能性があります。論理名では、各サーバーインスタンスが論理名グループに対応しているため、インターフェースグループの管理が容易になります。
ネットワークインターフェースは、物理インターフェースの論理名と選択基準を指定して宣言されます。
JBoss EAP のデフォルト設定には、管理 インターフェースと パブリック インターフェース名の両方が含まれます。管理 インターフェース名は、管理レイヤーを必要とするすべてのコンポーネントおよびサービス(HTTP 管理エンドポイントを含む)に使用できます。public インターフェース名は、Web や Messaging などのアプリケーション関連のネットワーク通信すべてに使用できます。
デフォルト名の使用は必須ではありません。新しい論理名を作成し、デフォルト名に置き換えることができます。
domain.xmlhost.xml、および standalone.xml 設定ファイルには、インターフェース宣言が含まれます。宣言基準はワイルドカードアドレスを参照したり、有効な一致となるためにインターフェースまたはアドレスで必要となる 1 つ以上の特性のセットを指定したりできます。
3 つの設定ファイルは直接編集可能ですが、手動編集は不要になりました。管理 CLI および管理コンソールは、設定の変更にセキュアで制御された永続的な環境を提供します。
以下の例は、通常は standalone.xml または host.xml 設定ファイルのいずれかで定義されるインターフェース宣言の複数の設定を示しています。これらのファイルを使用すると、リモートホストグループが特定のインターフェース属性を維持でき、引き続きドメインコントローラーインターフェースへの参照が許可されます。
以下の例は、管理およびパブリックの相対名グループに指定された特定の inet-address 値を示しています。

例5.1 inet-address 値で作成されたインターフェースグループ

<interfaces>
  <interface name="management">
   <inet-address value="127.0.0.1"/>
  </interface>
  <interface name="public">
   <inet-address value="127.0.0.1"/>
  </interface>
</interfaces>
Copy to Clipboard Toggle word wrap
以下の例は、グローバルインターフェースグループを示しています。any-address 要素を使用してワイルドカードアドレスを宣言します。

例5.2 ワイルドカード宣言で作成されたグローバルグループ

<interface name="global">
   <!-- Use the wild-card address -->
   <any-address/>
</interface>
Copy to Clipboard Toggle word wrap
以下の例では、external という相対グループの下でネットワークインターフェースカード(eth0)を宣言します。

例5.3 NIC 値で作成された外部グループ

<interface name="external">
   <nic name="eth0"/>
</interface>
Copy to Clipboard Toggle word wrap
以下の例では、要件のあるデフォルトグループを宣言します。これらの要件は、インターフェースの条件を有効な一致に設定します。これは、JBoss EAP がインターフェースの名前を使用して参照できる特定のプロパティーを持つインターフェース宣言グループの作成を許可する方法の例になります。これは、複数のサーバーインスタンスにおける設定の複雑さおよび管理オーバーヘッドを軽減するのに役立ちます。

例5.4 特定の条件値で作成されたデフォルトグループ

<interface name="default">
   <!-- Match any interface/address on the right subnet if it's
        up, supports multicast, and isn't point-to-point -->
   <subnet-match value="192.168.0.0/16"/>
   <up/>
   <multicast/>
   <not>
      <point-to-point/>
   </not>
</interface>
Copy to Clipboard Toggle word wrap

5.1.2. インターフェースの設定

standalone.xml および host.xml 設定ファイルのデフォルトのインターフェース設定は、それぞれ相対的なインターフェーストークンを持つ 3 つの名前付きインターフェースを提供します。以下の表にあるように、管理コンソールまたは管理 CLI を使用して追加の属性および値を設定します。必要に応じて、相対インターフェースバインディングは特定の値に置き換えることができますが、これを行う場合は、-b スイッチが相対値しか上書きできないため、サーバー実行時にインターフェース値を渡すことができないことに注意してください。

例5.5 デフォルトインターフェース設定

<interfaces>
  <interface name="management">
    <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
  </interface>
  <interface name="public">
    <inet-address value="${jboss.bind.address:127.0.0.1}"/>
  </interface>
  <interface name="unsecure">
    <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/>
  </interface>
</interfaces>
Copy to Clipboard Toggle word wrap
管理対象ドメインで複数のサーバーを実行している間、インターフェースバインディングはそれぞれの host.xml ファイルの個別のサーバーに割り当てることができます。以下に例を示します。
<servers>
  <server name="server-name" group="main-server-group">
    <interfaces>
      <interface name="public">
        <inet-address value="ip-address"/>
      </interface>
    </interfaces>
  </server>
</servers>
Copy to Clipboard Toggle word wrap
注記
上記の例では、server-name を実際のサーバー名に置き換え、ip-address を実際の IP アドレスに置き換えます。
Expand
表5.1 インターフェース属性と値
インターフェース要素 説明
any インターフェースの選択基準の一部は、最低でも基準のネストされたセットの 1 つ (すべてとは限らない) を満たす必要があることを示す要素。
any-address
このインターフェースを使用するソケットをワイルドカードアドレスにバインドする必要があることを示す空の要素。
java.net.preferIpV4Stack システムプロパティーが true に設定されていない限り、IPv6 ワイルドカードアドレス(::)が使用されます。true に設定すると、IPv4 ワイルドカードアドレス(0.0.0.0)が使用されます。
ソケットがデュアルスタックマシンの IPv6 anylocal アドレスにバインドされた場合は、IPv6 および IPv4 トラフィックを受け入れることができます。 IPv4 (IPv4 マッピング) anylocal アドレスにバインドされた場合は、IPv4 トラフィックのみを受け入れることができます。
any-ipv4-address このインターフェースを使用するソケットを IPv4 ワイルドカードアドレス (0.0.0.0) にバインドする必要があることを示す空の要素。
any-ipv6-address このインターフェースを使用するソケットを IPv6 ワイルドカードアドレス (::) にバインドする必要があることを示す空の要素。
inet-address IPv6 または IPv4 のドット区切り表記の IP アドレス、または IP アドレスに解決できるホスト名。
link-local-address インターフェースの選択基準の一部として、関連付けられたアドレスがリンクローカルであるかどうかを示す空の要素。
loopback インターフェースの選択基準の一部として、ループバックインターフェースであるかどうかを示す空の要素。
loopback-address マシンのループバックインターフェースで実際には設定できないループバックアドレス。IP アドレスが関連付けられた NIC が見つからない場合であっても該当する値が使用されるため、inet-address タイプとは異なります。
multicast インターフェースの選択基準の一部として、マルチキャストをサポートするかどうかを示す空の要素。
nic ネットワークインターフェースの名前 (eth0、eth1、lo など)。
nic-match 使用できるインターフェースを見つけるために、マシンで利用可能なネットワークインターフェースの名前を検索する正規表現。
not インターフェースの選択基準の一部は、基準のネストされたセットを満たしてはならないことを示す要素。
point-to-point インターフェースの選択基準の一部として、ポイントツーポイントインターフェースであるかどうかを示す空の要素。
public-address インターフェースの選択基準の一部として、公開されたルーティング可能なアドレスを持つかどうかを示す空の要素。
site-local-address インターフェースの選択基準の一部として、関連付けられたアドレスがサイトローカルであるかどうかを示す空の要素。
subnet-match 「スラッシュ表記法」で記述されたネットワーク IP アドレスとアドレスのネットワーク接頭辞のビット数(例:"192.168.0.0/16".
up インターフェースの選択基準の一部として、現在稼動しているかどうかを示す空の要素。
virtual インターフェースの選択基準の一部として、仮想インターフェースであるかどうかを示す空の要素。
  • インターフェース属性の設定

    • 管理 CLI でのインターフェース属性の設定

      タブ補完を使用して、入力しながらコマンド文字列を補完したり、利用可能な属性を表示したりできます。
      管理 CLI を使用して、新しいサーバーを追加してインスタンスをそのサーバーに設定し、同じ設定を XML に追加します。server-name を実際のサーバー名に置き換え、ip-address を実際の IP アドレスに置き換えます。
      /host=master/server-config=server-name:add(group=main-server-group)
      /host=master/server-config=server-name/interface=public:add(inet-address=ip-address)
      Copy to Clipboard Toggle word wrap
      管理 CLI を使用して、新しいインターフェースを追加し、インターフェース属性に新しい値を書き込みます。
      1. 新しいインターフェースの追加

        add 操作は必要に応じて新しいインターフェースを作成します。add コマンドは、管理 CLI セッションのルートから実行され、以下の例では interfacename というタイトルの新しいインターフェース名を作成し、inet-address12.0.0.2 として宣言されます。
        /interface=interfacename/:add(inet-address=12.0.0.2)
        Copy to Clipboard Toggle word wrap
      2. インターフェース属性の編集

        write-attribute 操作は、新しい値を属性に書き込みます。以下の例では、inet-address の値を 12.0.0.8 に更新します。
        /interface=interfacename/:write-attribute(name=inet-address, value=12.0.0.8)
        Copy to Clipboard Toggle word wrap
      3. インターフェース属性の検証

        include-runtime=true パラメーターを指定して read-resource 操作を実行し、サーバーモデルでアクティブな現在の値をすべて公開して、属性値が変更されたことを確認します。以下に例を示します。
        [standalone@localhost:9999 interface=public] :read-resource(include-runtime=true)
        Copy to Clipboard Toggle word wrap
    • 管理コンソールでのインターフェース属性の設定

      1. 管理コンソールへのログイン

        管理対象ドメインまたはスタンドアロンサーバーインスタンスの管理コンソールにログインします。
      2. Configuration タブに移動します。

        画面上部の Configuration タブを選択します。
        注記
        ドメインモードの場合は、画面左上の Profile ドロップダウンメニューからプロファイルを選択します。
      3. ナビゲーションメニュー から インターフェース を選択します。

        ナビゲーションメニューから Interfaces メニュー項目を選択します。
      4. 新しいインターフェースの追加

        1. Add をクリックします。
        2. NameInet Address、および Address Wildcard に、必要な値を入力します。
        3. Save をクリックします。
      5. インターフェース属性の編集

        1. 利用可能なインターフェース の一覧から編集する必要があるインターフェースを選択し編集 をクリックします。
        2. NameInet Address、および Address Wildcard に、必要な値を入力します。
        3. Save をクリックします。

5.2. ソケットバインディンググループ

5.2.1. ソケットバインディンググループ

ソケットバインディングとソケットバインディンググループを使用することにより、ネットワークポートと、JBoss EAP 6 の設定で必要なネットワーキングインターフェースとの関係を定義できます。
ソケットバインディングはソケットの名前付き設定です。これらの名前付き設定の宣言は domain.xmlstandalone.xml 設定ファイルの両方にあります。設定の他のセクションは、ソケット設定の完全な詳細を含めるのではなく、論理名でこれらのソケットを参照できます。これにより、マシンごとに異なる可能性のある相対ソケット設定を参照できます。
ソケットバインディングはソケットバインディンググループで収集されます。ソケットバインディンググループは、ある論理名でグループ化されたソケットバインディング宣言のコレクションです。named グループは、設定全体で参照できます。スタンドアロンサーバーにはこのようなグループが 1 つだけ含まれますが、管理対象ドメインインスタンスには複数のグループを含めることができます。管理対象ドメインで各サーバーグループのソケットバインディンググループを作成するか、複数のサーバーグループ間でソケットバインディンググループを共有することができます。
命名グループを使用すると、管理対象ドメインの場合にサーバーグループを設定するときにソケットバインディングの特定のグループに、簡素化された参照を使用できます。もう 1 つの一般的な使用方法は、1 つのシステム上のスタンドアロンサーバーの複数のインスタンスの設定および管理です。以下の例は、スタンドアロンおよびドメインインスタンスの設定ファイルのデフォルトのソケットバインディンググループを示しています。

例5.6 スタンドアロン設定のデフォルトソケットバインディング

standalone.xml 設定ファイルのデフォルトのソケットバインディンググループは、standard-sockets でグループ化されます。このグループは、同じ論理参照方法を使用して パブリック インターフェースでも参照されます。
   
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
        <socket-binding name="management-native" interface="management" port="${jboss							.management.native.port:9999}"/>
        <socket-binding name="management-http" interface="management" port="${jboss								.management.http.port:9990}"/>
        <socket-binding name="management-https" interface="management" port="${jboss							.management.https.port:9443}"/>
        <socket-binding name="ajp" port="8009"/>
        <socket-binding name="http" port="8080"/>
        <socket-binding name="https" port="8443"/>
        <socket-binding name="remoting" port="4447"/>
        <socket-binding name="txn-recovery-environment" port="4712"/>
        <socket-binding name="txn-status-manager" port="4713"/>
        <outbound-socket-binding name="mail-smtp">
            <remote-destination host="localhost" port="25"/>
        </outbound-socket-binding>
</socket-binding-group>
Copy to Clipboard Toggle word wrap

例5.7 ドメイン設定のデフォルトソケットバインディング

domain.xml 設定ファイルのデフォルトのソケットバインディンググループには、standard-socketsha-socketsfull-socketsfull-ha-sockets グループの 4 つのグループが含まれます。これらのグループは、public という名前のインターフェースでも参照されます。
<socket-binding-groups>
        <socket-binding-group name="standard-sockets" default-interface="public">
            <!-- Needed for server groups using the 'default' profile  -->
            <socket-binding name="ajp" port="8009"/>
            <socket-binding name="http" port="8080"/>
            <socket-binding name="https" port="8443"/>
            <socket-binding name="remoting" port="4447"/>
            <socket-binding name="txn-recovery-environment" port="4712"/>
            <socket-binding name="txn-status-manager" port="4713"/>
            <outbound-socket-binding name="mail-smtp">
                <remote-destination host="localhost" port="25"/>
            </outbound-socket-binding>
        </socket-binding-group>
        <socket-binding-group name="ha-sockets" default-interface="public">
            <!-- Needed for server groups using the 'ha' profile  -->
            <socket-binding name="ajp" port="8009"/>
            <socket-binding name="http" port="8080"/>
            <socket-binding name="https" port="8443"/>
            <socket-binding name="jgroups-mping" port="0" multicast-address="${jboss									.default.multicast.address:230.0.0.4}" multicast-port="45700"/>
            <socket-binding name="jgroups-tcp" port="7600"/>
            <socket-binding name="jgroups-tcp-fd" port="57600"/>
            <socket-binding name="jgroups-udp" port="55200" multicast-address="${jboss								.default.multicast.address:230.0.0.4}" multicast-port="45688"/>
            <socket-binding name="jgroups-udp-fd" port="54200"/>
            <socket-binding name="modcluster" port="0" multicast-address="224.0.1.105" 								multicast-port="23364"/>
            <socket-binding name="remoting" port="4447"/>
            <socket-binding name="txn-recovery-environment" port="4712"/>
            <socket-binding name="txn-status-manager" port="4713"/>
            <outbound-socket-binding name="mail-smtp">
            <remote-destination host="localhost" port="25"/>
            </outbound-socket-binding>
        </socket-binding-group>
        <socket-binding-group name="full-sockets" default-interface="public">
            <!-- Needed for server groups using the 'full' profile  -->
            <socket-binding name="ajp" port="8009"/>
            <socket-binding name="http" port="8080"/>
            <socket-binding name="https" port="8443"/>
            <socket-binding name="jacorb" interface="unsecure" port="3528"/>
            <socket-binding name="jacorb-ssl" interface="unsecure" port="3529"/>
            <socket-binding name="messaging" port="5445"/>
            <socket-binding name="messaging-group" port="0" multicast-address="${jboss								.messaging.group.address:231.7.7.7}" multicast-port="${jboss.messaging.group.port:9876}"/>
            <socket-binding name="messaging-throughput" port="5455"/>
            <socket-binding name="remoting" port="4447"/>
            <socket-binding name="txn-recovery-environment" port="4712"/>
            <socket-binding name="txn-status-manager" port="4713"/>
            <outbound-socket-binding name="mail-smtp">
            <remote-destination host="localhost" port="25"/>
            </outbound-socket-binding>
        </socket-binding-group>
        <socket-binding-group name="full-ha-sockets" default-interface="public">
            <!-- Needed for server groups using the 'full-ha' profile  -->
            <socket-binding name="ajp" port="8009"/>
            <socket-binding name="http" port="8080"/>
            <socket-binding name="https" port="8443"/>
            <socket-binding name="jacorb" interface="unsecure" port="3528"/>
            <socket-binding name="jacorb-ssl" interface="unsecure" port="3529"/>
            <socket-binding name="jgroups-mping" port="0" multicast-address="${jboss									.default.multicast.address:230.0.0.4}" multicast-port="45700"/>
            <socket-binding name="jgroups-tcp" port="7600"/>
            <socket-binding name="jgroups-tcp-fd" port="57600"/>
            <socket-binding name="jgroups-udp" port="55200" multicast-address="${jboss								.default.multicast.address:230.0.0.4}" multicast-port="45688"/>
            <socket-binding name="jgroups-udp-fd" port="54200"/>
            <socket-binding name="messaging" port="5445"/>
            <socket-binding name="messaging-group" port="0" multicast-address="${jboss								.messaging.group.address:231.7.7.7}" multicast-port="${jboss.messaging.group.port:9876}"/>
            <socket-binding name="messaging-throughput" port="5455"/>
            <socket-binding name="modcluster" port="0" multicast-address="224.0.1.105" 								multicast-port="23364"/>
            <socket-binding name="remoting" port="4447"/>
            <socket-binding name="txn-recovery-environment" port="4712"/>
            <socket-binding name="txn-status-manager" port="4713"/>
            <outbound-socket-binding name="mail-smtp">
            <remote-destination host="localhost" port="25"/>
            </outbound-socket-binding>
        </socket-binding-group>
    </socket-binding-groups>
Copy to Clipboard Toggle word wrap
ソケットバインディングインスタンスは、アプリケーションサーバーディレクトリーの standalone.xml および domain.xml ソースファイルで作成および編集できます。バインディングの管理方法として、管理コンソールまたは管理 CLI の使用が推奨されます。管理コンソールを使用する利点として、General Configuration セクションの下に専用の Socket Binding Group 画面を備えたグラフィカルユーザーインターフェースがあります。管理 CLI は、アプリケーションサーバー設定の高いレベルで、バッチ処理とスクリプトの使用を可能にするコマンドラインアプローチに基づいて API およびワークフローを提供します。両方のインターフェースにより、変更を永続化するか、サーバー設定に保存できます。

5.2.2. ソケットバインディングの設定

ソケットバインディングは固有のソケットバインディンググループで定義できます。スタンドアロンサーバーにはこのようなグループである standard-sockets グループが含まれ、さらにグループを作成することができません。代わりに、代替のスタンドアロンサーバー設定ファイルを作成できます。ただし、管理対象ドメインでは、複数のソケットバインディンググループを作成し、必要に応じて含まれるソケットバインディングを設定できます。以下の表は、各ソケットバインディングで使用できる属性を示しています。
Expand
表5.2 ソケットバインディング属性
属性 説明 ロール
name 設定の他の場所で使用する必要があるソケット設定の論理名。 必須
port この設定に基づいたソケットをバインドする必要があるベースポート。すべてのポート値にインクリメントまたはデクリメントを適用して、サーバーがこのベース値をオーバーライドするように設定できます。 必須
interface この設定に基づいたソケットをバインドする必要があるインターフェースの論理名。定義されないと、エンクロージングソケットバインディンググループからの default-interface の値が使用されます。 任意
multicast-address マルチキャストにソケットが使用される場合は、使用するマルチキャストアドレス。 任意
multicast-port マルチキャストにソケットが使用される場合は、使用するマルチキャストポート。 任意
fixed-port true の場合、port の値を常にソケットに使用する必要があり、インクリメントまたはデクリメントを適用して上書きしないでください。 任意
  • ソケットバインディンググループのソケットバインディングの設定

    管理 CLI または管理コンソールを選択して、必要に応じてソケットバインディングを設定します。
    • 管理 CLI を使用したソケットバインディングの設定

      管理 CLI を使用してソケットバインディングを設定します。
      1. 新しいソケットバインディングの追加

        必要に応じて add 操作を使用して新規アドレス設定を作成します。管理 CLI セッションのルートからこのコマンドを実行できます。以下の例では、newsocket という新しいソケットバインディングが作成され、port 属性は 1234 として宣言されています。この例は、以下に示すように、スタンドアロンサーバーと、standard-sockets ソケットバインディンググループで編集される管理対象ドメインの両方に適用されます。
        [domain@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=newsocket/:add(port=1234)
        Copy to Clipboard Toggle word wrap
      2. パターン属性の編集

        write-attribute 操作を使用して、新しい値を属性に書き込みます。タブ補完を使用すると、入力時のコマンド文字列の補完に役立つほか、利用可能な属性を明らかにできます。以下の例では、port の値を 2020に更新します。
        [domain@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=newsocket/:write-attribute(name=port,value=2020)
        Copy to Clipboard Toggle word wrap
      3. パターン属性の確認

        値が変更されたことを確認するには、include-runtime=true パラメーターを指定して read-resource 操作を実行し、サーバーモデルでアクティブな現在の値をすべて公開します。
        [domain@localhost:9999 /] /socket-binding-group=standard-sockets/socket-binding=newsocket/:read-resource
        Copy to Clipboard Toggle word wrap
    • 管理コンソールを使用したソケットバインディングの設定

      管理コンソールを使用してソケットバインディングを設定します。
      1. 管理コンソールへのログイン

        管理対象ドメインまたはスタンドアロンサーバーの管理コンソールにログインします。
      2. Configuration タブに移動します。

        画面上部の Configuration タブを選択します。
      3. ナビゲーションメニューから Socket Binding アイテムを選択します。

        General Configuration メニューを展開します。Socket Binding を選択します。管理対象ドメインを使用している場合は、Socket Binding Groups リストで対象のグループを選択します。
      4. 新しいソケットバインディングの追加

        1. 追加 ボタンをクリックします。
        2. NamePort、および Binding Group に必要な値を入力します。
        3. Save をクリックして終了します。
      5. ソケットバインディングの編集

        1. 一覧からソケットバインディングを選択し、Edit をクリックします。
        2. NameInterfacePort などの必要な値を入力します。
        3. Save をクリックして終了します。

5.2.3. JBoss EAP 6 により使用されるネットワークポート

JBoss EAP 6 のデフォルト設定で使用されるポートは、次の複数の要因によって異なります。
  • サーバーグループがデフォルトのソケットバインディンググループのいずれかを使用するか、またはカスタムグループを使用するかどうか。
  • 個別デプロイメントの要件。
数値ポートオフセット
同じ物理サーバーで複数のサーバーを実行する際にポートの競合を軽減するために、数値ポートオフセットを設定できます。サーバーが数値ポートオフセットを使用する場合は、サーバーグループのソケットバインディンググループのデフォルトのポート番号にオフセットを追加します。たとえば、ソケットバインディンググループの HTTP ポートが 8080 で、サーバーが 100 のポートオフセットを使用する場合、HTTP ポートは 8180 になります。
特に指定がない限り、ポートは TCP プロトコルを使用します。

デフォルトのソケットバインディンググループ

  • full-ha-sockets
  • full-sockets
  • ha-sockets
  • standard-sockets
これらのソケットバインディンググループは domain.xml でのみ利用できます。スタンドアロンサーバープロファイルには、標準のソケットバインディンググループのみが含まれます。このグループは standalone.xml の standard-sockets、standalone-ha.xmlha-socketsstandalone-full.xml の場合はfull-socketsstandalone-full-ha.xml の場合は full-ha-sockets に対応します。スタンドアロンプロファイルには、management-{native,http,https} などのソケットバインディングが含まれます。
Expand
表5.3 デフォルトのソケットバインディングの参照
名前 ポート マルチキャストポート 説明 full-ha-sockets full-sockets ha-socket standard-socket
ajp 8009 Apache JServ プロトコル。HTTP クラスタリングおよび負荷分散に使用します。 はい はい はい はい
http 8080 デプロイされた Web アプリケーションのデフォルトポート。 はい はい はい はい
https 8443 デプロイされた Web アプリケーションとクライアント間の SSL 暗号化接続。 はい はい はい はい
jacorb 3528 JTS トランザクションおよび他の ORB 依存サービス用の CORBA サービス。 はい はい いいえ いいえ
jacorb-ssl 3529 SSL 暗号化 CORBA サービス。 はい はい いいえ いいえ
jgroups-diagnostics 7500 マルチキャスト。HA クラスターでのピア検出に使用されます。管理インターフェースを使用して設定できません。 はい いいえ はい いいえ
jgroups-mping 45700 マルチキャスト。HA クラスターでの初期メンバーシップの検出に使用されます。 はい いいえ はい いいえ
jgroups-tcp 7600 TCP を使用した、HA クラスター内でのユニキャストピア検出。 はい いいえ はい いいえ
jgroups-tcp-fd 57600 TCP を介した HA 障害検出に使用されます。 はい いいえ はい いいえ
jgroups-udp 55200 45688 UDP を使用した、HA クラスター内でのマルチキャストピア検出。 はい いいえ はい いいえ
jgroups-udp-fd 54200 UDP を介した HA 障害検出に使用されます。 はい いいえ はい いいえ
messaging 5445 JMS サービス。 はい はい いいえ いいえ
messaging-group 0 9876 HornetQ JMS ブロードキャストと検出グループにより参照されます。 はい はい いいえ いいえ
messaging-throughput 5455 JMS Remoting により使用されます。 はい はい いいえ いいえ
mod_cluster 23364 JBoss EAP 6 と HTTP ロードバランサー間の通信に対するマルチキャストポート。 はい いいえ はい いいえ
remoting 4447 リモート EJB の呼び出しに使用されます。 はい はい はい はい
txn-recovery-environment 4712 JTA トランザクションリカバリーマネージャー。 はい はい はい はい
txn-status-manager 4713 JTA / JTS トランザクションマネージャー。 はい はい はい はい

管理ポート

ソケットバインディンググループの他に、各ホストコントローラーによって 2 つのポートが管理目的で開かれます。

  • 9990 - Web 管理コンソールポート
  • 9999 - 管理コンソールと管理 API が使用するポート
さらに、管理コンソールに対して HTTPS が有効になっている場合、9443 もデフォルトポートとして開かれます。

5.2.4. ソケットバインディンググループのポートオフセット

ポートオフセットは、そのサーバーのソケットバインディンググループによって提供されたポート値に追加される数値オフセットです。これにより、単一のサーバーは所属するサーバーグループのソケットバインディングを継承でき、オフセットを使用してグループ内の他のサーバーと競合しないようにできます。たとえば、ソケットバインディンググループの HTTP ポートが 8080 で、サーバーが 100 のポートオフセットを使用する場合、HTTP ポートは 8180 になります。

5.2.5. ポートオフセットの設定

  • ポートオフセットの設定

    管理 CLI または管理コンソールを選択してポートオフセットを設定します。
    • 管理 CLI を使用したポートオフセットの設定

      管理 CLI を使用してポートオフセットを設定します。
      1. ポートオフセットの編集

        write-attribute 操作を使用して、新しい値をポートオフセットに書き込みます。以下の例では、server-twosocket-binding-port-offset 値を 250 に更新しています。このサーバーは、デフォルトのローカルホストグループのメンバーです。変更を有効にするには、再起動が必要です。
        [domain@localhost:9999 /] /host=master/server-config=server-two/:write-attribute(name=socket-binding-port-offset,value=250)
        Copy to Clipboard Toggle word wrap
      2. ポートオフセット属性の確認

        値が変更されたことを確認するには、include-runtime=true パラメーターを指定して read-resource 操作を実行し、サーバーモデルでアクティブな現在の値をすべて公開します。
        [domain@localhost:9999 /] /host=master/server-config=server-two/:read-resource(include-runtime=true)
        Copy to Clipboard Toggle word wrap
    • 管理コンソールを使用したポートオフセットの設定

      管理コンソールを使用してポートオフセットを設定します。
      1. 管理コンソールへのログイン

        管理対象ドメインの管理コンソールにログインします。
      2. ドメイン タブの選択

        画面上部の ドメイン タブを選択します。
      3. ポートオフセット属性の編集

        1. Available Server Configurations リストでサーバーを選択し、以下のアセンブリーリストの上部にある Edit をクリックします。
        2. Port Offset フィールドに任意の値を入力します。
        3. Save をクリックして終了します。

5.3. IPv6

5.3.1. IPv6 ネットワーキング向け JVM スタック設定の指定

概要
このトピックでは、JBoss EAP 6 インストールでの IPv6 ネットワーキングの有効化について説明します。

手順5.1 IPv4 Stack Java プロパティーの無効化

  1. インストールに関連するファイルを開きます。
    • スタンドアロンサーバーの場合:

      Open EAP_HOME/bin/standalone.conf.
    • 管理対象ドメインの場合:

      Open EAP_HOME/bin/domain.conf.
  2. IPv4 Stack Java プロパティーを false に変更します。
    -Djava.net.preferIPv4Stack=false
    Copy to Clipboard Toggle word wrap
    以下に例を示します。

    例5.8 JVM オプション

    # Specify options to pass to the Java VM.
    #
    if [ "x$JAVA_OPTS" = "x" ]; then
       JAVA_OPTS="-Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=false 
       -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 
       -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv6Addresses=true"
    fi
    
    Copy to Clipboard Toggle word wrap

5.3.2. IPv6 ネットワークに対するインターフェース宣言の設定

概要

次の手順に従って、インターフェース inet アドレスを IPv6 のデフォルトに設定します。

手順5.2 IPv6 ネットワーキングのインターフェースの設定

  1. 画面上部の Configuration タブを選択します。
  2. General Configuration メニューを展開し、Interfaces を選択します。
  3. Available Interfaces リストからインターフェースを選択します。
  4. 詳細一覧で Edit をクリックします。
  5. 下記の inet アドレスを設定します。
    ${jboss.bind.address.management:[ADDRESS]}
    Copy to Clipboard Toggle word wrap
  6. Save をクリックして終了します。
  7. サーバーを再起動し、変更を実装します。

5.3.3. IPv6 アドレス用 JVM スタック設定の指定

概要
このトピックでは、JBoss EAP 6 インストールで IPv6 アドレスを優先するよう設定ファイルで設定する方法について説明します。

手順5.3 IPv6 アドレスを優先するよう JBoss EAP 6 インストールを設定する

  1. インストールに関連するファイルを開きます。
    • スタンドアロンサーバーの場合:

      Open EAP_HOME/bin/standalone.conf.
    • 管理対象ドメインの場合:

      Open EAP_HOME/bin/domain.conf.
  2. 以下の Java プロパティーを Java VM オプションに追加します。
    -Djava.net.preferIPv6Addresses=true
    Copy to Clipboard Toggle word wrap
    以下に例を示します。

    例5.9 JVM オプション

    # Specify options to pass to the Java VM.
    #
    if [ "x$JAVA_OPTS" = "x" ]; then
       JAVA_OPTS="-Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=false 
       -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 
       -Dsun.rmi.dgc.server.gcInterval=3600000 -Djava.net.preferIPv6Addresses=true"
    fi
    
    Copy to Clipboard Toggle word wrap

5.4. remoting

5.4.1. リモーティングのメッセージサイズの設定

remoting サブシステムは、リモーティングプロトコルのメッセージのサイズを制限するオプションを提供します。最大インバウンドメッセージサイズ(MAX_INBOUND_MESSAGE_SIZE)および最大送信メッセージサイズ(MAX_OUTBOUND_MESSAGE_SIZE)を設定して、適切なサイズ制限内でメッセージが受信され、送信されるようにすることができます。
MAX_INBOUND_MESSAGE_SIZE および MAX_OUTBOUND_MESSAGE_SIZE は ejb3 サブシステムで設定でき、値はバイト単位です。
<subsystem xmlns="urn:jboss:domain:ejb3:1.5">
......
	<remote connector-ref="remoting-connector" thread-pool-name="default">
		<channel-creation-options>
			<option name="MAX_INBOUND_MESSAGE_SIZE" value="xxxxx" type="remoting"/>
			<option name="MAX_OUTBOUND_MESSAGE_SIZE" value="xxxxx" type="remoting"/>
		</channel-creation-options>
	</remote>
......
</subsystem>
Copy to Clipboard Toggle word wrap
リモーティングプロトコルのメッセージサイズを設定すると、システムメモリーが効率的に使用され、重要な操作の実行中にメモリー不足が発生しないようになります。
送信側が最大許容制限(MAX_OUTBOUND_MESSAGE_SIZE)を超えるメッセージを送信する場合、サーバーは例外をスローし、データの送信を取り消します。しかし、コネクションは開いたままとなり、必要に応じて送信側はメッセージを閉じることができます。
受信したメッセージが最大許容制限(MAX_INBOUND_MESSAGE_SIZE)を超える場合、接続が開いたまま、メッセージは非同期に閉じられます。

5.4.2. Remoting サブシステムの設定

概要

JBoss Remoting には、ワーカースレッドプール、1 つ以上のコネクター、および一連のローカルおよびリモート接続 URI の 3 つのトップレベル設定可能な要素があります。このトピックでは、設定可能な各項目の説明、各項目の設定方法についての CLI コマンドの例、および完全に設定されたサブシステムの XML の例を紹介します。この設定はサーバーにのみ適用されます。独自のアプリケーションにカスタムコネクターを使用しない限り、ほとんどのユーザーは Remoting サブシステムをまったく設定する必要はありません。EJB などの Remoting クライアントとして動作するアプリケーションには、特定のコネクターに接続するための個別の設定が必要です。

注記
Remoting サブシステム設定は Web ベースの管理コンソールに公開されませんが、コマンドラインベースの管理 CLI から完全に設定可能です。手作業による XML の編集は推奨されません。

CLI コマンドの適合

CLI コマンドは、デフォルト のプロファイルの設定時に管理対象ドメインに対して式化されます。別のプロファイルを設定するには、その名前を置き換えます。スタンドアロンサーバーの場合は、コマンドの /profile=default 部分を省略します。

Remoting サブシステム外の設定

remoting サブシステム以外の設定側面がいくつかあります。

ネットワークインターフェース
remoting サブシステムによって使用されるネットワークインターフェースは、domain/configuration/domain.xml または standalone/configuration/standalone.xml で定義された パブリック インターフェースです。
<interfaces>
   <interface name="management"/>
   <interface name="public"/>
   <interface name="unsecure"/>
</interfaces>        

Copy to Clipboard Toggle word wrap
パブリック インターフェースのホストごとの定義は、domain.xml または standalone.xml と同じディレクトリーの host.xml で定義されます。このインターフェースは、他のサブシステムによっても使用されます。変更時には注意が必要です。
<interfaces>
   <interface name="management">
      <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
   </interface>
   <interface name="public">
      <inet-address value="${jboss.bind.address:127.0.0.1}"/>
   </interface>
   <interface name="unsecure">
      <!-- Used for IIOP sockets in the standard configuration.
         To secure JacORB you need to setup SSL -->
      <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/>
   </interface>
</interfaces>             

Copy to Clipboard Toggle word wrap
socket-binding
remoting サブシステムによって使用されるデフォルトの socket-binding は TCP ポート 4447 にバインドされます。これを変更する必要がある場合は、ソケットバインディングおよびソケットバインディンググループのドキュメントを参照してください。
ソケットバインディンググループとソケットバインディンググループに関する情報は、JBoss EAP 『管理ガイドのソケットバインディンググループの章を参照し』 てください。『https://access.redhat.com/documentation/ja-jp/red_hat_jboss_enterprise_application_platform/?version=6.4
EJB のリモーティングコネクターリファレンス
EJB サブシステムには、リモートメソッド呼び出しに対するリモーティングコネクターへの参照が含まれます。デフォルト設定は次のとおりです。
<remote connector-ref="remoting-connector" thread-pool-name="default"/>            

Copy to Clipboard Toggle word wrap
セキュアなトランスポート設定
リモーティングトランスポートは、クライアントが要求した場合に StartTLS を使用してセキュアな(HTTPS、Secure Servlet など)接続を使用します。セキュアな接続とセキュアでない接続に同じソケットバインディング(ネットワークポート)が使用されるため、サーバー側の追加設定は必要ありません。クライアントは必要に応じてセキュアなトランスポートまたはセキュアでないトランスポートを要求します。EJB、ORB、JMS プロバイダーなどの Remoting を使用する JBoss EAP 6 コンポーネントは、デフォルトでセキュアなインターフェースを要求します。
警告: StartTLS セキュリティーに関する考慮事項
StartTLS は、クライアントが要求した場合にセキュアな接続をアクティベートし、セキュアでない接続にデフォルト設定することで機能します。これは、攻撃者がクライアントの要求をインターセプト してセキュアでない接続を要求するために Middle スタイルの不正使用における Man に悪影響を与えることが本質的に行われます。セキュアでない接続が実際に適切なフォールバックである場合を除き、クライアントがセキュアな接続を受信しない場合、適切に失敗するよう記述する必要があります。

ワーカースレッドプール

ワーカースレッドプールは、Remoting コネクターを介して提供される作業の処理に使用できるスレッドのグループです。これは単一の要素 &lt ;worker-thread-pool> で、複数の属性を取ります。ネットワークタイムアウトの取得、スレッドの不足、またはメモリー使用量の制限が必要な場合には、これらの属性をチューニングします。特定の推奨事項は、特定の状況によって異なります。詳細は Red Hat グローバルサポートサービスまでお問い合わせください。

Expand
表5.4 ワーカースレッドプールの属性
属性 説明 CLI コマンド
read-threads
リモーティングワーカーに対して作成する読み取りスレッドの数。デフォルトは1です。
/profile=default/subsystem=remoting/:write-attribute(name=worker-read-threads,value=1)
write-threads
リモーティングワーカーに作成する書き込みスレッドの数。デフォルトは1です。
/profile=default/subsystem=remoting/:write-attribute(name=worker-write-threads,value=1)
task-keepalive
コアでないリモーティングワーカーのタスクスレッドにキープアライブを使用する期間 (ミリ秒単位)。デフォルトは 60 です。
/profile=default/subsystem=remoting/:write-attribute(name=worker-task-keepalive,value=60)
task-max-threads
リモーティングワーカーのタスクスレッドプールに対するスレッドの最大数。デフォルトは 16 です。
/profile=default/subsystem=remoting/:write-attribute(name=worker-task-max-threads,value=16)
task-core-threads
リモーティングワーカーのタスクスレッドプールに対するコアスレッドの数。デフォルトは 4 です。
/profile=default/subsystem=remoting/:write-attribute(name=worker-task-core-threads,value=4)
task-limit
許可するリモーティングワーカータスクの最大数。 この数を超えるリモーティングワーカータスクは拒否されます。デフォルトは 16384 です。
/profile=default/subsystem=remoting/:write-attribute(name=worker-task-limit,value=16384)

コネクター

コネクターは主な Remoting 設定要素です。複数のコネクターを設定できます。それぞれは複数のサブ要素を持つ & lt;connector > 要素といくつかの属性で構成されます。デフォルトのコネクターは、JBoss EAP 6 の複数のサブシステムによって使用されます。カスタムコネクターの要素や属性の設定はアプリケーションに依存するため、詳細は Red Hat グローバルサポートサービスにお問い合わせください。

Expand
表5.5 コネクターの属性
属性 説明 CLI コマンド
socket-binding このコネクターに使用するソケットバインディングの名前。
/profile=default/subsystem=remoting/connector=remoting-connector/:write-attribute(name=socket-binding,value=remoting)
authentication-provider
このコネクターで使用するJASPIC(Java Authentication Service Provider Interface for Containers)モジュール。モジュールはクラスパスにある必要があります。
/profile=default/subsystem=remoting/connector=remoting-connector/:write-attribute(name=authentication-provider,value=myProvider)
security-realm
オプション。アプリケーションのユーザー、パスワード、およびロールが含まれるセキュリティーレルム。EJB または Web アプリケーションはセキュリティーレルムに対して認証できます。ApplicationRealm はデフォルトの JBoss EAP 6 インストールで利用できます。
/profile=default/subsystem=remoting/connector=remoting-connector/:write-attribute(name=security-realm,value=ApplicationRealm)
Expand
表5.6 コネクター要素
属性 説明 CLI コマンド
sasl
SASL(Simple Authentication and Security Layer)認証メカニズムの組み込み要素
該当なし
properties
1 つ以上の &lt ;property&gt; 要素が含まれ、それぞれ name 属性と任意の value 属性が含まれます。
/profile=default/subsystem=remoting/connector=remoting-connector/property=myProp/:add(value=myPropValue)

送信接続

3 種類のアウトバウンド接続を指定することができます。

  • URI への送信接続。
  • ローカルアウトバウンド接続: ソケットなどのローカルリソースに接続します。
  • リモートアウトバウンド接続: リモートリソースに接続し、セキュリティーレルムを使用して認証します。
すべてのアウトバウンド接続は < outbound-connections> 要素に囲まれて います。これらの各接続タイプは outbound-socket-binding-ref 属性を取ります。outbound-connection は uri 属性を取ります。リモートアウトバウンド接続は、承認に使用する任意の username および security-realm 属性を取ります。
Expand
表5.7 送信接続要素
属性 説明 CLI コマンド
outbound-connection 汎用アウトバウンド接続。
/profile=default/subsystem=remoting/outbound-connection=my-connection/:add(uri=http://my-connection)
local-outbound-connection 暗黙的な local:// URI スキームを使用した送信接続。
/profile=default/subsystem=remoting/local-outbound-connection=my-connection/:add(outbound-socket-binding-ref=remoting2)
remote-outbound-connection
セキュリティーレルムで basic/digest 認証を使用した remote:// URI スキームの送信接続。
/profile=default/subsystem=remoting/remote-outbound-connection=my-connection/:add(outbound-socket-binding-ref=remoting,username=myUser,security-realm=ApplicationRealm)

SASL 要素

SASL 子要素を定義する前に、最初の SASL 要素を作成する必要があります。以下のコマンドを使用します。

/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:add
Copy to Clipboard Toggle word wrap
SASL 要素の子要素は以下の表で説明されています。
Expand
表5.8 SASL 子要素
属性 説明 CLI コマンド
include-mechanisms
SASL メカニズムのリストである value 属性が含まれます。
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=include-mechanisms,value=["DIGEST","PLAIN","GSSAPI"])
Copy to Clipboard Toggle word wrap
qop
優先順で SASL Quality of 保護値のリストである value 属性が含まれます。
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=qop,value=["auth"])
Copy to Clipboard Toggle word wrap
strength
value 属性が含まれます。これは SASL 暗号強度の値のリストで優先順で表されます。
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=strength,value=["medium"])
Copy to Clipboard Toggle word wrap
reuse-session
ブール値である value 属性が含まれます。true の場合、セッションを再利用しようとします。
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=reuse-session,value=false)
Copy to Clipboard Toggle word wrap
server-auth
ブール値である value 属性が含まれます。true の場合、サーバーはクライアントに対して認証します。
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=server-auth,value=false)
Copy to Clipboard Toggle word wrap
policy
ゼロ以上の要素が含まれるローカリング要素。それぞれが単一の を取ります。
  • forward-secrecy: 前方機密性の実装にメカニズムが必要であるかどうか(1 つのセッションに分割しても、今後のセッションに侵入するための情報が自動的に提供されない)
  • 非アクティブ - 辞書攻撃を受けやすいメカニズムを許可するかどうか。false を指定すると許可され、true は拒否されます。
  • no-anonymous: 匿名ログインを受け入れるメカニズムを許可するかどうか。false を指定すると許可され、true は拒否されます。
  • no-dictionary: パッシブ辞書攻撃を受けやすいメカニズムを許可するかどうか。false を指定すると許可され、true は拒否されます。
  • no-plain-text: 単純なプレーンテキスト攻撃を受けやすいメカニズムを許可するかどうか。false を指定すると許可され、true は拒否されます。
  • pass-credentials: クライアントのクレデンシャルを渡すメカニズムを許可するかどうか。
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:add
Copy to Clipboard Toggle word wrap
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=forward-secrecy,value=true)
Copy to Clipboard Toggle word wrap
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=no-active,value=false)
Copy to Clipboard Toggle word wrap
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=no-anonymous,value=false)
Copy to Clipboard Toggle word wrap
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=no-dictionary,value=true)
Copy to Clipboard Toggle word wrap
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=no-plain-text,value=false)
Copy to Clipboard Toggle word wrap
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=pass-credentials,value=true)
Copy to Clipboard Toggle word wrap
properties
1 つ以上の &lt ;property&gt; 要素が含まれ、それぞれ name 属性と任意の value 属性が含まれます。
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/property=myprop:add(value=1)
Copy to Clipboard Toggle word wrap
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/property=myprop2:add(value=2)
Copy to Clipboard Toggle word wrap

例5.10 設定例

以下の例は、JBoss EAP 6 に同梱されるデフォルトの remoting サブシステムを示しています。
<subsystem xmlns="urn:jboss:domain:remoting:1.1">
    <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"/>
</subsystem>    

Copy to Clipboard Toggle word wrap
この例には多くのハイフン的な値が含まれており、前述の要素と属性をコンテキストに配置するように提示されています。
<subsystem xmlns="urn:jboss:domain:remoting:1.1">
    <worker-thread-pool read-threads="1" task-keepalive="60" task-max-threads="16" task-core-thread="4" task-limit="16384" write-threads="1" />
    <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm">
        <sasl>
            <include-mechanisms value="GSSAPI PLAIN DIGEST-MD5" />
            <qop value="auth" />
            <strength value="medium" />
            <reuse-session value="false" />
            <server-auth value="false" />
            <policy>
                <forward-secrecy value="true" />
                <no-active value="false" />
                <no-anonymous value="false" />
                <no-dictionary value="true" />
                <no-plain-text value="false" />
                <pass-credentials value="true" />
            </policy>
            <properties>
                <property name="myprop1" value="1" />
                <property name="myprop2" value="2" />
            </properties>
        </sasl>
        <authentication-provider name="myprovider" />
        <properties>
            <property name="myprop3" value="propValue" />
        </properties>
    </connector>
    <outbound-connections>
        <outbound-connection name="my-outbound-connection" uri="http://myhost:7777/"/>
        <remote-outbound-connection name="my-remote-connection" outbound-socket-binding-ref="my-remote-socket" username="myUser" security-realm="ApplicationRealm"/>
        <local-outbound-connection name="myLocalConnection" outbound-socket-binding-ref="my-outbound-socket"/>
    </outbound-connections>
</subsystem>    

Copy to Clipboard Toggle word wrap

設定イントロスペクションが文書化されていない

  • JNDI およびマルチキャストの自動検出

第6章 データソース管理

6.1. はじめに

6.1.1. JDBC

JDBC API は、Java アプリケーションがデータベースにアクセスする方法を定義する基準です。アプリケーションは JDBC ドライバーを参照するデータソースを設定します。その後、データベースではなくドライバーに対してアプリケーションを記述できます。ドライバーはコードをデータベース言語に変換します。そのため、適切なドライバーがインストールされていればアプリケーションをサポートされるデータベースで使用できます。
JDBC 4.0 仕様は、に定義されてい http://jcp.org/en/jsr/detail?id=221 ます。

手順6.1 管理コンソールを使用したデータソースプール接続のテスト

  1. 管理コンソールの上部から Runtime タブを選択します。
  2. 左側の Subsystems メニューを展開し、Datasources を選択します。
  3. Test Connection ボタンをクリックしてデータソースへの接続をテストし、設定が正しいことを確認します。

手順6.2 管理 CLI を使用したデータソース接続のテスト

  1. CLI ツールを起動し、サーバーに接続します。
  2. 以下の管理 CLI コマンドを実行して接続をテストします。
    • スタンドアロンモードでは、以下のコマンドを入力します。
      /subsystem=datasources/data-source=ExampleDS:test-connection-in-pool
      
      Copy to Clipboard Toggle word wrap
    • ドメインモードでは、以下のコマンドを入力します。
      host=master/server=server-one/subsystem=datasources/data-source=ExampleDS:test-connection-in-pool
      Copy to Clipboard Toggle word wrap
JDBC とデータソースの使用を開始するにあたっては、JBoss EAP 6 の管理設定ガイドの JDBC ドライバーのセクションを参照してください。

6.1.2. JBoss EAP 6 でサポートされるデータベース

JBoss EAP 6 でサポートされる JDBC 準拠のデータベースの一覧は、を参照し https://access.redhat.com/articles/111663 てください。

6.1.3. データソースの型

リソースの一般的なタイプには、データソースと XA データソース があります
非 XA データソースは、トランザクションを使用しないアプリケーション、または単一のデータベースでトランザクションを使用するアプリケーションに使用されます。
XA データソースは、トランザクションが複数のデータベースにわたって分散されるアプリケーションによって使用されます。XA データソースを使用すると追加のオーバーヘッドが発生します。
管理コンソールあるいは管理 CLI でデータソースを作成するときに、データソースの型を指定します。

6.1.4. データソースの例

JBoss EAP 6 には H2 データベースが含まれています。これは、開発者がアプリケーションを迅速に構築できるように、軽量でリレーショナルデータベース管理システムであり、プラットフォームのデータソースの例になります。
警告
ただし、実稼働環境では使用しないでください。これは、アプリケーションをテストおよび構築するために必要なすべての標準をサポートする非常に小さい自己完結型のデータソースです。ただし、本番稼働用として堅牢または拡張性はありません。
サポートされるデータソースおよび認定済みのデータソースのリストは、「JBoss EAP 6 でサポートされるデータベース」 を参照してください。

6.1.5. -ds.xml ファイルのデプロイメント

JBoss EAP 6 では、データソースは server サブシステムのリソースとして定義されます。以前のバージョンでは、サーバー設定のデプロイメントディレクトリーに *-ds.xml データソース設定ファイルが必要でした。*-ds.xml ファイルは、以下の 『Schemas』 で利用可能な 1.1 データソーススキーマに従って JBoss EAP 6 にデプロイでき http://www.ironjacamar.org/documentation.html ます。
警告
この機能は開発目的でのみ使用してください。JBoss の管理ツールではサポートされないため、本番環境では推奨されません。この機能は JBoss EAP 6.4 で非推奨となり、製品の次期メジャーリリースではサポートされません。
重要
*-ds.xml ファイルのデプロイ時に、すでにデプロイ/定義された <driver> エントリーへの参照を使用する必要があります。

6.2. JDBC ドライバー

6.2.1. 管理コンソールを用いた JDBC ドライバーのインストール

概要

アプリケーションが JDBC データソースに接続する前に、データソースベンダーの JDBC ドライバーを JBoss EAP 6 が使用できる場所にインストールする必要があります。JBoss EAP 6 では、これらのドライバーを他のデプロイメントと同じようにデプロイできます。これは、管理対象ドメインを使用する場合、サーバーグループの複数のサーバーにデプロイできることを意味します。

前提条件

このタスクを実行する前に、以下の前提条件を満たしている必要があります。

  • データベースのベンダーから JDBC ドライバーをダウンロードする必要があります。
注記
JDBC 4 準拠のドライバーは自動的に認識され、名前とバージョンでシステムにインストールされます。JDBC JAR は、Java サービスプロバイダーメカニズムを使用して識別されます。このような JAR には、JAR の Driver クラスの名前が含まれる META-INF/services/java.sql.Driver テキストが含まれます。

手順6.3 JDBC ドライバー JAR の編集

JDBC ドライバー JAR が JDBC 4 未対応である場合、以下の方法でデプロイ可能にすることができます。
  1. 空の一時ディレクトリーに移動するか、空の一時ディレクトリーを作成します。
  2. META-INF サブディレクトリーを作成します。
  3. META-INF/services サブディレクトリーを作成します。
  4. JDBC ドライバーの完全修飾クラス名を示す 1 行が含まれる、META-INF/services/java.sql.Driver ファイルを作成します。
  5. JAR コマンドラインツールを使用して、次のように JAR を更新します。
    jar \-uf jdbc-driver.jar META-INF/services/java.sql.Driver
    Copy to Clipboard Toggle word wrap
  6. 管理対象ドメインを使用する場合は、JAR ファイルをサーバーグループにデプロイします。それ以外の場合は、サーバーにデプロイします。「管理コンソールを使用してデプロイされたアプリケーションを有効化」を参照してください。

結果:

JDBC ドライバーがデプロイされ、アプリケーションが使用できるようになります。

6.2.2. コアモジュールとしての JDBC ドライバーのインストール

前提条件

このタスクを実行する前に、以下の前提条件を満たしている必要があります。

手順6.4 管理 CLI を使用してコアモジュールとしての JDBC ドライバーのインストール

  1. サーバーを起動します。
  2. 管理 CLI を起動しますが、稼働中のインスタンスへの接続に --connect 引数または -c 引数を使用しないでください。
  3. module add CLI コマンドを使用して、新しいモジュールを追加します。

    例6.1 MySQL JDBC ドライバーモジュールを追加する CLI コマンドの例

    module add --name=com.mysql --resources=/path/to/mysql.jar --dependencies=javax.api,javax.transaction.api
    Copy to Clipboard Toggle word wrap
    注記
    module 管理 CLI コマンドを使用してモジュールの追加および削除は テクノロジープレビュー としてのみ提供されるため、リモート JBoss EAP インスタンスにモジュールを追加しないでください。本番環境では、モジュールを手作業で追加および削除する必要があります。
    以下の手順に従って、モジュールを手動で追加します。
    1. ファイルパス構造は EAP_HOME/modules/ ディレクトリーの下に作成されます。たとえば、MySQL JDBC ドライバーの場合は、EAP_HOME/modules/com/mysql/main/ のようになります。
    2. リソースとして指定された JAR ファイルは main/ サブディレクトリーにコピーされます。
    3. 指定の依存関係を持つ module.xml ファイルが main/ サブディレクトリーに作成されます。module.xml ファイルの例は、「モジュール」 を参照してください。
    このコマンドを使用してモジュールを追加および削除する方法は、module --help を実行します。
  4. CLI コマンド connect を使用して、実行中のインスタンスに接続します。
  5. CLI コマンドを実行して JDBC ドライバーモジュールをサーバー設定に追加します。
    選択するコマンドは、JDBC ドライバー JAR にある /META-INF/services/java.sql.Driver ファイルにリストされているクラスの数によって異なります。たとえば、MySQL 5.1.20 JDBC JAR の /META-INF/services/java.sql.Driver ファイルには、2 つのクラスが一覧表示されます。
    • com.mysql.jdbc.Driver
    • com.mysql.fabric.jdbc.FabricMySQLDriver
    複数のエントリーがある場合は、ドライバークラスの名前も指定する必要があります。これを実行しないと、以下のようなエラーが発生します。

    例6.2 ドライバークラスエラー

    JBAS014749: Operation handler failed: Service jboss.jdbc-driver.mysql is already registered
    Copy to Clipboard Toggle word wrap
    • 1 つのクラスエントリーを含む JDBC JAR に対して CLI コマンドを実行します。
      /subsystem=datasources/jdbc-driver=DRIVER_NAME:add(driver-name=DRIVER_NAME,driver-module-name=MODULE_NAME,driver-xa-datasource-class-name=XA_DATASOURCE_CLASS_NAME)
      Copy to Clipboard Toggle word wrap

      例6.3 1 つのドライバークラスを持つ JDBC JAR に対するスタンドアロンモードの CLI コマンド

      /subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-xa-datasource-class-name=com.mysql.jdbc.jdbc2.optional.MysqlXADataSource)
      Copy to Clipboard Toggle word wrap

      例6.4 1 つのドライバークラスを持つ JDBC JAR に対するドメインモードの CLI コマンド

      /profile=ha/subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-xa-datasource-class-name=com.mysql.jdbc.jdbc2.optional.MysqlXADataSource)
      Copy to Clipboard Toggle word wrap
    • 複数のクラスエントリーを含む JDBC JAR に対して CLI コマンドを実行します。
      /subsystem=datasources/jdbc-driver=DRIVER_NAME:add(driver-name=DRIVER_NAME,driver-module-name=MODULE_NAME,driver-xa-datasource-class-name=XA_DATASOURCE_CLASS_NAME, driver-class-name=DRIVER_CLASS_NAME)
      Copy to Clipboard Toggle word wrap

      例6.5 複数のドライバークラスエントリーを持つ JDBC JAR に対するスタンドアロンモードの CLI コマンド

      /subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-xa-datasource-class-name=com.mysql.jdbc.jdbc2.optional.MysqlXADataSource, driver-class-name=com.mysql.jdbc.Driver)
      Copy to Clipboard Toggle word wrap

      例6.6 複数のドライバークラスエントリーを持つ JDBC JAR に対するドメインモードの CLI コマンド

      /profile=ha/subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-xa-datasource-class-name=com.mysql.jdbc.jdbc2.optional.MysqlXADataSource, driver-class-name=com.mysql.jdbc.Driver)
      Copy to Clipboard Toggle word wrap

      例6.7 複数の非 XA ドライバークラスエントリーを持つ JDBC JAR に対するドメインモードの CLI コマンド

      /profile=ha/subsystem=datasources/jdbc-driver=oracle/:add(driver-module-name=com.oracle,driver-name=oracle,jdbc-compliant=true,driver-datasource-class-name=oracle.jdbc.OracleDriver)
      Copy to Clipboard Toggle word wrap

結果

JDBC ドライバーがインストールされ、コアモジュールとして設定されます。アプリケーションのデータソースが JDBC ドライバーを参照できる状態になります。

6.2.3. JDBC ドライバーをダウンロードできる場所

以下の表は、JBoss EAP 6 で使用される一般的なデータベースの JDBC ドライバーをダウンロードできる場所を示しています。
注記
これらのリンク先は他社の Web サイトであるため、Red Hat は管理しておらず、積極的に監視も行っていません。データベースの最新ドライバーについては、データベースベンダーのドキュメントおよび Web サイトを確認してください。

6.2.4. ベンダー固有クラスへのアクセス

概要

このトピックでは、JDBC 固有クラスを使用するために必要な手順について説明します。これは、アプリケーションが JDBC API の一部ではないベンダー固有の機能を使用する必要がある場合はに必要です。

警告
これは高度な使用法です。JDBC API に含まれない機能を必要とするアプリケーションのみこれを実装します。
重要
このプロセスは、再認証メカニズムを使用し、ベンダー固有のクラスにアクセスする場合に必要です。
重要
接続は IronJacamar コンテナーによって制御されるため、ベンダー固有の API ガイドラインに厳密に従ってください。

手順6.5 アプリケーションへの依存関係の追加

以下の方法のいずれかを使用して、依存関係をアプリケーションに追加できます。任意の方法を選択します。
    • MANIFEST.MF ファイルの設定

      1. テキストエディターでアプリケーションの META-INF/MANIFEST.MF ファイルを開きます。
      2. JDBC モジュールの依存関係を追加し、ファイルを保存します。
        Dependencies: MODULE_NAME
        Copy to Clipboard Toggle word wrap

        例6.8 com.mysql が依存関係として宣言されている MANIFEST.MF ファイル

        Dependencies: com.mysql
        Copy to Clipboard Toggle word wrap
      1. jboss-deployment-structure.xml ファイルの作成

        アプリケーションの META-INF/ または WEB-INF フォルダーに jboss-deployment-structure.xml というファイルを作成します。

        例6.9 com.mysql が依存関係として宣言されている jboss-deployment-structure.xml ファイル

        <jboss-deployment-structure>
          <deployment>
            <dependencies>
              <module name="com.mysql" />
            </dependencies>
          </deployment>
        </jboss-deployment-structure>
        Copy to Clipboard Toggle word wrap

例6.10 ベンダー固有 API へのアクセス

以下のサンプルは MySQL API にアクセスします。
import java.sql.Connection;
import org.jboss.jca.adapters.jdbc.WrappedConnection;

  Connection c = ds.getConnection();
  WrappedConnection wc = (WrappedConnection)c;
  com.mysql.jdbc.Connection mc = wc.getUnderlyingConnection();
Copy to Clipboard Toggle word wrap

6.3. 非 XA データソース

6.3.1. 管理インターフェースによる非 XA データソースの作成

概要

ここでは、管理コンソールまたは管理 CLI のいずれかを使用して非 XA データソースを作成する手順について取り上げます。

前提条件

  • JBoss EAP 6 サーバーが稼働している必要があります。
Oracle のデータソース
バージョン 10.2 以前の Oracle データソースでは、トランザクション以外の接続とトランザクション接続が混在するとエラーが発生するため、<no-tx-separate-pools/> パラメーターが必要でした。特定のアプリケーションでこのパラメーターが不要になる場合があります。
ドメインモード
ドライバーリストの重複などの問題を防ぐために、選択したドライバーがプロファイルで利用できないか、JBoss EAP 6.4 以降ではプロファイルのサーバーが実行されていない場合に表示されないため、JBoss EAP 6.4 以降ではモジュールとしてインストールされ、プロファイルから適切に参照される JDBC ドライバーのみが、ドメインモードで管理コンソールを使用してデータソースを作成する時に検出可能です。

手順6.6 管理 CLI または管理コンソールのいずれかを使用したデータソースの作成

    • 管理 CLI

      1. CLI ツールを起動し、サーバーに接続します。
      2. 以下の管理 CLI コマンドを実行して非 XA データソースを作成し、適切に変数を設定します。
        注記
        DRIVER_NAME の値は、JDBC ドライバー JAR にある /META-INF/services/java.sql.Driver ファイルにリストされているクラスの数によって異なります。クラスが 1 つしかない場合、値は JAR の名前になります。複数のクラスがある場合、値は JAR + driverClassName + "_" + majorVersion +"_" + minorVersion の名前になります。これを実行しないと、以下のエラーがログに記録されます。
        JBAS014775:    New missing/unsatisfied dependencies
        Copy to Clipboard Toggle word wrap
        たとえば、MySQL 5.1.31 ドライバーに必要な DRIVER_NAME 値は mysql-connector-java-5.1.31-bin.jarcom.mysql.jdbc.Driver_5_1 です。
        data-source add --name=DATASOURCE_NAME --jndi-name=JNDI_NAME --driver-name=DRIVER_NAME  --connection-url=CONNECTION_URL
        Copy to Clipboard Toggle word wrap
      3. データソースを有効にします。
        data-source enable --name=DATASOURCE_NAME
        Copy to Clipboard Toggle word wrap
    • 管理コンソール

      1. 管理コンソールへログインします。
      2. 管理コンソールの Datasources パネルに移動します。

        1. コンソールの上部にある Configuration タブを選択します。
        2. ドメインモードの場合は、左上のドロップダウンボックスからプロファイルを選択します。
        3. コンソールの左側にある Subsystems メニューを展開し、Connector メニューを展開します。
        4. コンソールの左側にあるメニューから Datasources を選択します。
      3. 新しいデータソースを作成します。

        1. Datasources パネルの上部にある Add をクリックします。
        2. Create Datasource ウィザードに新しいデータソース属性を入力し、Next ボタンをクリックします。
        3. Create Datasource ウィザードに JDBC ドライバーの詳細を入力し、Next をクリックして続行します。
        4. Create Datasource ウィザードにコネクション設定を入力します。
        5. Test Connection ボタンをクリックしてデータソースへの接続をテストし、設定が正しいことを確認します。
        6. 完了 をクリック て終了します。

結果

非 XA データソースがサーバーに追加されます。これで、standalone.xml ファイルまたは domain.xml ファイル、および管理インターフェースが表示されます。

6.3.2. 管理インターフェースによる非 XA データソースの編集

概要

ここでは、管理コンソールまたは管理 CLI のいずれかを使用して非 XA データソースを編集する手順について取り上げます。

JTA の統合
非 XA データソースは JTA トランザクションと統合できます。データソースを JTA と統合するには、jta パラメーターが true に設定されていることを確認します。

手順6.7 非 XA データソースの編集

    • 管理 CLI

      1. write-attribute コマンドを使用してデータソース属性を設定します。
        /subsystem=datasources/data-source=DATASOURCE_NAME:write-attribute(name=ATTRIBUTE_NAME,value=ATTRIBUTE_VALUE)
        Copy to Clipboard Toggle word wrap
      2. サーバーを再ロードして変更を確認します。
        reload
        Copy to Clipboard Toggle word wrap
    • 管理コンソール

      1. 管理コンソールの Datasources パネルに移動します。

        1. コンソールの上部にある Configuration タブを選択します。
        2. ドメインモードの場合は、左上のドロップダウンボックスからプロファイルを選択します。
        3. コンソールの左側にある Subsystems メニューを展開し、Connector メニューを展開します。
        4. 拡張されたメニューから Datasources を選択します。
      2. データソースを編集します。

        1. Available Datasources リストからデータソースを選択します。データソース属性は以下に表示されます。
        2. Edit をクリックしてデータソース属性を編集します。
        3. Save をクリックして終了します。

結果

非 XA データソースが設定されている。変更が、standalone.xml ファイルまたは domain.xml ファイルのいずれかと管理インターフェースで表示されるようになりました。

6.3.3. 管理インターフェースによる非 XA データソースの削除

概要

ここでは、管理コンソールまたは管理 CLI を使用して、JBoss EAP 6 より非 XA データソースを削除するために必要な手順について説明します。

手順6.8 非 XA データソースの削除

    • 管理 CLI

      1. 次のコマンドを実行して非 XA データソースを削除します。
        data-source remove --name=DATASOURCE_NAME
        Copy to Clipboard Toggle word wrap
    • 管理コンソール

      1. 管理コンソールの Datasources パネルに移動します。

        1. コンソールの上部にある Configuration タブを選択します。
        2. ドメインモードの場合は、左上のドロップダウンボックスからプロファイルを選択します。
        3. コンソールの左側にある Subsystems メニューを展開し、Connector メニューを展開します。
        4. Datasources を選択します。
      2. 削除 するデータソースを選択し、Remove をクリックします。

結果

非 XA データソースがサーバーより削除されます。

6.4. XA データソース

6.4.1. 管理インターフェースによる XA データソースの作成

概要

ここでは、管理コンソールまたは管理 CLI のいずれかを使用して XA データソースを作成する手順について取り上げます。

Oracle のデータソース
バージョン 10.2 以前の Oracle データソースでは、トランザクション以外の接続とトランザクション接続が混在するとエラーが発生するため、<no-tx-separate-pools/> パラメーターが必要でした。特定のアプリケーションでこのパラメーターが不要になる場合があります。

手順6.9 管理 CLI または管理コンソールのいずれかを使用した XA データソースの作成

    • 管理 CLI

      1. 以下の管理 CLI コマンドを実行して XA データソースを作成し、適切に変数を設定します。
        注記
        DRIVER_NAME の値は、JDBC ドライバー JAR にある /META-INF/services/java.sql.Driver ファイルにリストされているクラスの数によって異なります。クラスが 1 つしかない場合、値は JAR の名前になります。複数のクラスがある場合、値は JAR + driverClassName + "_" + majorVersion +"_" + minorVersion の名前になります。これを実行しないと、以下のエラーがログに記録されます。
        JBAS014775:    New missing/unsatisfied dependencies
        Copy to Clipboard Toggle word wrap
        たとえば、MySQL 5.1.31 ドライバーに必要な DRIVER_NAME 値は mysql-connector-java-5.1.31-bin.jarcom.mysql.jdbc.Driver_5_1 です。
        xa-data-source add --name=XA_DATASOURCE_NAME --jndi-name=JNDI_NAME --driver-name=DRIVER_NAME --xa-datasource-class=XA_DATASOURCE_CLASS
        Copy to Clipboard Toggle word wrap
      2. XA データソースプロパティーの設定

        1. サーバー名の設定

          次のコマンドを実行し、ホストのサーバー名を設定します。
          /subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME/xa-datasource-properties=ServerName:add(value=HOSTNAME)
          Copy to Clipboard Toggle word wrap
        2. データベース名の設定

          次のコマンドを実行し、データベース名を設定します。
          /subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME/xa-datasource-properties=DatabaseName:add(value=DATABASE_NAME)
          Copy to Clipboard Toggle word wrap
      3. データソースを有効にします。
        xa-data-source enable --name=XA_DATASOURCE_NAME
        Copy to Clipboard Toggle word wrap
    • 管理コンソール

      1. 管理コンソールの Datasources パネルに移動します。

        1. コンソールの上部にある Configuration タブを選択します。
        2. ドメインモードの場合は、左上のドロップダウンボックスからプロファイルを選択します。
        3. コンソールの左側にある Subsystems メニューを展開し、Connector メニューを展開します。
        4. Datasources を選択します。
      2. XA Datasource タブを選択します。
      3. 新しい XA データソースを作成します。

        1. Add をクリックします。
        2. Create XA Datasource ウィザードで新しい XA データソース属性を入力し、Next をクリックします。
        3. Create XA Datasource ウィザードに JDBC ドライバーの詳細を入力し、Next をクリックします。
        4. XA プロパティーを入力し、Next をクリックします。
        5. Create XA Datasource ウィザードで接続設定を入力します。
        6. テスト接続 ボタンをクリックして XA データソースへの接続をテストし、設定が正しいことを確認します。
        7. 完了 をクリック て終了します。

結果

XA データソースがサーバーに追加されている。これで、standalone.xml ファイルまたは domain.xml ファイル、および管理インターフェースが表示されます。

6.4.2. 管理インターフェースによる XA データソースの編集

概要

ここでは、管理コンソールまたは管理 CLI のいずれかを使用して XA データソースを編集する手順について取り上げます。

手順6.10 管理 CLI または管理コンソールのいずれかを使用した XA データソースの編集

    • 管理 CLI

      1. XA データソース属性の設定

        write-attribute コマンドを使用してデータソース属性を設定します。
        /subsystem=datasources/xa-data-source=XA_DATASOURCE_NAME:write-attribute(name=ATTRIBUTE_NAME,value=ATTRIBUTE_VALUE)
        Copy to Clipboard Toggle word wrap
      2. XA データソースプロパティーの設定

        次のコマンドを実行して XA データソースサブリソースを設定します。
        /subsystem=datasources/xa-data-source=DATASOURCE_NAME/xa-datasource-properties=PROPERTY_NAME:add(value=PROPERTY_VALUE)
        Copy to Clipboard Toggle word wrap
      3. サーバーを再ロードして変更を確認します。
        reload
        Copy to Clipboard Toggle word wrap
    • 管理コンソール

      1. 管理コンソールの Datasources パネルに移動します。

        1. コンソールの上部にある Configuration タブを選択します。
        2. ドメインモードの場合は、左上のドロップダウンボックスからプロファイルを選択します。
        3. コンソールの左側にある Subsystems メニューを展開し、Connector メニューを展開します。
        4. Datasources を選択します。
      2. XA Datasource タブを選択します。
      3. データソースを編集します。

        1. Available XA Datasources リストから関連する XA データソースを選択します。XA データソース属性は、その下の Attributes パネルに表示されます。
        2. Edit ボタンを選択してデータソース属性を編集します。
        3. XA データソース属性を編集し、作業が完了したら Save ボタンを選択します。

結果

XA データソースが設定されている。変更が、standalone.xml ファイルまたは domain.xml ファイルのいずれかと管理インターフェースで表示されるようになりました。

6.4.3. 管理インターフェースによる XA データソースの削除

概要

ここでは、管理コンソールまたは管理 CLI を使用して、JBoss EAP 6 から XA データソースを削除するために必要な手順について説明します。

手順6.11 管理 CLI または管理コンソールのいずれかを使用した XA データソースの削除

    • 管理 CLI

      1. 次のコマンドを実行して XA データソースを削除します。
        xa-data-source remove --name=XA_DATASOURCE_NAME
        Copy to Clipboard Toggle word wrap
    • 管理コンソール

      1. 管理コンソールの Datasources パネルに移動します。

        1. コンソールの上部にある Configuration タブを選択します。
        2. ドメインモードの場合は、左上のドロップダウンボックスからプロファイルを選択します。
        3. コンソールの左側にある Subsystems メニューを展開し、Connector メニューを展開します。
        4. Datasources を選択します。
      2. XA Datasource タブを選択します。
      3. 削除する登録済みの XA データソースを選択し、Remove をクリックして XA データソースを永続的に 削除 します。

結果

XA データソースがサーバーより削除されます。

6.4.4. XA リカバリー

6.4.4.1. XA リカバリーモジュール
各 XA リソースにはその設定に関連付けられたリカバリーモジュールが必要です。リカバリーモジュールはクラス com.arjuna.ats.jta.recovery.XAResourceRecovery を拡張する必要があります。
JBoss EAP 6 は、JDBC および JMS XA リソースのリカバリーモジュールを提供します。このようなタイプのリソースでは、リカバリーモジュールは自動的に登録されます。カスタムモジュールを使用する必要がある場合は、データソースに登録できます。
6.4.4.2. XA リカバリーモジュールの設定
ほとんどの JDBC および JMS リソースでは、リカバリーモジュールはリソースに自動的に関連付けられます。この場合は、リカバリーモジュールがリソースに接続してリカバリーを実行することを許可するオプションのみを設定する必要があります。
JDBC または JMS でないカスタムリソースの場合は、サポートされる設定について Red Hat グローバルサポートサービスにお問い合わせください。
これらの設定属性はデータソースの作成時または作成後に設定できます。Web ベースの管理コンソールまたはコマンドライン管理 CLI を使用して設定できます。XA データソースの設定に関する一般的な情報は、「管理インターフェースによる XA データソースの作成」 および 「管理インターフェースによる XA データソースの編集」 を参照してください。
一般的なデータソース設定属性と、特定のデータベースベンダーに関連する設定詳細については、以下の表を参照してください。
Expand
表6.2 一般的な設定属性
属性 説明
recovery-username
リソースに接続してリカバリー行うためにリカバリーモジュールが使用する必要があるユーザー名。
recovery-password
リソースに接続してリカバリーを行うためにリカバリーモジュールが使用する必要があるパスワード。
recovery-security-domain
リカバリーを行う目的でリカバリーモジュールがリソースに接続するために使用するセキュリティードメイン。
recovery-plugin-class-name
カスタムのリカバリーモジュールを使用する必要がある場合は、この属性をモジュールの完全修飾クラス名に設定します。モジュールはクラス com.arjuna.ats.jta.recovery.XAResourceRecovery を拡張する必要があります。
recovery-plugin-properties
プロパティーを設定する必要があるカスタムのリカバリーモジュールを使用する場合は、この属性をプロパティーのコンマ区切りの key=value ペアのリストに設定します。
注記
表6.2「一般的な設定属性」 で使用される名前は、データソースが CLI で設定されている場合に使用されるパラメーターです。XML 設定ファイルで使用される名前とは異なる場合があります。

ベンダー固有の設定情報

ここでは、特定のデータベースが JBoss EAP トランザクションマネージャーによって管理される XA トランザクションで連携するのに必要な特定の設定について説明します。詳細は、特定のデータベースのドキュメントを参照してください。
Oracle
Oracle データソースが不適切に設定された場合は、ログ出力に次のようなエラーが示されることがあります。

例6.11 誤った設定エラー

WARN  [com.arjuna.ats.jta.logging.loggerI18N] [com.arjuna.ats.internal.jta.recovery.xarecovery1] Local XARecoveryModule.xaRecovery  got XA exception javax.transaction.xa.XAException, XAException.XAER_RMERR
Copy to Clipboard Toggle word wrap
このエラーを解決するには、recovery-username で設定した Oracle ユーザーがリカバリーに必要なテーブルにアクセスできるようにします。以下の SQL ステートメントは、Oracle バグ 5945463 にパッチが適用された Oracle 11g または Oracle 10g R2 インスタンスに対する適切な付与を示しています。

例6.12 付与の設定

GRANT SELECT ON sys.dba_pending_transactions TO recovery-username;
GRANT SELECT ON sys.pending_trans$ TO recovery-username;
GRANT SELECT ON sys.dba_2pc_pending TO recovery-username;
GRANT EXECUTE ON sys.dbms_xa TO recovery-username;
Copy to Clipboard Toggle word wrap
11g より前の Oracle 11 バージョンを使用している場合は、最終的な EXECUTE ステートメントを以下のように変更します。
	GRANT EXECUTE ON sys.dbms_system TO recovery-username;
Copy to Clipboard Toggle word wrap
PostgreSQL および Postgres Plus Advanced Server
PostgreSQL が XA トランザクションを処理できるようにするには、設定パラメーター max_prepared_transactions を 0 よりも大きな値に変更します。
MySQL
特別な設定は必要ありません。詳細は MySQL のドキュメントを参照してください。
IBM DB2
特別な設定は必要ありません。詳細は IBM DB2 のドキュメントを参照してください。
Sybase
Sybase は、XA トランザクションがデータベース上で有効であることを想定します。XA トランザクションはデータベース設定が正しくないと動作しません。xact コーディネーションを有効 にすると、Adaptive Server トランザクションコーディネーションサービスを有効または無効にします。このパラメーターを有効にすると、リモート Adaptive Server データのアップデートが、確実に元のトラザクションでコミットまたはロールバックされるようになります。トラザクションコーディネーションを有効にするには、以下を使用します。
sp_configure 'enable xact coordination', 1
Copy to Clipboard Toggle word wrap
.
MSSQL
詳細は Microsoft ドキュメントを参照してください。また、開始点として参照 http://msdn.microsoft.com/en-us/library/aa342335.aspx することもできます。

ベンダー固有の問題とその結果

ここでは、XA トランザクションの処理に現在既知のデータベース固有の問題を説明します。これらの問題は、特定の EAP バージョンで現在対応しているデータベースバージョンおよび jdbc ドライバーを指します。
Oracle
データベースに関連する既知の問題はありません。
PostgreSQL
  • コミットメソッドプロトコルの呼び出し中にエラーが発生した場合、JDBC ドライバーは XAER_RMERR を返します。データベースはこのエラーコードを返し、トランザクションをデータベース側 でインダウト 状態のままにします。正しい戻りコードは XAER_RMFAIL または XAER_RETRY である必要があります。詳細はを参照してください https://github.com/pgjdbc/pgjdbc/issues/236。これにより、トランザクションは EAP 側で Heuristic 状態のままになり、データベースでロックが保持されるため、ユーザーの介入が必要になります。
  • jdbc ドライバーによって返される誤ったエラーコードにより、場合によってはデータの不整合が発生する可能性があります。詳細は、を参照して https://developer.jboss.org/thread/251537 ください。 https://github.com/pgjdbc/pgjdbc/issues/236
Postgres Plus Advanced Server
  • コミットメソッドプロトコルの呼び出し中にエラーが発生した場合、JDBC ドライバーは XAER_RMERR を返します。データベースはこのエラーコードを返し、トランザクションをデータベース側 でインダウト 状態のままにします。正しい戻りコードは XAER_RMFAIL または XAER_RETRY である必要があります。詳細はを参照してください https://github.com/pgjdbc/pgjdbc/issues/236。これにより、トランザクションは EAP 側で Heuristic 状態のままになり、データベースでロックが保持されるため、ユーザーの介入が必要になります。
  • jdbc ドライバーによって返される誤ったエラーコードにより、場合によってはデータの不整合が発生する可能性があります。詳細は以下を参照してください。 https://developer.jboss.org/thread/251537
  • 同じ XID に対して XAResource.rollback が呼び出されると、XAException がスローされます。同じ XID に対するロールバックを複数回呼び出しても JTS 仕様に準拠し、XAException はスローされません。詳細はを参照してください https://github.com/pgjdbc/pgjdbc/issues/78
MySQL
MySQL は XA トランザクションを処理できません。クライアントが MySQL を切断されると、このようなトランザクションに関する情報がすべて失われます。詳細はを参照してください http://bugs.mysql.com/bug.php?id=12161
IBM DB2
データベースに関連する既知の問題はありません。
Sybase
  • コミットメソッドプロトコルの呼び出し中にエラーが発生した場合、JDBC ドライバーは XAER_RMERR を返します。データベースはこのエラーコードを返し、トランザクションをデータベース側 でインダウト 状態のままにします。正しい戻りコードは XAER_RMFAIL または XAER_RETRY である必要があります。詳細はを参照してください https://github.com/pgjdbc/pgjdbc/issues/236。これにより、トランザクションは EAP 側で Heuristic 状態のままになり、データベースでロックが保持されるため、ユーザーの介入が必要になります。
  • 同じ XID に対して XAResource.rollback が呼び出されると、XAException がスローされます。同じ XID に対するロールバックを複数回呼び出しても JTS 仕様に準拠し、XAException はスローされません。詳細はを参照してください https://github.com/pgjdbc/pgjdbc/issues/78
MSSQL
  • コミットメソッドプロトコルの呼び出し中にエラーが発生した場合、JDBC ドライバーは XAER_RMERR を返します。データベースはこのエラーコードを返し、トランザクションをデータベース側 でインダウト 状態のままにします。正しい戻りコードは XAER_RMFAIL または XAER_RETRY である必要があります。詳細はを参照してください https://github.com/pgjdbc/pgjdbc/issues/236。これにより、トランザクションは EAP 側で Heuristic 状態のままになり、データベースでロックが保持されるため、ユーザーの介入が必要になります。
  • 同じ XID に対して XAResource.rollback が呼び出されると、XAException がスローされます。同じ XID に対するロールバックを複数回呼び出しても JTS 仕様に準拠し、XAException はスローされません。詳細はを参照してください https://github.com/pgjdbc/pgjdbc/issues/78
  • 同じ XID の XAResource.rollback の呼び出しにより、サーバーログファイルに以下のメッセージが記録されます。
    WARN [com.arjuna.ats.jtax] ...: XAResourceRecord.rollback caused an error from resource ... in transaction ...: java.lang.NullPointerException
    Copy to Clipboard Toggle word wrap
Messaging

IBM Web Warehouse

  • JTS を使用する場合、定期的なリカバリー時に同じ XID に対するロールバックの 2 回目の呼び出しにより、エラーがログファイルに記録される可能性があります。同じ XID に対する 2 回目のロールバックは JTS の構成であり、無視できます。
    RAR がこのような XID が分からない場合は、XAER_NOTA の戻りコードが予想されます。ただし、IBM Web Warehouse は誤った戻りコード XAER_RMFAIL を返す可能性があります。
    The method 'xa_rollback' has failed with errorCode '-7' due to the resource being closed.'
    Copy to Clipboard Toggle word wrap

ActiveMQ

  • コミットメソッドプロトコルの呼び出し中にエラーが発生した場合(ネットワークの切断など)は、XAER_RMERR を返します。リソースアダプターはこのエラーコードをトランザクションマネージャーに戻し、メッセージブローカー側でトランザクションが インダウト 状態のままになります。この動作は XA 仕様に対して行われ、正しい戻りコードは XAER_RMFAIL または XAER_RETRY である必要があります。誤ったエラーコードにより、場合によってはデータの不整合が発生する可能性があります。詳細は、を参照して https://developer.jboss.org/thread/251537 ください。
    WARN [com.arjuna.ats.jtax] ...: XAResourceRecord.rollback caused an XA error: ARJUNA016099: Unknown error code:0 from resource ...  in transaction ...: javax.transaction.xa.XAException: Transaction ...  has not been started.
    Copy to Clipboard Toggle word wrap

TIBCO

  • JTS を使用する場合、定期的なリカバリー時に同じ XID に対するロールバックの 2 回目の呼び出しにより、エラーがログファイルに記録される可能性があります。同じ XID に対する 2 回目のロールバックは JTS の構成であり、無視できます。
    WARN [com.arjuna.ats.jtax] ...: XAResourceRecord.rollback caused an XA error: XAException.XAER_RMFAIL from resource ... in transaction ...: javax.transaction.xa.XAException
    Copy to Clipboard Toggle word wrap

6.5. データソースセキュリティー

6.5.1. データソースセキュリティー

データソースセキュリティーとは、データソース接続のパスワードを暗号化したり分かりにくくすることを言います。これらのパスワードはプレーンテキストで設定ファイルに保存できますが、セキュリティーリスクが高くなります。
データソースセキュリティーの推奨ソリューションは、セキュリティードメインまたはパスワード vault を使用することです。以下には、各メソッドの例が含まれています。詳細は、セキュリティー 『アーキテクチャー』 およびその他の JBoss EAP セキュリティードキュメントを参照してください。

例6.13 セキュリティードメインの例

 <security-domain name="DsRealm" cache-type="default">  
  <authentication>  
    <login-module code="ConfiguredIdentity" flag="required">  
      <module-option name="userName" value="sa"/>  
      <module-option name="principal" value="sa"/>  
      <module-option name="password" value="sa"/>  
    </login-module>  
  </authentication>  
</security-domain>
Copy to Clipboard Toggle word wrap
DsRealm ドメインはデータソースによって参照されます。
<datasources>
  <datasource jndi-name="java:jboss/datasources/securityDs"
    pool-name="securityDs">
    <connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url>
      <driver>h2</driver>
      <new-connection-sql>select current_user()</new-connection-sql>
      <security>
        <security-domain>DsRealm</security-domain>
      </security>
    </datasource>
</datasources>
Copy to Clipboard Toggle word wrap
注記
セキュリティードメインが複数のデータソースと使用される場合は、セキュリティードメインでキャッシュを無効にする必要があります。これは、cache-type 属性の値を none に設定するか、この属性を削除します。ただし、キャッシュが必要な場合は、各データソースに個別のセキュリティードメインを使用する必要があります。

例6.14 パスワード vault の例

<security>
  <user-name>admin</user-name>
  <password>${VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0}</password>
</security>
Copy to Clipboard Toggle word wrap

6.6. データベース接続の検証

6.6.1. データベース接続検証設定の指定

概要

データベースのメンテナンス、ネットワークの問題、またはその他の障害により、JBoss EAP 6 がデータベースへの接続を失うことがあります。データベース接続の検証は、サーバー設定ファイルの &lt ; datasource> セクション内の <validation &gt; 要素を使用して有効にします。以下の手順に従ってデータソースを設定し、JBoss EAP 6 でデータベース接続検証を有効にします。

手順6.12 データベース接続検証設定の指定

  1. 検証方法の選択

    以下のいずれかの検証方法を選択します。
    • <validate-on-match>true</validate-on-match>

      < validate-on-match > オプションを true に設定すると、次の手順で指定された検証メカニズムを使用して接続プールからチェックアウトされるたびにデータベース接続が検証されます。
      接続が有効でない場合は、警告がログに書き込まれ、プール内の次の接続が取得されます。このプロセスは、有効な接続が見つかるまで続行します。プール内の各接続を繰り返し処理しない場合は、< use-fast-fail > オプションを使用できます。有効な接続がプールにない場合は、新しい接続が作成されます。接続の作成に失敗すると、例外が要求元アプリケーションに返されます。
      この設定により、最も早いリカバリーが実現されますが、データベースへの負荷が最も大きくなります。ただし、これは、パフォーマンスを気にする必要がない場合は最も安全な方法です。
    • <background-validation>true</background-validation>

      < background-validation > オプションを true に設定すると、< background-validation-millis > 値と組み合わせて、バックグラウンド検証が実行される頻度を決定します。< background-validation-millis > パラメーターのデフォルト値は 0 ミリ秒で、デフォルトでは無効になっています。この値は、< idle-timeout-minutes> 設定と同じ値に設定しないで ください。
      特定のシステムのoptum < background-validation-millis > 値を決定するためのバランス動作です。値が小さいほどプールの検証頻度が高くなり、より迅速に無効な接続がプールから削除されます。ただし、値が小さいほどデータベースリソースが多くなります。値が大きいほど接続検証チェックの頻度が低くなり、データベースリソースの使用量が減りますが、無効な接続が検出されない期間が長くなります。
    注記
    < validate-on-match > オプションを true に設定すると、< background-validation> オプションfalse に設定する必要があります。その逆も同様です。< background-validation> オプションtrue に設定すると、< validate-on-match> オプションfalse に設定する必要があります。
  2. 検証メカニズムの選択

    以下のいずれかの検証メカニズムを選択します。
    • <valid-connection-checker> クラス名の指定

      これは、使用中の特定の pid に対して最適化されているため、推奨されるメカニズムです。JBoss EAP 6 は以下の接続チェッカーを提供します。
      • org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker
      • org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker
      • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLReplicationValidConnectionChecker
      • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker
      • org.jboss.jca.adapters.jdbc.extensions.novendor.JDBC4ValidConnectionChecker
      • org.jboss.jca.adapters.jdbc.extensions.novendor.NullValidConnectionChecker
      • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker
      • org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker
      • org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker
    • <check-valid-connection-sql> の SQL の指定

      接続を検証するために使用する SQL ステートメントを提供します。
      以下は、Oracle 用接続を検証するために SQL ステートメントをどのように指定するかの例です。
      <check-valid-connection-sql>select 1 from dual</check-valid-connection-sql>
      Copy to Clipboard Toggle word wrap
      MySQL または PostgreSQL の場合は、以下の SQL ステートメントを指定する必要があります。
      <check-valid-connection-sql>select 1</check-valid-connection-sql>
      Copy to Clipboard Toggle word wrap
  3. クラス名の <exception-sorter> 設定

    例外が致命的とマークされた場合、接続はトランザクションに参加していてもすぐに閉じられます。致命的な接続例外を適切に検出およびクリーンアップするには、例外ソータークラスオプションを使用します。JBoss EAP 6 は以下の例外ソーターを提供します。
    • org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter
    • org.jboss.jca.adapters.jdbc.extensions.informix.InformixExceptionSorter
    • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter
    • org.jboss.jca.adapters.jdbc.extensions.novendor.NullExceptionSorter
    • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter
    • org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter
    • org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter
    • org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLExceptionSorter

6.7. データソース設定

6.7.1. データソースのパラメーター

Expand
表6.3 非 XA および XA データソースに共通のデータソースパラメーター
パラメーター 説明
jndi-name データソースの一意の JNDI 名。
pool-name データソースの管理プール名。
enabled データソースが有効かどうかを指定します。
use-java-context
データソースをグローバルの JNDI にバインドするかどうかを指定します。
spy
JDBC レイヤーで スパイ 機能を有効にします。この機能は、データソースへの JDBC トラフィックをすべてログに記録します。ロギングカテゴリー jboss.jdbc.spy も logging サブシステムのログレベル DEBUG に設定する必要があることに注意してください。
use-ccm キャッシュ接続マネージャーを有効にします。
new-connection-sql 接続プールに接続が追加された時に実行する SQL ステートメント。
transaction-isolation
次のいずれかになります。
  • TRANSACTION_READ_UNCOMMITTED
  • TRANSACTION_READ_COMMITTED
  • TRANSACTION_REPEATABLE_READ
  • TRANSACTION_SERIALIZABLE
  • TRANSACTION_NONE
url-selector-strategy-class-name インターフェース org.jboss.jca.adapters.jdbc.URLSelectorStrategy を実装するクラス。
security
セキュリティー設定である子要素が含まれます。表6.8「セキュリティーパラメーター」を参照してください。
検証
検証設定である子要素が含まれます。表6.9「検証パラメーター」を参照してください。
timeout
タイムアウト設定である子要素が含まれます。表6.10「タイムアウトパラメーター」を参照してください。
statement
ステートメント設定である子要素が含まれます。表6.11「ステートメントのパラメーター」を参照してください。
Expand
表6.4 非 XA データソースのパラメーター
パラメーター 説明
jta 非 XA データソースの JTA 統合を有効にします。XA データソースには適用されません。
connection-url JDBC ドライバーの接続 URL。
driver-class JDBC ドライバークラスの完全修飾名。
connection-property
メソッド Driver.connect(url,props) に渡される任意の接続プロパティー。各 connection-property は、文字列名と値のペアを指定します。プロパティー名は名前から取得され、値は要素のコンテンツから取得されます。
pool
プーリング設定である子要素が含まれます。表6.6「非 XA および XA データソースに共通のプールパラメーター」を参照してください。
url-delimiter
高可用性 (HA) クラスター化されたデータベースの connection-url にある URL の区切り文字。 
Expand
表6.5 XA データソースのパラメーター
パラメーター 説明
xa-datasource-property
実装クラス XADataSource に割り当てるプロパティー。name=value で指定します。setter メソッドが存在する場合は、setName の形式で、setName(value) の形式で setter メソッドを呼び出すことでプロパティーが設定されます。
xa-datasource-class
実装クラス javax.sql.XADataSource の完全修飾名。
driver
JDBC ドライバーが含まれるクラスローダーモジュールへの一意な参照。使用できる形式は driverName#majorVersion.minorVersion です。
xa-pool
プーリング設定である子要素が含まれます。表6.6「非 XA および XA データソースに共通のプールパラメーター」 および 表6.7「XA プールパラメーター」 を参照してください。
recovery
リカバリー設定である子要素が含まれます。表6.12「リカバリーパラメーター」を参照してください。
Expand
表6.6 非 XA および XA データソースに共通のプールパラメーター
パラメーター 説明
min-pool-size プールが保持する最小接続数
max-pool-size プールが保持可能な最大接続数
prefill 接続プールのプレフィルを試行するかどうか。デフォルトは false です。
use-strict-min min-pool-size に達すると、アイドル接続スキャンが、追加の接続を明確化するために厳密に停止するかどうか。デフォルト値は false です。
flush-strategy
エラーの場合にプールがフラッシュされるかどうか。有効な値は以下のとおりです。
  • FailingConnectionOnly
  • IdleConnections
  • EntirePool
デフォルトは FailingConnectionOnly です。
allow-multiple-users 複数のユーザーが getConnection(user, password) メソッドを使いデータソースへアクセスするかどうか、および内部プールタイプがこの動作に対応するかを指定します。
Expand
表6.7 XA プールパラメーター
パラメーター 説明
is-same-rm-override javax.transaction.xa.XAResource.isSameRM(XAResource) クラスが true または false を返すかどうか。
interleaving XA 接続ファクトリーのインターリービングを有効にするかどうかを指定します。
no-tx-separate-pools
コンテキストごとに個別のサブプールを作成するかどうか。これは、JTA トランザクションの内部と外部の両方で XA 接続を使用できない Oracle データソースに必要です。
このオプションを使用すると、実際のプールが 2 つ作成されるため、合計プールサイズが max-pool-size の 2 倍になります。
pad-xid Xid のパディングを行うかどうかを指定します。
wrap-xa-resource
XAResource を org.jboss.tm.XAResourceWrapper インスタンスでラップするかどうか。
Expand
表6.8 セキュリティーパラメーター
パラメーター 説明
user-name 新規接続の作成に使うユーザー名
password 新規接続の作成に使うパスワード
security-domain 認証を処理する JAAS security-manager の名前が含まれます。この名前は、JAAS ログイン設定の application-policy/name 属性に相関します。
reauth-plugin 物理接続の再認証に使う再認証プラグインを定義します。
Expand
表6.9 検証パラメーター
パラメーター 説明
valid-connection-checker
接続を検証する org.jboss.jca.adaptors.jdbc.ValidConnectionChecker メソッドを提供するインターフェース SQLException.isValidConnection(Connection e) の実装。接続が破棄されると例外が発生します。これにより、パラメーター check-valid-connection-sql が上書きされます(存在する場合)。
check-valid-connection-sql プール接続の妥当性を確認する SQL ステートメント。これは、管理接続がプールから取得されたときに呼び出される場合があります。
validate-on-match
接続ファクトリーが指定のセットに対して管理された接続に一致させようとした時に接続レベルの検証を実行するかどうかを示します。
validate-on-match に「true」を指定することは、通常 background-validation に「true」を指定するとともには実行されません。使用前にクライアントが接続を検証する必要がある場合に、validate -on-match が必要です。このパラメーターはデフォルトで false です。
background-validation
接続がバックグラウンドスレッドで検証されることを指定します。バックグラウンド検証は、validate-on-match とともに使用されていない場合のパフォーマンスの最適化です。validate-on-match が true の場合、background-validation を使用すると冗長チェックが生じる可能性があります。バックグラウンド検証では、使用のために不適切な接続がクライアントに付与される可能性が開かれます(検証スキャンにかかる時間とクライアントに渡す前に接続が悪い場合)、クライアントアプリケーションはこの可能性に対応する必要があります。
background-validation-millis バックグラウンド検証を実行する期間 (ミリ秒単位)。
use-fast-fail
true の場合、接続が無効であれば最初の試行で接続の割り当てに失敗します。デフォルトは false です。
stale-connection-checker
ブール値の org.jboss.jca.adapters.jdbc.StaleConnectionChecker メソッドを提供する isStaleConnection(SQLException e) のインスタンス。このメソッドが true を返すと、例外は org.jboss.jca.adapters.jdbc.StaleConnectionException のサブクラスである SQLException でラップされます。
exception-sorter
ブール値の org.jboss.jca.adapters.jdbc.ExceptionSorter メソッドを提供する isExceptionFatal(SQLException e) のインスタンス。このメソッドは、例外が connectionErrorOccurred メッセージとして javax.resource.spi.ConnectionEventListener のすべてのインスタンスにブロードキャストされているかどうかを確認します。
Expand
表6.10 タイムアウトパラメーター
パラメーター 説明
use-try-lock tryLock() の代わりに lock() を使用します。ロックが使用できない場合に即座に失敗するのではなく、タイムアウトする前に設定された秒数間ロックの取得を試みます。デフォルトは 60 秒です。たとえば、タイムアウトを 5 分に設定するには、<use-try-lock>300</use-try-lock> を設定します。
blocking-timeout-millis 接続の待機中にブロックする最大時間(ミリ秒単位)。この時間を過ぎると、例外が発生します。このブロックは、接続許可の待機中にのみブロックし、新規接続の作成に長時間要している場合は例外は発生しません。デフォルトは 30000(30 秒)です。
idle-timeout-minutes
アイドル接続が切断されるまでの最大時間(分単位)。指定がない場合、デフォルトは 30 分になります。実際の最大時間は、idleRemover スキャン時間によって異なります。これは、プールの最小 idle-timeout-minutes の半分です。
set-tx-query-timeout
トランザクションがタイムアウトするまでの残り時間を基にクエリーのタイムアウトを設定するかどうかを指定します。トランザクションが存在しない場合は設定済みのクエリーのタイムアウトが使用されます。デフォルトは false です。
query-timeout クエリーのタイムアウト(秒単位)。デフォルトではタイムアウトはありません。
allocation-retry 例外を発生させる前に接続の割り当てを再試行する回数。デフォルトは 0 で、初回の割り当て失敗で例外が発生します。
allocation-retry-wait-millis
接続の割り当てを再試行するまで待機する時間(ミリ秒単位)。デフォルトは 5000(5 秒)です。
xa-resource-timeout
ゼロ以外の値はメソッド XAResource.setTransactionTimeout に渡されます。
Expand
表6.11 ステートメントのパラメーター
パラメーター 説明
track-statements
接続がプールへ返され、ステートメントが準備済みステートメントキャッシュへ返された時に、閉じられていないステートメントをチェックするかどうか。false の場合、ステートメントは追跡されません。
  • True: ステートメントと結果セットが追跡され、ステートメントが閉じられていない場合は警告が出力されます。
  • false: ステートメントと結果セットはいずれも追跡されません。
  • nowarn: ステートメントは追跡されますが、警告は出力されません。これがデフォルトです。
prepared-statement-cache-size LRU (Least Recently Used) キャッシュにある接続毎の準備済みステートメントの数。
share-prepared-statements
アプリケーションに提供されたラッパーがアプリケーションコードによって閉じられたときに、JBoss EAP が基盤の物理ステートメントを閉じたり終了せずに、キャッシュするかどうか。デフォルトは false です。
Expand
表6.12 リカバリーパラメーター
パラメーター 説明
recover-credential リカバリーに使用するユーザー名とパスワードのペア、あるいはセキュリティードメイン。
recover-plugin
リカバリーに使用される org.jboss.jca.core.spi.recoveryRecoveryPlugin クラスの実装。

6.7.2. データソース接続 URL

Expand
表6.13 データソース接続 URL
データソース 接続 URL
PostgreSQL jdbc:postgresql://SERVER_NAME:PORT/DATABASE_NAME
MySQL jdbc:mysql://SERVER_NAME:PORT/DATABASE_NAME
Oracle jdbc:oracle:thin:@ORACLE_HOST:PORT:ORACLE_SID
IBM DB2 jdbc:db2://SERVER_NAME:PORT/DATABASE_NAME
Microsoft SQLServer jdbc:sqlserver://SERVER_NAME:PORT;DatabaseName=DATABASE_NAME
注記
jdbc:microsoft:sqlserver://SERVER_NAME:PORT;DatabaseName=DATABASE_NAME テンプレートは、新しいデータベースでは機能しません。

6.7.3. データソースの拡張

データソースデプロイメントでは、JDBC リソースアダプターの複数の拡張機能を使用して接続の検証を改善し、例外が接続を再確立すべきかどうかを確認できます。これらの拡張機能は、以下のとおりです。
Expand
表6.14 データソースの拡張
データソースの拡張 設定パラメーター 説明
org.jboss.jca.adapters.jdbc.spi.ExceptionSorter <exception-sorter> SQLException が発生した接続にとってこの例外は致命的かどうかを確認します。
org.jboss.jca.adapters.jdbc.spi.StaleConnectionChecker <stale-connection-checker> 古くなった SQLExceptions をラップします。 org.jboss.jca.adapters.jdbc.StaleConnectionException
org.jboss.jca.adapters.jdbc.spi.ValidConnection <valid-connection-checker> アプリケーションによる接続の使用が有効であるかどうかを確認します。
JBoss EAP 6 は、これらの拡張の実装を、サポートされるいくつかのデータベース用に提供します。

拡張の実装

汎用
  • org.jboss.jca.adapters.jdbc.extensions.novendor.NullExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.novendor.NullStaleConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.novendor.NullValidConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.novendor.JDBC4ValidConnectionChecker
PostgreSQL
  • org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker
MySQL
  • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLReplicationValidConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker
IBM DB2
  • org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.db2.DB2StaleConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker
Sybase
  • org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker
Microsoft SQLServer
  • org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker
Oracle
  • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter
  • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleStaleConnectionChecker
  • org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker

6.7.4. データソース統計の表示

以下のコマンドが適切に変更されたバージョンを使用すると、jdbcpool の両方の定義されたデータソースから統計を表示できます。

例6.15 ドメインモードの場合の CLI:

環境に応じて /host=master/server=server-one および data-source=ExampleDS を変更します。
[domain@localhost:9999 /]  /host=master/server=server-one/subsystem=datasources/data-source=ExampleDS/statistics=pool:read-resource(include-runtime=true)
{
    "outcome" => "success",
    "result" => {
        "ActiveCount" => "0",
        "AvailableCount" => "20",
        "AverageBlockingTime" => "0",
        "AverageCreationTime" => "0",
        "CreatedCount" => "0",
        "DestroyedCount" => "0",
        "MaxCreationTime" => "0",
        "MaxUsedCount" => "0",
        "MaxWaitTime" => "0",
        "TimedOut" => "0",
        "TotalBlockingTime" => "0",
        "TotalCreationTime" => "0"
    }
}


Copy to Clipboard Toggle word wrap

例6.16 スタンドアロンモードの CLI:

環境に応じて data-source=ExampleDS を変更します。
[standalone@localhost:9999 /]  /subsystem=datasources/data-source=ExampleDS/statistics=pool:read-resource(include-runtime=true)
{
    "outcome" => "success",
    "result" => {
        "ActiveCount" => "0",
        "AvailableCount" => "20",
        "AverageBlockingTime" => "0",
        "AverageCreationTime" => "0",
        "CreatedCount" => "0",
        "DestroyedCount" => "0",
        "MaxCreationTime" => "0",
        "MaxUsedCount" => "0",
        "MaxWaitTime" => "0",
        "TimedOut" => "0",
        "TotalBlockingTime" => "0",
        "TotalCreationTime" => "0"
    }
}
Copy to Clipboard Toggle word wrap
注記
統計はすべてランタイムのみの情報で、デフォルトは false であるため、必ず include-runtime=true 引数を指定してください。

6.7.5. データソースの統計

主要統計

サポートされるデータソースの主要統計は下表のとおりです。

Expand
表6.15 主要統計
名前 説明
ActiveCount
アクティブな接続の数。各接続はアプリケーションによって使用されているか、プールで使用可能な状態であるかのいずれかになります。
AvailableCount
プールの使用可能な接続の数。
AverageBlockingTime
プールの排他ロックの取得をブロックするために費やされた平均時間。値はミリ秒単位です。
AverageCreationTime
接続の作成に費やされた平均時間。値はミリ秒単位です。
CreatedCount
作成された接続の数。
DestroyedCount
破棄された接続の数。
InUseCount
現在使用中の接続の数。
MaxCreationTime
接続の作成にかかった最大時間。値はミリ秒単位です。
MaxUsedCount
使用される接続の最大数。
MaxWaitCount
同時に接続を待機する要求の最大数。
MaxWaitTime
プールの排他ロックの待機に費やされた最大時間。
TimedOut
タイムアウトした接続の数。
TotalBlockingTime
プールの排他ロックの待機に費やされた合計時間。値はミリ秒単位です。
TotalCreationTime
接続の作成に費やされた合計時間。値はミリ秒単位です。

JDBC の統計

サポートされるデータソースの JDBC 統計は下表のとおりです。

Expand
表6.16 JDBC の統計
名前 説明
PreparedStatementCacheAccessCount
ステートメントキャッシュがアクセスされた回数。
PreparedStatementCacheAddCount
ステートメントキャッシュに追加されたステートメントの数。
PreparedStatementCacheCurrentSize
ステートメントキャッシュに現在キャッシュされた準備済みおよび呼び出し可能ステートメントの数。
PreparedStatementCacheDeleteCount
キャッシュから破棄されたステートメントの数。
PreparedStatementCacheHitCount
キャッシュからのステートメントが使用された回数。
PreparedStatementCacheMissCount
ステートメント要求がキャッシュのステートメントと一致しなかった回数。
以下のコマンドの適切に変更されたバージョンを使用すると、コア および JDBC の統計を有効にできます。
  • /subsystem=datasources/data-source=ExampleDS/statistics=pool:write-attribute(name=statistics-enabled,value=true)
    
    Copy to Clipboard Toggle word wrap
    /subsystem=datasources/data-source=ExampleDS/statistics=jdbc:write-attribute(name=statistics-enabled,value=true)
    
    Copy to Clipboard Toggle word wrap

6.8. データソース例

6.8.1. PostgreSQL データソースの例

PostgreSQL のデータソース設定例は以下のとおりです。データソースが有効になり、ユーザーが追加され、検証オプションが設定されます。

例6.17 PostSQL データソースの設定

<datasources>
  <datasource jndi-name="java:jboss/PostgresDS" pool-name="PostgresDS">
    <connection-url>jdbc:postgresql://localhost:5432/postgresdb</connection-url>
    <driver>postgresql</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
    	<validate-on-match>true</validate-on-match>
      <background-validation>false</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="postgresql" module="org.postgresql">
      <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
Copy to Clipboard Toggle word wrap
上記 PostgreSQL データソースの module.xml ファイルの例は次のとおりです。

例6.18 module.xml

<module xmlns="urn:jboss:module:1.1" name="org.postgresql">
  <resources>
    <resource-root path="postgresql-9.1-902.jdbc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
Copy to Clipboard Toggle word wrap

6.8.2. PostgreSQL XA データソースの例

PostgreSQL XA データソースの設定例は次のとおりです。データソースが有効になり、ユーザーが追加され、検証オプションが設定されます。

例6.19 PostSQL XA datasource

<datasources>
  <xa-datasource jndi-name="java:jboss/PostgresXADS" pool-name="PostgresXADS">
    <driver>postgresql</driver>
    <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
    <xa-datasource-property name="PortNumber">5432</xa-datasource-property>
    <xa-datasource-property name="DatabaseName">postgresdb</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <validate-on-match>true</validate-on-match>
      <background-validation>false</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker">
      </valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter">
      </exception-sorter>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="postgresql" module="org.postgresql">
      <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
Copy to Clipboard Toggle word wrap
上記 PostgreSQL XA データソースの module.xml ファイルの例は次のとおりです。

例6.20 module.xml

<module xmlns="urn:jboss:module:1.1" name="org.postgresql">
  <resources>
    <resource-root path="postgresql-9.1-902.jdbc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
Copy to Clipboard Toggle word wrap

6.8.3. MySQL データソースの例

MySQL データソースの設定例は次のとおりです。データソースが有効になり、ユーザーが追加され、検証オプションが設定されます。

例6.21 MySQL データソースの設定

<datasources>
  <datasource jndi-name="java:jboss/MySqlDS" pool-name="MySqlDS">
    <connection-url>jdbc:mysql://mysql-localhost:3306/jbossdb</connection-url>
    <driver>mysql</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security> 
    <validation>
      <validate-on-match>true</validate-on-match>
      <background-validation>false</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="mysql" module="com.mysql">
      <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
Copy to Clipboard Toggle word wrap
上記 MySQL データソースの module.xml ファイルの例は次のとおりです。

例6.22 module.xml

<module xmlns="urn:jboss:module:1.1" name="com.mysql">
  <resources>
    <resource-root path="mysql-connector-java-5.0.8-bin.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
Copy to Clipboard Toggle word wrap

6.8.4. MySQL XA データソースの例

MySQL XA データソースの設定例は次のとおりです。データソースが有効になり、ユーザーが追加され、検証オプションが設定されます。

例6.23 MySQL XA データソース

<datasources>
  <xa-datasource jndi-name="java:jboss/MysqlXADS" pool-name="MysqlXADS">
  <driver>mysql</driver>
    <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
    <xa-datasource-property name="DatabaseName">mysqldb</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <validate-on-match>true</validate-on-match>
      <background-validation>false</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mysql.MySQLExceptionSorter"></exception-sorter>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="mysql" module="com.mysql">
      <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
Copy to Clipboard Toggle word wrap
上記 MySQL XA データソースの module.xml ファイルの例は次のとおりです。

例6.24 module.xml

<module xmlns="urn:jboss:module:1.1" name="com.mysql">
  <resources>
    <resource-root path="mysql-connector-java-5.0.8-bin.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
Copy to Clipboard Toggle word wrap

6.8.5. Oracle データソースの例

Oracle のデータソース
バージョン 10.2 以前の Oracle データソースでは、トランザクション以外の接続とトランザクション接続が混在するとエラーが発生するため、<no-tx-separate-pools/> パラメーターが必要でした。特定のアプリケーションでこのパラメーターが不要になる場合があります。
Oracle のデータソース設定例は以下のとおりです。データソースが有効になり、ユーザーが追加され、検証オプションが設定されます。

例6.25 Oracle データソースの設定

<datasources>
  <datasource jndi-name="java:/OracleDS" pool-name="OracleDS">
    <connection-url>jdbc:oracle:thin:@localhost:1521:XE</connection-url>
    <driver>oracle</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security> 
    <validation>
      <validate-on-match>true</validate-on-match>
      <background-validation>false</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker"></valid-connection-checker>
      <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleStaleConnectionChecker"></stale-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="oracle" module="com.oracle">
    </driver>
  </drivers>
</datasources>
Copy to Clipboard Toggle word wrap
上記 Oracle データソースの module.xml ファイルの例は次のとおりです。

例6.26 module.xml

<module xmlns="urn:jboss:module:1.1" name="com.oracle">
  <resources>
    <resource-root path="ojdbc6.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
Copy to Clipboard Toggle word wrap

6.8.6. Oracle XA データソースの例

Oracle のデータソース
バージョン 10.2 以前の Oracle データソースでは、トランザクション以外の接続とトランザクション接続が混在するとエラーが発生するため、<no-tx-separate-pools/> パラメーターが必要でした。特定のアプリケーションでこのパラメーターが不要になる場合があります。
重要
Oracle XA データソースにアクセスするユーザーは、以下の設定を適用しないと XA リカバリーが適切に操作しません。値 user は、JBoss から Oracle に接続するために定義されたユーザーです。
  • GRANT SELECT ON sys.dba_pending_transactions TO user;
  • GRANT SELECT ON sys.pending_trans$ TO user;
  • GRANT SELECT ON sys.dba_2pc_pending TO user;
  • GRANT EXECUTE ON sys.dbms_xa TO user; (パッチ済みの Oracle 10g R2、または Oracle 11g を使用する場合)
    または、
    GRANT EXECUTE ON sys.dbms_system TO user; (パッチされていない 11g 以前のバージョンの Oracle を使用する場合)
Oracle XA データソースの設定例は次のとおりです。データソースが有効になり、ユーザーが追加され、検証オプションが設定されます。

例6.27 Oracle XA データソース

<datasources>
  <xa-datasource jndi-name="java:/XAOracleDS" pool-name="XAOracleDS">
    <driver>oracle</driver>
    <xa-datasource-property name="URL">jdbc:oracle:oci8:@tc</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <xa-pool>
      <is-same-rm-override>false</is-same-rm-override>
      <no-tx-separate-pools />
    </xa-pool>
    <validation>
      <validate-on-match>true</validate-on-match>
      <background-validation>false</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleValidConnectionChecker"></valid-connection-checker>
      <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleStaleConnectionChecker"></stale-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.oracle.OracleExceptionSorter"></exception-sorter>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="oracle" module="com.oracle">
      <xa-datasource-class>oracle.jdbc.xa.client.OracleXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
Copy to Clipboard Toggle word wrap
上記 Oracle XA データソースの module.xml ファイルの例は次のとおりです。

例6.28 module.xml

<module xmlns="urn:jboss:module:1.1" name="com.oracle">
  <resources>
    <resource-root path="ojdbc6.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
Copy to Clipboard Toggle word wrap

6.8.7. Microsoft SQLServer のデータソースの例

Microsoft SQLServer データソースの設定例は次のとおりです。データソースが有効になり、ユーザーが追加され、検証オプションが設定されます。

例6.29 SQLServer データソースの設定

<datasources>
  <datasource jndi-name="java:/MSSQLDS" pool-name="MSSQLDS">
    <connection-url>jdbc:sqlserver://localhost:1433;DatabaseName=MyDatabase</connection-url>
    <driver>sqlserver</driver>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <validate-on-match>true</validate-on-match>
      <background-validation>false</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="sqlserver" module="com.microsoft">
  </datasources>
Copy to Clipboard Toggle word wrap
上記 Microsoft SQLServer データソースの module.xml ファイルの例は次のとおりです。

例6.30 module.xml

<module xmlns="urn:jboss:module:1.1" name="com.microsoft">
  <resources>
    <resource-root path="sqljdbc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
Copy to Clipboard Toggle word wrap

6.8.8. Microsoft SQLServer XA のデータソースの例

Microsoft SQLServer XA データソースの設定例は次のとおりです。データソースが有効になり、ユーザーが追加され、検証オプションが設定されます。

例6.31 SQLserver XA datasource

<datasources>
  <xa-datasource jndi-name="java:/MSSQLXADS" pool-name="MSSQLXADS">
    <driver>sqlserver</driver>
    <xa-datasource-property name="ServerName">localhost</xa-datasource-property>
    <xa-datasource-property name="DatabaseName">mssqldb</xa-datasource-property>
    <xa-datasource-property name="SelectMethod">cursor</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <xa-pool>
      <is-same-rm-override>false</is-same-rm-override>
    </xa-pool>
    <validation>
      <validate-on-match>true</validate-on-match>
      <background-validation>false</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker"></valid-connection-checker>
    	<exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLExceptionSorter"></exception-sorter>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="sqlserver" module="com.microsoft">
      <xa-datasource-class>com.microsoft.sqlserver.jdbc.SQLServerXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
Copy to Clipboard Toggle word wrap
上記 Microsoft SQLServer XA データソースの module.xml ファイルの例は次のとおりです。

例6.32 module.xml

<module xmlns="urn:jboss:module:1.1" name="com.microsoft">
  <resources>
    <resource-root path="sqljdbc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
Copy to Clipboard Toggle word wrap

6.8.9. IBM DB2 データソースの例

IBM DB2 のデータソース設定例は以下のとおりです。データソースが有効になり、ユーザーが追加され、検証オプションが設定されます。

例6.33 IBM DB2 データソースの設定

<datasources>
  <datasource jndi-name="java:/DB2DS" pool-name="DB2DS">
    <connection-url>jdbc:db2:ibmdb2db</connection-url>
    <driver>ibmdb2</driver>
    <pool>
      <min-pool-size>0</min-pool-size>
      <max-pool-size>50</max-pool-size>
    </pool>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security> 
    <validation>
      <validate-on-match>true</validate-on-match>
      <background-validation>false</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker"></valid-connection-checker>
      <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2StaleConnectionChecker"></stale-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="ibmdb2" module="com.ibm">
    </driver>
  </drivers>
</datasources>
Copy to Clipboard Toggle word wrap
上記 IBM DB2 データソースの module.xml ファイルの例は次のとおりです。

例6.34 module.xml

<module xmlns="urn:jboss:module:1.1" name="com.ibm">
  <resources>
    <resource-root path="db2jcc4.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
Copy to Clipboard Toggle word wrap

6.8.10. IBM DB2 XA のデータソースの例

IBM DB2 XA データソースの設定例は次のとおりです。データソースが有効になり、ユーザーが追加され、検証オプションが設定されます。

例6.35 IBM DB2 XA データソースの設定

<datasources>
  <xa-datasource jndi-name="java:/DB2XADS" pool-name="DB2XADS">
    <driver>ibmdb2</driver>
    <xa-datasource-property name="DatabaseName">ibmdb2db</xa-datasource-property>
    <xa-datasource-property name="ServerName">hostname</xa-datasource-property>
    <xa-datasource-property name="PortNumber">port</xa-datasource-property>
    <xa-datasource-property name="DriverType">4</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <xa-pool>
      <is-same-rm-override>false</is-same-rm-override>
    </xa-pool>
    <validation>
      <validate-on-match>true</validate-on-match>
      <background-validation>false</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ValidConnectionChecker"></valid-connection-checker>
      <stale-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2StaleConnectionChecker"></stale-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.db2.DB2ExceptionSorter"></exception-sorter>
    </validation>
    <recovery>
      <recover-plugin class-name="org.jboss.jca.core.recovery.ConfigurableRecoveryPlugin">
        <config-property name="EnableIsValid">false</config-property>
        <config-property name="IsValidOverride">false</config-property>
        <config-property name="EnableClose">false</config-property>
      </recover-plugin>
    </recovery>
  </xa-datasource>
  <drivers>
    <driver name="ibmdb2" module="com.ibm">
      <xa-datasource-class>com.ibm.db2.jcc.DB2XADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
Copy to Clipboard Toggle word wrap
上記 IBM DB2 XA データソースの module.xml ファイルの例は次のとおりです。

例6.36 module.xml

<module xmlns="urn:jboss:module:1.1" name="com.ibm">
  <resources>
    <resource-root path="db2jcc4.jar"/>
    <resource-root path="db2jcc_license_cisuz.jar"/>
    <resource-root path="db2jcc_license_cu.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
Copy to Clipboard Toggle word wrap

6.8.11. Sybase データソースの例

Sybase データソースの設定例は以下のとおりです。データソースが有効になり、ユーザーが追加され、検証オプションが設定されます。

例6.37 Sybase データソースの設定

<datasources>
  <datasource jndi-name="java:jboss/SybaseDB" pool-name="SybaseDB" enabled="true">
    <connection-url>jdbc:sybase:Tds:localhost:5000/DATABASE?JCONNECT_VERSION=6</connection-url>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <validation>
      <validate-on-match>true</validate-on-match>
      <background-validation>false</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter"></exception-sorter>
    </validation>
  </datasource>
  <drivers>
    <driver name="sybase" module="com.sybase">
      <datasource-class>com.sybase.jdbc4.jdbc.SybDataSource</datasource-class>
      <xa-datasource-class>com.sybase.jdbc4.jdbc.SybXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
Copy to Clipboard Toggle word wrap
上記 Sybase データソースの module.xml ファイルの例は次のとおりです。

例6.38 module.xml

<module xmlns="urn:jboss:module:1.1" name="com.sybase">
  <resources>
    <resource-root path="jconn2.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
Copy to Clipboard Toggle word wrap

6.8.12. Sybase XA データソースの例

Sybase XA データソースの設定例は次のとおりです。データソースが有効になり、ユーザーが追加され、検証オプションが設定されます。

例6.39 Sybase XA データソースの設定

<datasources>
  <xa-datasource jndi-name="java:jboss/SybaseXADS" pool-name="SybaseXADS" enabled="true">
    <xa-datasource-property name="NetworkProtocol">Tds</xa-datasource-property>
    <xa-datasource-property name="ServerName">myserver</xa-datasource-property>
    <xa-datasource-property name="PortNumber">4100</xa-datasource-property>
    <xa-datasource-property name="DatabaseName">mydatabase</xa-datasource-property>
    <security>
      <user-name>admin</user-name>
      <password>admin</password>
    </security>
    <xa-pool>
      <is-same-rm-override>false</is-same-rm-override>
    </xa-pool>
    <validation>
      <validate-on-match>true</validate-on-match>
      <background-validation>false</background-validation>
      <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseValidConnectionChecker"></valid-connection-checker>
      <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.sybase.SybaseExceptionSorter"></exception-sorter>
    </validation>
  </xa-datasource>
  <drivers>
    <driver name="sybase" module="com.sybase">
      <datasource-class>com.sybase.jdbc4.jdbc.SybDataSource</datasource-class>
      <xa-datasource-class>com.sybase.jdbc4.jdbc.SybXADataSource</xa-datasource-class>
    </driver>
  </drivers>
</datasources>
Copy to Clipboard Toggle word wrap
上記 Sybase XA データソースの module.xml ファイルの例は次のとおりです。

例6.40 module.xml

<module xmlns="urn:jboss:module:1.1" name="com.sybase">
  <resources>
    <resource-root path="jconn2.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
Copy to Clipboard Toggle word wrap

第7章 モジュールの設定

7.1. はじめに

7.1.1. モジュール

モジュールは、クラスローディングおよび依存関係管理に使用されるクラスの論理グループです。JBoss EAP 6 は、静的モジュールと動的モジュールと呼ばれる 2 種類のモジュールを識別します。ただし、この 2 つの間の唯一の違いは、パッケージ化方法です。
静的モジュール
静的モジュールは、アプリケーションサーバーの EAP_HOME/modules/ ディレクトリーで事前定義されます。各サブディレクトリーは 1 つのモジュールを表し、設定ファイル(module.xml)と必要な JAR ファイルが含まれる main/ サブディレクトリーを定義します。モジュールの名前は module.xml ファイルで定義されます。アプリケーションサーバーにより提供される API は、Java EE API や JBoss Logging などの他の API を含む静的モジュールとして提供されます。

例7.1 module.xml ファイルの例

<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.0" name="com.mysql">
  <resources>
    <resource-root path="mysql-connector-java-5.1.15.jar"/>
  </resources>
  <dependencies>
    <module name="javax.api"/>
    <module name="javax.transaction.api"/>
  </dependencies>
</module>
Copy to Clipboard Toggle word wrap
モジュール名 com.mysql は、main/ サブディレクトリー名を除く、モジュールのディレクトリー構造と一致する必要があります。
JBoss EAP ディストリビューションで提供されるモジュールは、EAP_HOME/modules ディレクトリー内の system ディレクトリーにあります。このため、サードパーティーによって提供されるモジュールから分離されます。
JBoss EAP 6.1 以降では、Red Hat が提供するレイヤー化された製品も、system ディレクトリー内にそのモジュールをインストールします。
カスタム静的モジュールの作成は、同じサードパーティーライブラリーを使用する同じサーバー上に多くのアプリケーションがデプロイされる場合に役立ちます。これらのライブラリーを各アプリケーションとバンドルする代わりに、JBoss 管理者によってこれらのライブラリーが含まれるモジュールを作成およびインストールできます。アプリケーションは、カスタム静的モジュールで明示的な依存関係を宣言できます。
モジュールレイアウトごとに 1 つのディレクトリーを使用して、カスタムモジュールが EAP_HOME/modules ディレクトリーにインストールされるようにする必要があります。これにより、同梱されたバージョンではなく、system ディレクトリーに存在するカスタムバージョンのモジュールがロードされるようになります。このようにして、ユーザー提供のモジュールはシステムモジュールよりも優先されます。
JBOSS_MODULEPATH 環境変数を使用して JBoss EAP がモジュールを検索する場所を変更する場合、指定された場所の 1 つで system サブディレクトリー構造を探します。システム 構造は、JBOSS_MODULEPATH で指定された場所のどこかに存在する必要があります。
動的モジュール
動的モジュールは、各 JAR または WAR デプロイメント(または EAR 内のサブデプロイメント)に対してアプリケーションサーバーによって作成およびロードされます。動的モジュールの名前は、デプロイされたアーカイブの名前に由来します。デプロイメントはモジュールとしてロードされるため、依存関係を設定し、他のデプロイメントで依存関係として使用することが可能です。
モジュールは必要な場合にのみロードされます。通常、モジュールは、明示的または暗黙的な依存関係があるアプリケーションがデプロイされる場合にのみロードされます。

7.1.2. グローバルモジュール

グローバルモジュールは、JBoss EAP 6 が各アプリケーションへの依存関係として提供するモジュールです。モジュールは、アプリケーションサーバーのグローバルモジュールの一覧に追加することでグローバルモジュールを作成できます。モジュールへの変更は必要ありません。

7.1.3. モジュールの依存性

モジュール依存関係は、あるモジュールが機能するために別のモジュールのクラスを必要とする宣言です。モジュールは、他のモジュールの依存関係を宣言できます。アプリケーションサーバーがモジュールをロードすると、モジュールクラスローダーはそのモジュールの依存関係を解析し、各依存関係のクラスをクラスパスに追加します。指定の依存関係が見つからない場合、モジュールはロードできません。
デプロイされたアプリケーション (JAR または WAR) は動的モジュールとしてロードされ、依存関係を利用して JBoss EAP 6 によって提供される API にアクセスします。
依存関係には明示的と暗黙的の 2 つのタイプがあります。

明示的な依存関係

明示的な依存関係は開発者が設定ファイルで宣言します。静的モジュールは、依存関係を module.xml ファイルに宣言できます。動的モジュールでは、デプロイメントの MANIFEST.MF または jboss-deployment-structure.xml デプロイメント記述子に依存関係を宣言できます。

明示的な依存関係は、オプションとして指定できます。オプションの依存関係をロードできなくても、モジュールのロードは失敗しません。ただし、依存関係が後で使用できるようになっても、モジュールのクラスパスには追加されません。依存関係はモジュールがロードされるときに利用可能である必要があります。

暗黙的な依存関係

暗黙的な依存関係は、デプロイメントで特定の条件またはメタデータが見つかると、アプリケーションサーバーによって自動的に追加されます。JBoss EAP 6 に同梱される Java EE 6 API は、デプロイメントで暗黙的な依存関係が検出されたときに追加されるモジュールの例になります。

特定の暗黙的な依存関係を除外するようにデプロイメントを設定することもできます。これは、jboss-deployment-structure.xml デプロイメント記述子ファイルで行います。これは、アプリケーションサーバーが暗黙的な依存関係として追加しようとする特定バージョンのライブラリーをアプリケーションがバンドルする場合に一般的に行われます。
モジュールのクラスパスには、独自のクラスと、その直接の依存関係のクラスのみが含まれます。モジュールは 1 つの依存関係の依存関係クラスにはアクセスできませんが、暗黙的な依存関係のエクスポートを指定できます。ただし、モジュールは、明示的な依存関係をエクスポートするように指定できます。エクスポートした依存関係は、エクスポートするモジュールに依存するモジュールに提供されます。

例7.2 モジュールの依存関係

モジュール A はモジュール B に依存し、モジュール B はモジュール C に依存します。モジュール A はモジュール B のクラスにアクセスでき、モジュール B はモジュール C のクラスにアクセスできます。以下の場合を除き、モジュール A はモジュール C のクラスにはアクセスできません。
  • モジュール A がモジュール C への明示的な依存関係を宣言する場合。
  • または、モジュール B がモジュール B の依存関係をモジュール C でエクスポートする場合。
jboss-deployment-structure.xml デプロイメント記述子に関する詳細は、『『開発ガイド』』 の「 『クラスローディングとモジュール』 」の章を参照してください。

7.1.4. サブデプロイメントクラスローダーの分離

エンタープライズアーカイブ (EAR) の各サブデプロイメントは独自のクラスローダーを持つ動的モジュールです。デフォルトでは、サブデプロイメントは他のサブデプロイメントのリソースにアクセスできます。
サブデプロイメントが他のサブデプロイメントのリソースにアクセスすることが許可されていない場合は、厳格なサブデプロイメントの分離を有効にできます。

7.2. すべてのデプロイメントを対象とするサブデプロイメントモジュール分離の無効化

このタスクでは、サーバー管理者がアプリケーションサーバーでサブデプロイメントモジュール分離を無効にする方法を説明します。これはすべてのデプロイメントに影響します。
警告
このタスクでは、サーバーの XML 設定ファイルを編集する必要があります。これを実行する前にサーバーを停止する必要があります。最終的なリリース管理ツールはこの種の設定をサポートするため、これは一時的なものです。
  1. サーバーの停止

    JBoss EAP 6 サーバーを停止します。
  2. サーバー設定ファイルを開く

    サーバー設定ファイルをテキストエディターで開きます。
    このファイルは、管理対象ドメインまたはスタンドアロンサーバーの場合とは異なります。さらに、デフォルト以外の場所とファイル名を使用することもできます。デフォルトの設定ファイルは、管理対象ドメインとスタンドアロンサーバーの domain/configuration/domain.xmlstandalone/configuration/standalone.xml です。
  3. EE サブシステム設定の特定

    設定ファイルで EE サブシステム設定要素を見つけます。設定ファイルの <profile> 要素には、複数のサブシステム要素が含まれます。EE Subsystem 要素には urn:jboss:domain:ee:1.2 の名前空間があります。
    <profile>
    
       ...
    
       <subsystem xmlns="urn:jboss:domain:ee:1.2" />
    
       ...
    Copy to Clipboard Toggle word wrap
    デフォルト設定には単一の自己終了タグがありますが、カスタム設定は、以下のような個別の開始タグと終了タグを持つことがあります (タグ間に別の要素が含まれることがあります)。
    <subsystem xmlns="urn:jboss:domain:ee:1.2" ></subsystem>
    Copy to Clipboard Toggle word wrap
  4. 自己終了タグの置き換え (必要な場合)

    EE サブシステム要素が単一の自己終了タグである場合は、以下のように適切な開始タグと終了タグで置き換えます。
    <subsystem xmlns="urn:jboss:domain:ee:1.2" ></subsystem>
    Copy to Clipboard Toggle word wrap
  5. ear-subdeployments-isolated 要素の追加

    ear-subdeployments-isolated 要素を EE サブシステム要素の子として追加し、以下のように false の内容を追加します。
    <subsystem xmlns="urn:jboss:domain:ee:1.2" ><ear-subdeployments-isolated>false</ear-subdeployments-isolated></subsystem>
    Copy to Clipboard Toggle word wrap
  6. サーバーの起動

    新しい設定で実行されるよう JBoss EAP 6 サーバーを再起動します。

結果

すべてのデプロイメントに対してサブデプロイメントモジュール分離が無効化された状態で、サーバーが実行されます。

7.3. すべてのデプロイメントへのモジュールの追加

このタスクは JBoss 管理者によるグローバルモジュールリストの定義方法を実証します。

前提条件

  1. グローバルモジュールとして設定するモジュールの名前を知っている必要があります。JBoss EAP 6 に含まれる静的モジュールのリストは、「含まれるモジュール」 を参照してください。モジュールが別のデプロイメントにある場合は、「動的モジュールの名前付け」 を参照してモジュール名を判断してください。

手順7.1 グローバルモジュールリストへのモジュールの追加

  1. 管理コンソールへログインします。「管理コンソールへのログイン」
  2. EE Subsystem パネルに移動します。
    1. コンソールの上部にある Configuration タブを選択します。
    2. ドメインモードの場合

      1. 左上のドロップダウンボックスより該当するプロファイルを選択します。
    3. コンソールの左側にある Subsystems メニューを展開します。
    4. コンソールの左側にあるメニューから ContainerEE を選択します。
  3. Subsystem Defaults セクションで Add をクリックします。モジュールの 作成ダイアログが 表示されます。
  4. モジュールの名前と任意でモジュールスロットを入力します。
  5. Save をクリックして新しいグローバルモジュールを追加するか、Cancel をクリックして中断します。
    • Save をクリックすると、ダイアログが閉じられ、指定のモジュールがグローバルモジュールのリストに追加されます。
    • Cancel をクリックするとダイアログが閉じられ、変更は加えられません。

結果

グローバルモジュールのリストに追加されたモジュールは各デプロイメントへの依存関係に追加されます。

7.4. カスタムモジュールの作成

次の手順では、JBoss EAP サーバー上で実行されているすべてのアプリケーションがプロパティーファイルやその他のリソースを使用できるようにするために、カスタムモジュールを作成する方法について説明します。

手順7.2 カスタムモジュールの作成

  1. モジュール/ ディレクトリー構造を作成し、これを追加します。
    1. EAP_HOME/module ディレクトリーにディレクトリー構造を作成し、ファイルと JAR が含まれるようにします。以下に例を示します。
      $ cd EAP_HOME/modules/ 
      $ mkdir -p myorg-conf/main/properties
      Copy to Clipboard Toggle word wrap
    2. プロパティーファイルを、前のステップで作成した EAP_HOME/modules/myorg-conf/main/properties/ ディレクトリーに移動します。
    3. 以下の XML が含まれる EAP_HOME/modules/myorg-conf/main/ ディレクトリーに module.xml ファイルを作成します。
      <module xmlns="urn:jboss:module:1.1" name="myorg-conf">
          <resources>
              <resource-root path="properties"/>
          </resources>
      </module>
      Copy to Clipboard Toggle word wrap
  2. サーバー設定ファイルの ee サブシステムを変更します。Managemet CLI を使用するか、ファイルを手動で編集できます。
    • 管理 CLI を使用してサーバー設定ファイルを変更するには、以下の手順に従います。
      1. サーバーを起動し、管理 CLI へ接続します。
        • Linux の場合は、コマンドラインで以下を入力します。
           EAP_HOME/bin/jboss-cli.sh --connect
          Copy to Clipboard Toggle word wrap
        • Windows の場合は、コマンドラインで以下を入力します。
          C:\>EAP_HOME\bin\jboss-cli.bat --connect
          Copy to Clipboard Toggle word wrap
        次の応答が表示されるはずです。
        Connected to standalone controller at localhost:9999
        Copy to Clipboard Toggle word wrap
      2. ee サブシステムで myorg-conf {-module> 要素を作成するには、コマンドラインで以下を入力します。
        /subsystem=ee:write-attribute(name=global-modules, value=[{"name"=>"myorg-conf","slot"=>"main"}])
        Copy to Clipboard Toggle word wrap
        以下の結果が表示されるはずです。
        {"outcome" => "success"}
        Copy to Clipboard Toggle word wrap
    • サーバー設定ファイルを手作業で編集する場合は、次の手順に従ってください。
      1. サーバーを停止し、テキストエディターでサーバー設定ファイルを開きます。スタンドアロンサーバーを実行している場合は、これは EAP_HOME/standalone/configuration/standalone.xml ファイル、管理対象ドメインを実行している場合は EAP_HOME/domain/configuration/domain.xml ファイルになります。
      2. ee サブシステムを見つけ、myorg-conf のグローバルモジュールを追加します。以下は、myorg-conf 要素が含まれるように変更された ee サブシステム要素の例になります。

        例7.3 myorg-conf 要素

        <subsystem xmlns="urn:jboss:domain:ee:1.0" >            
            <global-modules>
                <module name="myorg-conf" slot="main" />            
            </global-modules>
        </subsystem>
        Copy to Clipboard Toggle word wrap
  3. my.properties という名前のファイルを正しいモジュールの場所にコピーした場合、以下のようなコードを使用してプロパティーファイルをロードできるようになります。

    例7.4 プロパティーファイルの読み込み

    Thread.currentThread().getContextClassLoader().getResource("my.properties");
    Copy to Clipboard Toggle word wrap

7.5. 外部 JBoss モジュールディレクトリーの定義

概要

デフォルトでは、JBoss EAP は EAP_HOME/modules/ ディレクトリーでモジュールを検索します。JBOSS_MODULEPATH 環境変数を定義するか、起動設定ファイルで変数を設定することで、JBoss EAP が 1 つまたは複数の外部ディレクトリーを検索するように指示できます。このトピックでは、両方の方法について説明します。

手順7.3 JBOSS_MODULEPATH 環境変数の設定

  • 1 つ以上の外部モジュールディレクトリーを指定するには、JBOSS_MODULEPATH 環境変数を定義します。
    Linux の場合は、コロンを使用してディレクトリーのリストを区切ます。以下に例を示します。

    例7.5 JBOSS_MODULEPATH 環境変数

    export JBOSS_MODULEPATH=EAP_HOME/modules/:/home/username/external/modules/directory/
    Copy to Clipboard Toggle word wrap
    Windows の場合は、セミコロンを使用してディレクトリーのリストを区切ります。以下に例を示します。

    例7.6 JBOSS_MODULEPATH 環境変数

    SET JBOSS_MODULEPATH=EAP_HOME\modules\;D:\JBoss-Modules\
    Copy to Clipboard Toggle word wrap

手順7.4 起動設定ファイルでの JBOSS_MODULEPATH 変数の設定

  • グローバル環境変数を設定しない場合は、JBoss EAP 起動設定ファイルに JBOSS_MODULEPATH 変数を設定できます。スタンドアロンサーバーを実行している場合は、EAP_HOME/bin/standalone.conf ファイルになります。サーバーが管理対象ドメインで実行されている場合、これは EAP_HOME/bin/domain.conf ファイルになります。
    以下は、standalone.conf ファイルに JBOSS_MODULEPATH 変数を設定するコマンドの例です。

    例7.7 standalone.conf entry

    JBOSS_MODULEPATH="EAP_HOME/modules/:/home/username/external/modules/directory/"
    Copy to Clipboard Toggle word wrap

7.6. 参照資料

7.6.1. 含まれるモジュール

JBoss EAP 6 に含まれるモジュールとそれらのモジュールがサポートされるかどうかの表は、カスタマーポータルの を参照してください https://access.redhat.com/articles/1122333

7.6.2. 動的モジュールの名前付け

すべてのデプロイメントは JBoss EAP 6 によってモジュールとしてロードされ、以下の慣例に従って名前が付けられます。
  • WAR および JAR ファイルのデプロイメントは次の形式で名前が付けられます。
     deployment.DEPLOYMENT_NAME 
    Copy to Clipboard Toggle word wrap
    たとえば、inventory.warstore.jar のモジュール名はそれぞれ deployment.inventory.wardeployment.store.jar になります。
  • エンタープライズアーカイブ内のサブデプロイメントは次の形式で名前が付けられます。
     deployment.EAR_NAME.SUBDEPLOYMENT_NAME 
    Copy to Clipboard Toggle word wrap
    たとえば、エンタープライズアーカイブ accounts.ear 内の reports.war のサブデプロイメントは deployment.accounts.ear.reports.war のモジュール名を持ちます。

第8章 Jsvc

8.1. はじめに

8.1.1. Jsvc

Jsvc は、Java アプリケーションをバックグラウンドサービスとして UNIX および UNIX 系プラットフォームで実行できるライブラリーとアプリケーションのセットです。これにより、アプリケーションは特権ユーザーとして操作を実行でき、実行後に非特権ユーザーに切り替えできます。
Jsvc はランチャープロセス、コントローラープロセス、および制御されたプロセスの 3 つのプロセスを使用します。制御されたプロセスはメインの Java スレッドでもあります。JVM がクラッシュすると、コントローラープロセスが 60 秒以内に JVM を再起動します。Jsvc はデーモンプロセスで、JBoss EAP 6 では特権ユーザーによって起動される必要があります。
注記
Jsvc は Red Hat Enterprise Linux、Solaris、および HP-UX のみで使用できます。Microsoft Windows の同様の機能については、Red Hat カスタマーポータル から利用可能な Native Utilities for Windows Server ダウンロードの prunsrv.exe を参照してください。

8.1.2. Jsvc を使用した JBoss EAP の起動および停止

Jsvc を使用して JBoss EAP を起動および停止する手順は、スタンドアロンまたはドメインで動作するモードによって異なります。JBoss EAP がドメインモードで実行される場合、Jsvc はドメインコントローラーのプロセスのみを処理することに注意してください。Jsvc を使用して JBoss EAP を起動するために使用するコマンドはいずれも、特権ユーザーによって実行する必要があります。

前提条件

  • Zip を使用して JBoss EAP がインストールされた場合、以下の条件を満たしている必要があります。
    • Red Hat カスタマーポータルからダウンロードできる、お使いのオペレーティングシステム用の 『ネイティブユーティリティー』 パッケージをインストールします。『 『インストール 『ガイド』の「ネイティブコンポーネントおよびネイティブユーティリティーのインストール』 (Zip、インストーラー)』 」を参照してください。
    • JBoss EAP 6 インスタンスが実行されるユーザーアカウントを作成します。サーバーの起動と停止に使用されるアカウントは、JBoss EAP がインストールされたディレクトリーへの読み書きアクセスを持っている必要があります。
  • RPM を使用して JBoss EAP がインストールされた場合は、『apache-commons-daemon-jsvc-eap6』 パッケージをインストールします。『 『インストール 『ガイド』 』の「ネイティブコンポーネントおよびネイティブユーティリティーのインストール(RPM インストール)』 」を参照してください。
以下のコマンドは、スタンドアロンまたはドメインモードのいずれかで JBoss EAP を起動および停止します。ファイルの場所は、JBoss EAP 6 で Jsvc をインストールする方法によって異なることに注意してください。以下の表を使用して、コマンドの変数を解決するために使用するファイルを決定します。

スタンドアロンモード

以下は、スタンドアロンモードで JBoss EAP を起動または停止する手順です。

Expand
表8.1 Zip インストールの Jsvc ファイルの場所 - スタンドアロンモード
手順のファイル参照 ファイルの場所
EAP-HOME
${eap-installation-location}/jboss-eap-${version}
JSVC-BIN
EAP_HOME/modules/system/layers/base/native/sbin/jsvc
JSVC-JAR
EAP_HOME/modules/system/layers/base/native/sbin/commons-daemon.jar
CONF-DIR
EAP_HOME/standalone/configuration
LOG-DIR
EAP_HOME/standalone/log
Expand
表8.2 RPM インストールの Jsvc ファイルの場所 - スタンドアロンモード
手順のファイル参照 ファイルの場所
EAP-HOME
/usr/share/jbossas
JSVC-BIN
/usr/bin/jsvc-eap6/jsvc
JSVC-JAR
EAP_HOME/modules/system/layers/base/native/sbin/commons-daemon.jar
CONF-DIR
/etc/jbossas/standalone
LOG-DIR
/var/log/jbossas/standalone

スタンドモードでの JBoss EAP の起動

  • JSVC_BIN \
     -outfile LOG_DIR/jsvc.out.log   \
     -errfile LOG_DIR/jsvc.err.log   \
     -pidfile LOG_DIR/jsvc.pid  \
     -user jboss \
     -D[Standalone] -XX:+UseCompressedOops -Xms1303m \
     -Xmx1303m -XX:MaxPermSize=256m \
     -Djava.net.preferIPv4Stack=true 
     -Djboss.modules.system.pkgs=org.jboss.byteman \
     -Djava.awt.headless=true \
     -Dorg.jboss.boot.log.file=LOG_DIR/server.log \
     -Dlogging.configuration=file:CONF_DIR/logging.properties \
     -Djboss.modules.policy-permissions \
     -cp EAP_HOME/jboss-modules.jar:JSVC_JAR \
     -Djboss.home.dir=EAP_HOME \
     -Djboss.server.base.dir=EAP_HOME/standalone   \
     @org.jboss.modules.Main -start-method main \
     -mp EAP_HOME/modules \
     -jaxpmodule javax.xml.jaxp-provider \
     org.jboss.as.standalone
    Copy to Clipboard Toggle word wrap

スタンドアロンモードでの JBoss EAP の停止

  • JSVC_BIN \
     -stop \
     -outfile LOG_DIR/jsvc.out.log   \
     -errfile LOG_DIR/jsvc.err.log   \
     -pidfile LOG_DIR/jsvc.pid  \
     -user jboss \
     -D[Standalone] -XX:+UseCompressedOops -Xms1303m \
     -Xmx1303m -XX:MaxPermSize=256m \
     -Djava.net.preferIPv4Stack=true \
     -Djboss.modules.system.pkgs=org.jboss.byteman \
     -Djava.awt.headless=true \
     -Dorg.jboss.boot.log.file=LOG_DIR/server.log \
     -Dlogging.configuration=file:CONF_DIR/logging.properties \
     -Djboss.modules.policy-permissions \
     -cp EAP_HOME/jboss-modules.jar:JSVC_JAR \
     -Djboss.home.dir=EAP_HOME \
     -Djboss.server.base.dir=EAP_HOME/standalone   \
     @org.jboss.modules.Main -start-method main \
     -mp EAP_HOME/modules \
     -jaxpmodule javax.xml.jaxp-provider \
     org.jboss.as.standalone
    Copy to Clipboard Toggle word wrap

ドメインモード

以下は、ドメインモードで JBoss EAP を起動または停止する手順です。ドメインモードの場合は、JAVA_HOME 変数を Java ホームディレクトリーに置き換える必要があることに注意してください。

Expand
表8.3 Zip インストールの Jsvc ファイルの場所 - ドメインモード
手順のファイル参照 ファイルの場所
EAP-HOME
${eap-installation-location}/jboss-eap-${version}
JSVC-BIN
EAP_HOME/modules/system/layers/base/native/sbin/jsvc
JSVC-JAR
EAP_HOME/modules/system/layers/base/native/sbin/commons-daemon.jar
CONF-DIR
EAP_HOME/domain/configuration
LOG-DIR
EAP_HOME/domain/log
Expand
表8.4 RPM インストールの Jsvc ファイルの場所 - ドメインモード
手順のファイル参照 ファイルの場所
EAP-HOME
/usr/share/jbossas
JSVC-BIN
/usr/bin/jsvc-eap6/jsvc
JSVC-JAR
EAP_HOME/modules/system/layers/base/native/sbin/commons-daemon.jar
CONF-DIR
/etc/jbossas/domain
LOG-DIR
/var/log/jbossas/domain

ドメインモードでの JBoss EAP の起動

  • JSVC_BIN \
     -outfile LOG_DIR/jsvc.out.log   \
     -errfile LOG_DIR/jsvc.err.log   \
     -pidfile LOG_DIR/jsvc.pid  \
     -user jboss \
     -nodetach -D"[Process Controller]" -server -Xms64m \
     -Xmx512m -XX:MaxPermSize=256m \
     -Djava.net.preferIPv4Stack=true  \
     -Djboss.modules.system.pkgs=org.jboss.byteman \
     -Djava.awt.headless=true  \
     -Dorg.jboss.boot.log.file=LOG_DIR/process-controller.log \
     -Dlogging.configuration=file:CONF_DIR/logging.properties \
     -Djboss.modules.policy-permissions \
     -cp "EAP_HOME/jboss-modules.jar:JSVC_JAR" \
     org.apache.commons.daemon.support.DaemonWrapper \
     -start org.jboss.modules.Main -start-method main \
     -mp EAP_HOME/modules org.jboss.as.process-controller \
     -jboss-home EAP_HOME -jvm $JAVA_HOME/bin/java \
     -mp EAP_HOME/modules -- \
     -Dorg.jboss.boot.log.file=LOG_DIR/host-controller.log \
     -Dlogging.configuration=file:CONF_DIR/logging.properties \
     -Djboss.modules.policy-permissions \
     -server -Xms64m -Xmx512m -XX:MaxPermSize=256m \
     -Djava.net.preferIPv4Stack=true \
     -Djboss.modules.system.pkgs=org.jboss.byteman \
     -Djava.awt.headless=true -- -default-jvm $JAVA_HOME/bin/java
    Copy to Clipboard Toggle word wrap

ドメインモードでの JBoss EAP の停止

  • JSVC_BIN \
     -stop \
     -outfile LOG_DIR/jsvc.out.log   \
     -errfile LOG_DIR/jsvc.err.log   \
     -pidfile LOG_DIR/jsvc.pid  \
     -user jboss \
     -nodetach -D"[Process Controller]" -server -Xms64m \
     -Xmx512m -XX:MaxPermSize=256m \
     -Djava.net.preferIPv4Stack=true  \
     -Djboss.modules.system.pkgs=org.jboss.byteman \
     -Djava.awt.headless=true  \
     -Dorg.jboss.boot.log.file=LOG_DIR/process-controller.log \
     -Dlogging.configuration=file:CONF_DIR/logging.properties \
     -Djboss.modules.policy-permissions \
     -cp "EAP_HOME/jboss-modules.jar:JSVC_JAR" \
     org.apache.commons.daemon.support.DaemonWrapper \
     -start org.jboss.modules.Main -start-method main \
     -mp EAP_HOME/modules org.jboss.as.process-controller \
     -jboss-home EAP_HOME -jvm $JAVA_HOME/bin/java \
     -mp EAP_HOME/modules -- \
     -Dorg.jboss.boot.log.file=LOG_DIR/host-controller.log \
     -Dlogging.configuration=file:CONF_DIR/logging.properties \
     -Djboss.modules.policy-permissions \
     -server -Xms64m -Xmx512m -XX:MaxPermSize=256m \
     -Djava.net.preferIPv4Stack=true \
     -Djboss.modules.system.pkgs=org.jboss.byteman \
     -Djava.awt.headless=true -- -default-jvm $JAVA_HOME/bin/java
    Copy to Clipboard Toggle word wrap
注記
JVM のクラッシュなど、JBoss EAP 6 が通常通りに終了した場合、Jsvc は自動的に再起動します。JBoss EAP 6 が正常に終了した場合、Jsvc も停止します。

第9章 グローバル値

9.1. バルブ

バルブは、アプリケーションのパイプラインを処理するリクエストに挿入される Java クラスです。これは、サーブレットフィルターの前にパイプラインに挿入されます。バルブは、認証などの他の処理にパスしたり、リクエストをキャンセルしたりする前に、リクエストに変更を加えることができます。
バルブは、サーバーレベルまたはアプリケーションレベルで設定できます。唯一の違いは、どのように設定およびパッケージ化されているかです。
  • グローバルバルブはサーバーレベルで設定され、サーバーにデプロイされたすべてのアプリケーションに適用されます。グローバルバルブの設定手順は、JBoss EAP の 『管理および設定ガイド』 を参照してください。
  • アプリケーションレベルで設定されたバルブはアプリケーションデプロイメントとパッケージ化され、特定のアプリケーションのみが影響を受けます。アプリケーションレベルでバルブを設定する手順は、JBoss EAP の 『『開発ガイド』』 を参照してください。
6.1.0 およびそれ以降のバージョンはグローバルバルブをサポートします。

9.2. グローバルバルブ

グローバルバルブは、デプロイされたすべてのアプリケーションのパイプラインを処理するリクエストに挿入されるバルブです。バルブは、JBoss EAP 6 で静的モジュールとしてパッケージ化およびインストールされ、グローバル化されます。グローバルバルブは Web サブシステムで設定されます。
6.1.0 およびそれ以降のバージョンのみがグローバルバルブをサポートします。
グローバルバルブの設定方法については、『オーバークラウドの高度なカスタマイズ』の「グローバルバルブの設定」を参照してください。 「グローバルバルブの設定」

9.3. オーセンティケーターバルブ

オーセンティケーターバルブは、リクエストの認証情報を認証するバルブです。このようなバルブは org.apache.catalina.authenticator.AuthenticatorBase のサブクラスで、authenticate(Request request, Response response, LoginConfig config) メソッドを上書きします。
このバルブを使用して追加の認証スキームを実装できます。

9.4. グローバルバルブのインストール

グローバルバルブは、JBoss EAP 6 で静的モジュールとしてパッケージ化およびインストールする必要があります。このタスクは、モジュールのインストール方法を示しています。

前提条件:

  • バルブを作成し、JAR ファイルにパッケージ化する必要があります。
  • モジュール用に module.xml ファイルがすでに作成されている必要があります。
    module.xml ファイルの例については、「モジュール」 を参照してください。

手順9.1 グローバルモジュールのインストール

  1. モジュールインストールディレクトリーの作成

    インストールするモジュールのディレクトリーはアプリケーションサーバーの modules ディレクトリーに作成する必要があります。
    EAP_HOME/modules/system/layers/base/MODULENAME/main
    Copy to Clipboard Toggle word wrap
    $ mkdir -P EAP_HOME/modules/system/layers/base/MODULENAME/main
    Copy to Clipboard Toggle word wrap
  2. ファイルのコピー

    JAR および module.xml ファイルを、手順 1 で作成したディレクトリーにコピーします。
    $ cp MyValves.jar module.xml EAP_HOME/modules/system/layers/base/MODULENAME/main
    Copy to Clipboard Toggle word wrap
モジュールで宣言したバルブクラスを Web サブシステムで設定できるようになります。

9.5. グローバルバルブの設定

グローバルバルブは Web サブシステムで有効化および設定されます。これは、JBoss CLI ツールを使用して行います。

手順9.2 グローバルバルブの設定

  1. バルブの有効化

    add 操作を使用して、新しいバルブエントリーを追加します。
    /subsystem=web/valve=VALVENAME:add(module="MODULENAME",class-name="CLASSNAME")
    Copy to Clipboard Toggle word wrap
    次の値を指定する必要があります。
    • VALVENAMEアプリケーション設定でこのバルブを参照するために使用される名前。
    • MODULENAME設定されている値が含まれるモジュール。
    • CLASSNAMEモジュールの特定バルブのクラス名。
    以下に例を示します。
    /subsystem=web/valve=clientlimiter:add(module="clientlimitermodule",class-name="org.jboss.samplevalves.RestrictedUserAgentsValve")
    Copy to Clipboard Toggle word wrap
  2. オプション: パラメーターの指定

    バルブに設定パラメーターがある場合は、add-param 操作で指定します。
    /subsystem=web/valve=VALVENAME:add-param(param-name="PARAMNAME", param-value="PARAMVALUE")
    Copy to Clipboard Toggle word wrap
    次の値を指定する必要があります。
    • VALVENAMEアプリケーション設定でこのバルブを参照するために使用される名前。
    • PARAMNAME特定のバルブに設定されているパラメーターの名前。
    • PARAMVALUE(指定されたパラメーターの値)
    以下に例を示します。

    例9.1 バルブの設定

    /subsystem=web/valve=clientlimiter:add-param(
       param-name="restrictedUserAgents", 
       param-value="^.*MS Web Services Client Protocol.*$"
    )
    Copy to Clipboard Toggle word wrap
バルブがデプロイされたすべてのアプリケーションに対して有効になり、設定されます。
カスタム 『バルブの作成』 方法については、『 『開発ガイド』』 の「カスタムバルブの作成」セクションを参照してください。

第10章 アプリケーションデプロイメント

10.1. アプリケーションデプロイメント

JBoss EAP 6 には、管理環境と開発環境の両方に対応するよう、さまざまなアプリケーションデプロイメントおよび設定オプションが備えられています。管理者は、管理コンソールと管理 CLI で、実稼働環境のアプリケーションデプロイメントを管理するのに最適なグラフィカルおよびコマンドラインインターフェースを提供します。開発者は、設定可能なファイルシステムのデプロイメントスキャナー、JBoss Developer Studio などの IDE の使用、Maven を介したデプロイメントおよびアンデプロイメントなど、多くのアプリケーションデプロイメントテストオプションが含まれます。
注記
アプリケーションをデプロイする前に、デプロイメント記述子の検証を有効にできます。これには、org.jboss.metadata.parser.validate システムプロパティーを true に設定します。これには、以下の 2 つの方法があります。
  • サーバー起動時
    例:
    • ドメインモードの場合:
      ./domain.sh -Dorg.jboss.metadata.parser.validate=true
      Copy to Clipboard Toggle word wrap
    • スタンドアロンモードの場合:
      ./standalone.sh -Dorg.jboss.metadata.parser.validate=true
      Copy to Clipboard Toggle word wrap
  • サーバー設定で定義する方法。
    管理 CLI を使用したシステムプロパティーの設定に関する詳細は、を参照してください。 「管理 CLI を使用したシステムプロパティーの設定」

10.2. 管理コンソールでのデプロイ

10.2.1. 管理コンソースでのアプリケーションデプロイメント管理

管理コンソールを介してアプリケーションをデプロイすると、使いやすいグラフィカルインターフェースを利用することができます。サーバーまたはサーバーグループにデプロイされたアプリケーションを一目で確認でき、必要に応じてアプリケーションをコンテンツリポジトリーから有効化、無効化、または削除できます。

10.2.2. 管理コンソールを使用してデプロイされたアプリケーションを有効化

手順10.1 管理コンソールを使用してデプロイされたアプリケーションを有効化

  • コンソールの上部にある Deployments タブを選択します。
    アプリケーションのデプロイメントの方法は、スタンドアロンサーバーインスタンスと管理対象ドメインのどちらにデプロイするかによって異なります。
    • スタンドアロンサーバーインスタンスでのアプリケーションの有効化

      Available Deployments の表には、利用可能なすべてのアプリケーションデプロイメントおよびそれらのステータスが表示されます。
      1. スタンドアロンサーバーインスタンスでアプリケーションを有効にするには、アプリケーションを選択し、En/Disable をクリックします。

        図10.1 利用可能なデプロイメント

      2. Confirm をクリックし、サーバーインスタンスでアプリケーションが有効になっていることを確認します。

        図10.2 スタンドアロンサーバーで利用可能なデプロイメント

    • 管理対象ドメインでのアプリケーションの有効化

      Content Repository タブには、利用 可能なデプロイメントコンテンツ テーブルがあり、利用可能なアプリケーションデプロイメントとそのステータスが表示されます。
      1. 管理対象ドメインでアプリケーションを有効にするには、デプロイするアプリケーションを選択します。Available Deployment Content の表の上にある Assign をクリックします。

        図10.3 管理対象ドメインで利用可能なデプロイメント

      2. アプリケーションを追加する各サーバーグループのボックスにチェックを入れ、Save をクリックして終了します。
      3. Server Groups タブを選択して、Server Groups テーブルを表示します。

        図10.4 サーバーグループへのアプリケーションのデプロイメントの確認

      4. アプリケーションがまだ有効にされていない場合は、表示 をクリックして、En/Disable ボタンをクリックします。Confirm をクリックし、サーバーインスタンスでアプリケーションが有効になっていることを確認します。

結果

関連するサーバーまたはサーバーグループでアプリケーションが有効になっている。

10.2.3. 管理コンソールを使用してデプロイされたアプリケーションを無効化

手順10.2 管理コンソールを使用してデプロイされたアプリケーションを無効化

  • コンソールの上部にある Deployment タブを選択します。
    アプリケーションを無効化する方法は、スタンドアロンサーバーインスタンスと管理対象ドメインのどちらにデプロイするかどうかによって異なります。
    • スタンドアロンサーバーインスタンスにデプロイされたアプリケーションを無効化

      Available Deployments の表には、利用可能なすべてのアプリケーションデプロイメントおよびそれらのステータスが表示されます。

      図10.5 利用可能なデプロイメント

      1. 無効にするアプリケーションを選択します。En/Disable をクリックして、選択したアプリケーションを無効にします。
      2. Confirm をクリックし、サーバーインスタンスでアプリケーションを無効にすることを確認します。
    • 管理対象ドメインでのデプロイされたアプリケーションの無効化

      Deployments 画面には Content Repository タブが含まれます。Available Deployment Content の表には、利用可能なすべてのアプリケーションデプロイメントとそれらの状態が表示されます。
      1. Server Groups タブを選択して、サーバーグループを表示します。

        図10.6 サーバーグループのデプロイメント

      2. Server Group テーブルでサーバーグループの名前を選択し、アプリケーションをアンデプロイします。View をクリックしてアプリケーションを表示します。
      3. アプリケーションを選択し、En/Disable をクリックして選択したサーバーのアプリケーションを無効にします。
      4. Confirm をクリックし、サーバーインスタンスでアプリケーションを無効にすることを確認します。
      5. 必要に応じて他のサーバーグループにも同じ手順を繰り返します。アプリケーションステータスは、そのサーバーグループの Group Deployments テーブルの各サーバーグループに対して確認されます。

結果

関連するサーバーまたはサーバーグループからアプリケーションが無効になっている。

10.2.4. 管理コンソールを使用したアプリケーションのアンデプロイ

手順10.3 管理コンソールを使用したアプリケーションのアンデプロイ

  • コンソールの上部にある Deployments タブを選択します。
    アプリケーションをアンデプロイする方法は、スタンドアロンサーバーインスタンスと管理対象ドメインのどちらからアンデプロイするかどうかによって異なります。
    • デプロイされたアプリケーションをスタンドアロンサーバーインスタンスからアンデプロイ

      Available Deployments の表には、利用可能なすべてのアプリケーションデプロイメントおよびそれらのステータスが表示されます。

      図10.7 利用可能なデプロイメント

      1. アンデプロイするアプリケーションを選択します。Remove をクリックして、選択したアプリケーションをアンデプロイします。
      2. Confirm をクリックし、サーバーインスタンスでアプリケーションをアンデプロイしていることを確認します。
    • デプロイされたアプリケーションを管理対象ドメインからアンデプロイ

      Deployments 画面には Content Repository タブが含まれます。Available Deployment Content の表には、利用可能なすべてのアプリケーションデプロイメントとそれらの状態が表示されます。
      1. Server Groups タブを選択して、サーバーグループとデプロイされたアプリケーションの状態を表示します。

        図10.8 サーバーグループのデプロイメント

      2. Server Group テーブルでサーバーグループの名前を選択し、アプリケーションをアンデプロイします。View をクリックしてアプリケーションを表示します。
      3. アプリケーションを選択し、Remove をクリックして、選択したサーバーのアプリケーションをアンデプロイします。
      4. Confirm をクリックし、サーバーインスタンスでアプリケーションをアンデプロイしていることを確認します。
      5. 必要に応じて他のサーバーグループにも同じ手順を繰り返します。アプリケーションステータスは、そのサーバーグループの Group Deployments テーブルの各サーバーグループに対して確認されます。

結果

該当のサーバーあるいはサーバーグループからアプリケーションがアンデプロイされます。スタンドアロンインスタンスでは、デプロイメントコンテンツも削除されます。管理対象ドメインでは、デプロイメントコンテンツはコンテンツリポジトリーに残り、サーバーグループからのみアンデプロイされます。

10.3. 管理 CLI でのデプロイ

10.3.1. 管理 CLI でのアプリケーションデプロイメントの管理

管理 CLI を使用してアプリケーションをデプロイすると、単一のコマンドラインインターフェースでデプロイメントスクリプトを作成および実行できます。このスクリプト機能を使用して、特定のアプリケーションデプロイメントおよび管理シナリオを設定できます。スタンドアロンサーバーの場合は、1 台のサーバーのデプロイメントステータスや、管理対象ドメインの場合はサーバーのネットワーク全体を管理できます。

10.3.2. 管理 CLI を使用したスタンドアロンサーバーでのアプリケーションのデプロイ

手順10.4 スタンドアロンサーバーでのアプリケーションのデプロイ

  • デプロイ コマンドの実行

    管理 CLI で、アプリケーションのデプロイメントへのパスを指定して deploy コマンドを入力します。

    例10.1 デプロイコマンド

    [standalone@localhost:9999 /] deploy /path/to/test-application.war
    Copy to Clipboard Toggle word wrap
    デプロイメントに成功しても CLI には何も出力されないことに注意してください。

結果

指定のアプリケーションが、スタンドアロンサーバーにデプロイされます。

10.3.3. 管理 CLI を使用したスタンドアロンサーバーでのアプリケーションのアンデプロイ

手順10.5 スタンドアロンサーバーでのアプリケーションのアンデプロイ

デフォルトでは、undeploy コマンドは JBoss EAP のスタンドアロンインスタンスからデプロイメントコンテンツをアンデプロイ および 削除します。デプロイメントコンテンツを保持するには、パラメーター --keep-content を追加します。
  • undeploy コマンドの実行

    アプリケーションをアンデプロイし、デプロイメントコンテンツを削除するには、アプリケーションデプロイメントのファイル名を指定して管理 CLI の アンデプロイ コマンドを入力します。
    [standalone@localhost:9999 /] undeploy test-application.war
    Copy to Clipboard Toggle word wrap
    アプリケーションをアンデプロイし、デプロイメントコンテンツを保持するには、アプリケーションデプロイメントのファイル名とパラメーター --keep-content を指定して管理 CLI undeploy コマンドを入力します。
    [standalone@localhost:9999 /] undeploy test-application.war --keep-content
    Copy to Clipboard Toggle word wrap

結果

指定のアプリケーションがアンデプロイされます。undeploy コマンドは、成功すると管理 CLI へ何も出力されないことに注意してください。

10.3.4. 管理 CLI を使用した管理対象ドメインでのアプリケーションのデプロイ

手順10.6 管理対象ドメインでのアプリケーションのデプロイ

  • デプロイ コマンドの実行

    管理 CLI で、アプリケーションのデプロイメントへのパスを指定して deploy コマンドを入力します。--all-server-groups パラメーターを指定してすべてのサーバーグループにデプロイします。
    [domain@localhost:9999 /] deploy /path/to/test-application.war --all-server-groups
    Copy to Clipboard Toggle word wrap
    • または、--server-groups パラメーターを使用して、デプロイメントの特定のサーバーグループを定義します。
      [domain@localhost:9999 /] deploy /path/to/test-application.war --server-groups=server_group_1,server_group_2
      Copy to Clipboard Toggle word wrap
    デプロイメントに成功しても CLI には何も出力されないことに注意してください。

結果

指定のアプリケーションが、管理対象ドメインのサーバーグループにデプロイされます。

10.3.5. 管理 CLI を使用した管理対象ドメインでのアプリケーションのアンデプロイ

手順10.7 管理対象ドメインでのアプリケーションのアンデプロイ

  • undeploy コマンドの実行

    管理 CLI で、アプリケーションのデプロイメントのファイル名を指定して undeploy コマンドを入力します。--all-relevant-server-groups パラメーターを追加して、最初にデプロイしたサーバーグループからアプリケーションをアンデプロイできます。
    [domain@localhost:9999 /] undeploy test-application.war --all-relevant-server-groups
    Copy to Clipboard Toggle word wrap
    アンデプロイメントに成功すると、CLI へ出力されません。

結果

指定のアプリケーションがアンデプロイされます。

10.4. HTTP API を用いたデプロイ

10.4.1. HTTP API を使用したアプリケーションのデプロイ

概要

以下の手順に従って、HTTP API よりアプリケーションをデプロイできます。

前提条件

手順10.8 HTTP API を使用したアプリケーションのデプロイ

  • 要件に関連する deploy または undeploy コマンドのいずれかを使用します。

    例10.2 デプロイおよびアンデプロイコマンド

    Deploy
    ------------------------------
    curl --digest -L -D - http://<host>:<port>/management --header "Content-Type: application/json" -d '{"operation" : "composite", "address" : [], "steps" : [{"operation" : "add", "address" : {"deployment" : "<runtime-name>"}, "content" : [{"url" : "file:<path-to-archive>}]},{"operation" : "deploy", "address" : {"deployment" : "<runtime-name>"}}],"json.pretty":1}' -u <user>:<pass>
    
    Example:
    -------
    curl --digest -L -D - http://localhost:9990/management --header "Content-Type: application/json" -d '{"operation" : "composite", "address" : [], "steps" : [{"operation" : "add", "address" : {"deployment" : "example.war"}, "content" : [{"url" : "file:/home/$user/example.war"}]},{"operation" : "deploy", "address" : {"deployment" : "example.war"}}],"json.pretty":1}' -u user:password
    
    
    Undeploy
    ------------------------------
    curl --digest -L -D - http://<host>:<port>/management --header "Content-Type: application/json" -d '{"operation" : "composite", "address" : [], "steps" : [{"operation" : "undeploy", "address" : {"deployment" : "<runtime-name>"}},{"operation" : "remove", "address" : {"deployment" : "<runtime-name>"}}],"json.pretty":1}' -u <user>:<pass>
    
    Example:
    -------
    curl --digest -L -D - http://localhost:9990/management --header "Content-Type: application/json" -d '{"operation" : "composite", "address" : [], "steps" : [{"operation" : "undeploy", "address" : {"deployment" : "example.war"}},{"operation" : "remove", "address" : {"deployment" : "example.war"}}],"json.pretty":1}' -u user:password
    
    Copy to Clipboard Toggle word wrap
注記
JSON 要求をプログラムで生成する方法の詳細は、を参照してください https://access.redhat.com/solutions/82463

10.5. デプロイメントスキャナーでのデプロイ

10.5.1. デプロイメントスキャナーでのアプリケーションデプロイメント管理

デプロイメントスキャナーを介してスタンドアロンサーバーインスタンスにアプリケーションをデプロイすると、迅速な開発サイクルに適した方法でアプリケーションをビルドし、テストすることができます。デプロイメントスキャナーは、さまざまなアプリケーションタイプのデプロイメント頻度や動作にニーズに合わせて設定することができます。

概要

このタスクは、デプロイメントスキャナーを使用してスタンドアロンサーバーインスタンスにアプリケーションをデプロイする方法を説明します。「アプリケーションデプロイメント 」 トピックで説明されているように、この方法は開発者の利便性のために保持され、本番稼働環境でのアプリケーション管理には管理コンソールと管理 CLI の方法が推奨されます。

手順10.9 デプロイメントスキャナーを使用したアプリケーションのデプロイ

  1. デプロイメントフォルダーへのコンテンツのコピー

    アプリケーションファイルを EAP_HOME/standalone/deployments/ にあるデプロイメントフォルダーにコピーします。
  2. デプロイメントスキャンモード

    アプリケーションのデプロイメント方法は 2 つあります。自動デプロイメントスキャナーモードと手動のデプロイメントスキャナーモードを選択できます。デプロイメント方法のいずれかを開始する前に、「管理 CLI でのデプロイメントスキャナーの設定」 を読んでください。
    • 自動デプロイメント

      デプロイメントスキャナーはフォルダーの状態の変更を選択し、「管理 CLI でのデプロイメントスキャナーの設定」 で定義されたマーカーファイルを作成します。
    • 手動デプロイメント

      デプロイメントスキャナーには、デプロイメントプロセスをトリガーするマーカーファイルが必要です。以下の例では、Unix touch コマンドを使用して新しい .dodeploy ファイルを作成します。

      例10.3 touch コマンドを使用したデプロイ

      [user@host bin]$ touch $EAP_HOME/standalone/deployments/example.war.dodeploy
      Copy to Clipboard Toggle word wrap

結果

アプリケーションファイルがアプリケーションサーバーにデプロイされます。デプロイメントフォルダーにマーカーファイルが作成され、デプロイメントが成功したことを示し、アプリケーションは管理コンソールで Enabled とフラグが付けられます。

例10.4 デプロイメント後のデプロイメントフォルダーコンテンツ

example.war
example.war.deployed
Copy to Clipboard Toggle word wrap

概要

このタスクでは、デプロイメントスキャナーでデプロイされたスタンドアロンサーバーインスタンスからアプリケーションをアンデプロイする方法を説明します。「アプリケーションデプロイメント 」 トピックで説明されているように、この方法は開発者の利便性のために保持され、本番稼働環境でのアプリケーション管理には管理コンソールと管理 CLI の方法が推奨されます。

注記
デプロイメントスキャナーは、アプリケーション管理の他のデプロイメント方法と併用しないでください。管理コンソールでアプリケーションサーバーから削除されたアプリケーションは、deployment ディレクトリーに含まれるマーカーファイルやアプリケーションに影響を与えずにランタイムから削除されます。誤ってリダクションやその他のエラーのリスクを最小限に抑えるには、実稼働環境で管理 CLI と管理コンソールを使用します。

手順10.10 以下の方法の 1 つを用いたアプリケーションのアンデプロイ

  • アプリケーションのアンデプロイ

    アプリケーションをデプロイする方法は 2 つありますが、アプリケーションをデプロイメントフォルダーから削除する場合と、デプロイメントの状態のみを変更する場合によって、使用する方法が異なります。
    • マーカーファイルの削除によるアンデプロイ

      デプロイされたアプリケーションの example.war.deployed マーカーファイルを削除し、ランタイムからアプリケーションのアンデプロイを開始するためにデプロイメントスキャナーをトリガーします。
      結果
      デプロイメントスキャナーはアプリケーションをアンデプロイし、example.war.undeployed マーカーファイルを作成します。アプリケーションはデプロイメントフォルダーに残ります。
    • アプリケーションの削除によるアンデプロイ

      注記
      この方法を使用した展開形式の WAR ファイルのアンデプロイは有効ではありません。マーカーファイルを削除してアンデプロイメントのみが有効になります。展開形式の WAR ファイルをアンデプロイしようとすると、以下のメッセージがログに記録されます。
      WARN  [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 2) JBAS015006: The deployment scanner found that the content for exploded deployment EXAMPLE.war has been deleted, but auto-deploy/undeploy for exploded deployments is not enabled and the EXAMPLE.war.deployed marker file for this deployment has not been removed. As a result, the deployment is not being undeployed, but resources needed by the deployment may have been deleted and application errors may occur. Deleting the EXAMPLE.war.deployed marker file to trigger undeploy is recommended.
      Copy to Clipboard Toggle word wrap
      デプロイメントディレクトリーからアプリケーションを削除して、ランタイムからアプリケーションのアンデプロイを開始するためにデプロイメントスキャナーをトリガーします。
      結果
      デプロイメントスキャナーはアプリケーションをアンデプロイし、filename.filetype.undeployed マーカーファイルを作成します。アプリケーションはデプロイメントフォルダーに存在しません。

結果

アプリケーションファイルはアプリケーションサーバーからアンデプロイされ、管理コンソールの Deployments 画面に表示されません。

概要

このタスクでは、デプロイメントスキャナーを使用してデプロイされたスタンドアロンサーバーインスタンスにアプリケーションを再デプロイする方法を説明します。「アプリケーションデプロイメント 」 トピックで説明されているように、この方法は開発者の利便性のために保持され、本番稼働環境でのアプリケーション管理には管理コンソールと管理 CLI の方法が推奨されます。

手順10.11 アプリケーションをスタンドアロンサーバーへ再デプロイ

  • アプリケーションの再デプロイ

    デプロイメントスキャナーを使用してデプロイされたアプリケーションを再デプロイするには、3 つの方法があります。これらの方法は、デプロイメントスキャナーをトリガーしてデプロイメントサイクルを開始し、個人設定に合わせて選択できます。
    • マーカーファイルの変更による再デプロイ

      マーカーファイルのアクセスおよび変更のタイムスタンプを変更して、デプロイメントスキャナーの再デプロイメントをトリガーします。以下の Linux の例では、Unix touch コマンドが使用されています。

      例10.5 Unix touch コマンドを使用した再デプロイ

      [user@host bin]$ touch EAP_HOME/standalone/deployments/example.war.dodeploy
      Copy to Clipboard Toggle word wrap

      結果

      デプロイメントスキャナーはマーカーファイルの変更を検出し、アプリケーションを再デプロイします。新しい .deployed ファイルマーカーが、以前のファイルマーカーに置き換わります。

    • 新しい .dodeploy マーカーファイルの作成による再デプロイ

      新しい .dodeploy マーカーファイルを作成して、デプロイメントスキャナーの再デプロイメントをトリガーします。「デプロイメントスキャナーを使用してスタンドアロンサーバーインスタンスにアプリケーションをデプロイ」 の手動デプロイメント手順を参照してください。
    • マーカーファイルの削除による再デプロイ

      「デプロイメントスキャナーマーカーファイルのリファレンス」 で説明されているように、デプロイされたアプリケーションの .deployed マーカーファイルを削除すると、アンデプロイメントがトリガーされ、.undeployed マーカーが作成されます。デプロイメント解除マーカーを削除すると、デプロイメントサイクルが再びトリガーされます。詳細は、「デプロイメントスキャナーを使用してスタンドアロンサーバーインスタンスからアプリケーションをアンデプロイ」 を参照してください。

結果

アプリケーションファイルが再デプロイされます。

10.5.5. デプロイメントスキャナーマーカーファイルのリファレンス

マーカーファイル

マーカーファイルは、デプロイメントスキャナーサブシステムの一部です。これらのファイルは、スタンドアロンサーバーインスタンスのデプロイメントディレクトリー内のアプリケーションの状態をマークします。マーカーファイルの名前はアプリケーションと同じで、ファイル接尾辞はアプリケーションのデプロイメントの状態を示します。以下の表は、各マーカーファイルのタイプおよび応答を定義します。

例10.6 マーカーファイル例

以下の例は、testapplication.war という名前のアプリケーションの正常にデプロイされたインスタンスのマーカーファイルを示しています。
testapplication.war.deployed
Copy to Clipboard Toggle word wrap
Expand
表10.1 マーカーファイルタイプ定義
ファイル名接尾辞 生成 説明
.dodeploy ユーザー生成 コンテンツをランタイムにデプロイまたは再デプロイする必要があることを示します。
.skipdeploy ユーザー生成 アプリケーションの自動デプロイを無効にします。展開形式のコンテンツの自動デプロイメントを一時的にブロックする方法として役に立ち、不完全なコンテンツの編集がライブにプッシュするリスクを防ぎます。スキャナーは zip 形式のコンテンツに対する処理中の変更を検出し、完了するまで待機しますが、zip 形式のコンテンツとともに使用できます。
.isdeploying システム生成 デプロイメントの開始を示します。デプロイメントプロセスが完了すると、マーカーファイルが削除されます。
.deployed システム生成 コンテンツがデプロイされたことを示します。このファイルが削除された場合、コンテンツはアンデプロイされます。
.failed システム生成 デプロイメントの失敗を示します。マーカーファイルには、失敗の原因に関する情報が含まれます。マーカーファイルが削除されると、コンテンツは再度自動デプロイメントに表示されます。
.isundeploying システム生成 .deployed ファイルの削除に対する応答を示します。コンテンツはアンデプロイされ、完了時にマーカーは自動的に削除されます。
.undeployed システム生成 コンテンツがアンデプロイされたことを示します。マーカーファイルを削除しても、コンテンツの再デプロイメントには影響はありません。
.pending システム生成 デプロイメントの指示が、検出された問題の解決を保留しているサーバーに送信されることを示します。このマーカーはグローバルデプロイメントロードブロックとして機能します。この状態が存在する場合、スキャナーは他のコンテンツをデプロイまたはアンデプロイするようサーバーに指示しません。

10.5.6. デプロイメントスキャナー属性のリファレンス

デプロイメントスキャナーには、管理 CLI に公開された以下の属性が含まれ、write-attribute 操作を使用して設定できます。設定オプションの詳細は、「管理 CLI でのデプロイメントスキャナーの設定」 のトピックを参照してください。
Expand
表10.2 デプロイメントスキャナーの属性
名前 詳細 タイプ デフォルト値
auto-deploy-exploded .dodeploy マーカーファイルなしで、展開形式のコンテンツの自動デプロイメントを許可します。基本的な開発シナリオに対してのみ推奨され、開発者またはオペレーティングシステムによる変更中に、展開形式のアプリケーションデプロイメントが行われないようにします。 ブール値 False
auto-deploy-xml .dodeploy マーカーファイルなしでの XML コンテンツの自動デプロイメントを許可します。 ブール値 True
auto-deploy-zipped .dodeploy マーカーファイルなしでの zip 形式のコンテンツの自動デプロイメントを許可します。 ブール値 True
deployment-timeout デプロイメントスキャナーでデプロイメントをキャンセルするまでのデプロイメント試行許可時間 (秒単位)。 Long 600
path スキャンする実際のファイルシステムパスを定義します。relative-to 属性を指定すると、path の値は、そのディレクトリーまたはパスに対する相対追加として機能します。 文字列 デプロイメント
relative-to サーバー設定 XML ファイルの paths セクションで定義されたファイルシステムパスへの参照。 文字列 jboss.server.base.dir
scan-enabled scan-interval により起動時にアプリケーションの自動スキャンを許可します。 ブール値 True
scan-interval リポジトリーのスキャン間隔(ミリ秒単位)。1 未満の値の場合、スキャナーは起動時にのみ動作します。 Int 5000

10.5.7. デプロイメントスキャナーの設定

デプロイメントスキャナーは管理コンソールまたは管理 CLI を使用して設定できます。新しいデプロイメントスキャナーを作成したり、既存のスキャナー属性を管理したりできます。これには、スキャンの間隔、デプロイメントフォルダーの場所、およびデプロイメントをトリガーするアプリケーションファイルタイプが含まれます。

10.5.8. 管理 CLI でのデプロイメントスキャナーの設定

概要

デプロイメントスキャナーを設定する方法は複数ありますが、管理 CLI を使用してバッチスクリプトを使用するか、リアルタイムで属性を公開および変更できます。read-attribute および write-attribute global コマンドライン操作を使用すると、デプロイメントスキャナーの動作を変更できます。デプロイメントスキャナー属性の詳細は、「デプロイメントスキャナー属性のリファレンス」 トピックで定義されています。

デプロイメントスキャナーは JBoss EAP 6 のサブシステムで、standalone.xml で表示できます。

例10.7 Excerpt from standalone.xml

<subsystem xmlns="urn:jboss:domain:deployment-scanner:1.1">
    <deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000"/>
</subsystem>
Copy to Clipboard Toggle word wrap

手順10.12 デプロイメントスキャナーの設定

  1. 設定するデプロイメントスキャナー属性の決定

    管理 CLI でデプロイメントスキャナーを設定するには、最初に正しい属性名を公開する必要があります。これは、ルートノードのいずれかで read-resources 操作を使用するか、cd コマンドを使用してサブシステムの子ノードに変更します。このレベルで ls コマンドを使用して、属性を表示できます。
    • read-resource 操作を使用したデプロイメントスキャナー属性の公開

      read-resource 操作を使用して、デフォルトのデプロイメントスキャナーリソースで定義された属性を公開します。

      例10.8 read-resource 出力サンプル

      [standalone@localhost:9999 /]/subsystem=deployment-scanner/scanner=default:read-resource
      {
          "outcome" => "success",
          "result" => {
              "auto-deploy-exploded" => false,
              "auto-deploy-xml" => true,
              "auto-deploy-zipped" => true,
              "deployment-timeout" => 600,
              "path" => "deployments",
              "relative-to" => "jboss.server.base.dir",
              "scan-enabled" => true,
              "scan-interval" => 5000
          }
      }
      Copy to Clipboard Toggle word wrap
    • ls コマンドを使用したデプロイメントスキャナー属性の公開

      ls コマンドに -l オプションの引数を指定して、サブシステムノード属性、値、およびタイプを含む結果の表を表示します。 ls --help と入力して、CLI ヘルプエントリーを公開すると、ls コマンドとその引数を確認できます。管理 CLI のヘルプメニューの詳細は、「管理 CLI でのヘルプの取得」 のトピックを参照してください。

      例10.9 ls -l の出力例

      [standalone@localhost:9999 /] ls -l /subsystem=deployment-scanner/scanner=default
      ATTRIBUTE            VALUE                 TYPE    
      auto-deploy-exploded false                 BOOLEAN 
      auto-deploy-xml      true                  BOOLEAN 
      auto-deploy-zipped   true                  BOOLEAN 
      deployment-timeout   600                   LONG    
      path                 deployments           STRING  
      relative-to          jboss.server.base.dir STRING  
      scan-enabled         true                  BOOLEAN 
      scan-interval        5000                  INT
      Copy to Clipboard Toggle word wrap
  2. write-attribute 操作を使用したデプロイメントスキャナーの設定

    変更する属性の名前を決定したら、write-attribute を使用して属性名と、書き込む新しい値を指定します。以下の例はすべて子ノードレベルで実行されます。これは、cd コマンドおよびタブ補完を使用してデフォルトのスキャナーノードを公開および変更することでアクセスできます。
    [standalone@localhost:9999 /] cd subsystem=deployment-scanner/scanner=default
    Copy to Clipboard Toggle word wrap
    1. 展開されたコンテンツの自動デプロイメントの有効化

      write-attribute 操作を使用して、展開形式のアプリケーションコンテンツの自動デプロイメントを有効にします。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=auto-deploy-exploded,value=true)
      {"outcome" => "success"}
      Copy to Clipboard Toggle word wrap
    2. XML コンテンツの自動デプロイメントの無効化

      write-attribute 操作を使用して、XML アプリケーションコンテンツの自動デプロイメントを無効にします。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=auto-deploy-xml,value=false)     
      {"outcome" => "success"}
      Copy to Clipboard Toggle word wrap
    3. zip 形式のコンテンツの自動デプロイメントの無効化

      write-attribute コマンドを使用して、zip 形式のアプリケーションコンテンツの自動デプロイメントを無効にします。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=auto-deploy-zipped,value=false)
      {"outcome" => "success"}
      Copy to Clipboard Toggle word wrap
    4. パス属性の設定

      write-attribute 操作を使用してパス属性を変更し、監視するデプロイメントスキャナーの新しいパス名の newpathname 値を置き換えます。変更を反映するには、サーバーのリロードが必要なことに注意してください。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=path,value=newpathname)            
      {
          "outcome" => "success",
          "response-headers" => {
              "operation-requires-reload" => true,
              "process-state" => "reload-required"
          }
      }
      Copy to Clipboard Toggle word wrap
    5. 相対パス属性の設定

      write-attribute 操作を使用して、設定 XML ファイルの paths セクションで定義されたファイルシステムパスへの相対参照を変更します。変更を反映するには、サーバーのリロードが必要なことに注意してください。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=relative-to,value=new.relative.dir)
      {
          "outcome" => "success",
          "response-headers" => {
              "operation-requires-reload" => true,
              "process-state" => "reload-required"
          }
      }
      Copy to Clipboard Toggle word wrap
    6. デプロイメントスキャナーの無効化

      scan -enabled の値を false に設定して、Write-attribute 操作を使用してデプロイメントスキャナーを無効にします。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=scan-enabled,value=false)        
      {"outcome" => "success"}
      Copy to Clipboard Toggle word wrap
    7. スキャン間隔の変更

      write-attribute 操作を使用してスキャン間隔を 5000 ミリ秒から 10000 ミリ秒に変更します。
      [standalone@localhost:9999 scanner=default] :write-attribute(name=scan-interval,value=10000)
      {"outcome" => "success"}
      Copy to Clipboard Toggle word wrap

結果

設定の変更が、デプロイメントスキャナーに保存されます。

10.5.9. カスタムデプロイメントスキャナーの定義

概要

管理コンソールまたは管理 CLI を使用して新しいデプロイメントスキャナーを追加できます。デプロイメントを確認するためにスキャンする新しいディレクトリーを定義します。デフォルトのデプロイメントスキャナーは EAP_HOME/standalone/deployments/ を監視します。既存のデプロイメントスキャナーの設定に関する詳細は、「管理 CLI でのデプロイメントスキャナーの設定」 を参照してください。

手順10.13 管理 CLI でのカスタムデプロイメントスキャナーの定義

  1. 管理 CLI の add 操作を使用してデプロイメントスキャナーを追加します。
    [standalone@localhost:9999 /] /subsystem=deployment-scanner/scanner=new-scanner:add(path=new_deployment_dir,relative-to=jboss.server.base.dir,scan-interval=5000)
    {"outcome" => "success"}
    Copy to Clipboard Toggle word wrap
    注記
    指定のディレクトリーがすでに存在しないと、このコマンドに失敗し、エラーが発生します。
  2. 新しいデプロイメントスキャナーが standalone.xml ファイルおよび管理インターフェースに表示されるようになりました。

    例10.10 からの抜粋 standalone.xml

    <subsystem xmlns="urn:jboss:domain:deployment-scanner:1.1">
    	<deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000"/>
    	<deployment-scanner name="new-scanner" path="new_deployment_dir" relative-to="jboss.server.base.dir" scan-interval="5000"/>
    </subsystem>
    Copy to Clipboard Toggle word wrap
  3. デプロイメント用に指定のディレクトリーがスキャンされるようになりました。デプロイメントスキャナーを使用してアプリケーションをデプロイする方法は、「デプロイメントスキャナーを使用してスタンドアロンサーバーインスタンスにアプリケーションをデプロイ」 を参照してください。

結果

新しいデプロイメントスキャナーが定義され、デプロイメントの監視が行われています。

10.6. Maven でのデプロイ

10.6.1. Maven によるアプリケーションデプロイメントの管理

Maven を使用してアプリケーションをデプロイすると、デプロイメントのサイクルを既存の開発ワークフローの一部として取り入れることができます。

10.6.2. Maven によるアプリケーションのデプロイ

概要

このタスクでは、Maven を使用してアプリケーションをデプロイする方法を説明します。提供されている例では、JBoss EAP 6 のクイックスタートコレクションにある jboss-helloworld.war アプリケーションを使用します。helloworld プロジェクトには、jboss-as-maven-plugin を初期化する POM ファイルが含まれています。このプラグインは、アプリケーションサーバーとの間でアプリケーションをデプロイおよびアンデプロイする簡単な操作を提供します。

手順10.14 Maven によるアプリケーションのデプロイ

  1. ターミナルセッションを開き、quickstart サンプルが含まれるディレクトリーに移動します。

    例10.11 helloworld アプリケーションディレクトリーへの移動

    [localhost]$ cd /QUICKSTART_HOME/helloworld
    
    Copy to Clipboard Toggle word wrap
  2. Maven デプロイコマンドを実行してアプリケーションをデプロイします。アプリケーションがすでに実行されている場合、これは再デプロイされます。
    [localhost]$ mvn package jboss-as:deploy
    Copy to Clipboard Toggle word wrap
  3. 結果を確認します。
    • デプロイメントは、ターミナルウィンドウで操作ログを参照して確認できます。

      例10.12 Maven での helloworld アプリケーションの確認

                              
      [INFO] ------------------------------------------------------------------------
      [INFO] BUILD SUCCESS
      [INFO] ------------------------------------------------------------------------
      [INFO] Total time: 32.629s
      [INFO] Finished at: Fri Mar 14 09:09:50 EDT 2014
      [INFO] Final Memory: 23M/204M
      [INFO] ------------------------------------------------------------------------
      
      Copy to Clipboard Toggle word wrap
    • また、デプロイメントは、アクティブアプリケーションサーバーインスタンスのステータスストリームで確認することもできます。

      例10.13 アプリケーションサーバーでの helloworld アプリケーションの確認

      09:09:49,167 INFO  [org.jboss.as.repository] (management-handler-thread - 1) JBAS014900: Content added at location /home/username/EAP_HOME/standalone/data/content/32/4b4ef9a4bbe7206d3674a89807203a2092fc70/content
      09:09:49,175 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-7) JBAS015876: Starting deployment of "jboss-helloworld.war" (runtime-name: "jboss-helloworld.war")
      09:09:49,563 INFO  [org.jboss.weld.deployer] (MSC service thread 1-8) JBAS016002: Processing weld deployment jboss-helloworld.war
      09:09:49,611 INFO  [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016005: Starting Services for CDI deployment: jboss-helloworld.war
      09:09:49,680 INFO  [org.jboss.weld.Version] (MSC service thread 1-1) WELD-000900 1.1.17 (redhat)
      09:09:49,705 INFO  [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016008: Starting weld service for deployment jboss-helloworld.war
      09:09:50,080 INFO  [org.jboss.web] (ServerService Thread Pool -- 55) JBAS018210: Register web context: /jboss-helloworld
      09:09:50,425 INFO  [org.jboss.as.server] (management-handler-thread - 1) JBAS018559: Deployed "jboss-helloworld.war" (runtime-name : "jboss-helloworld.war")
      Copy to Clipboard Toggle word wrap

結果

アプリケーションが、アプリケーションサーバーにデプロイされます。

10.6.3. Maven によるアプリケーションのアンデプロイ

概要

このタスクでは、Maven を使用してアプリケーションをアンデプロイする方法を示します。提供されている例では、JBoss EAP 6 のクイックスタートコレクションにある jboss-helloworld.war アプリケーションを使用します。helloworld プロジェクトには、jboss-as-maven-plugin を初期化する POM ファイルが含まれています。このプラグインは、アプリケーションサーバーとの間でアプリケーションをデプロイおよびアンデプロイする簡単な操作を提供します。

手順10.15 Maven によるアプリケーションのアンデプロイ

  1. ターミナルセッションを開き、quickstart サンプルが含まれるディレクトリーに移動します。

    例10.14 helloworld アプリケーションディレクトリーへの移動

    [localhost]$ cd /QUICKSTART_HOME/helloworld
    
    Copy to Clipboard Toggle word wrap
  2. Maven アンデプロイコマンドを実行してアプリケーションをアンデプロイします。
    [localhost]$ mvn jboss-as:undeploy
    Copy to Clipboard Toggle word wrap
  3. 結果を確認します。
    • アンデプロイメントは、ターミナルウィンドウの操作ログを参照して確認できます。

      例10.15 Maven による helloworld アプリケーションのアンデプロイの確定

      [INFO] ------------------------------------------------------------------------
      [INFO] BUILD SUCCESSFUL
      [INFO] ------------------------------------------------------------------------
      [INFO] Total time: 1 second
      [INFO] Finished at: Mon Oct 10 17:33:02 EST 2011
      [INFO] Final Memory: 11M/212M
      [INFO] ------------------------------------------------------------------------
      Copy to Clipboard Toggle word wrap
    • また、アンデプロイメントは、アクティブアプリケーションサーバーインスタンスのステータスストリームで確認することもできます。

      例10.16 アプリケーションサーバーによる helloworld アプリケーションのアンデプロイの確定

      09:51:40,512 INFO  [org.jboss.web] (ServerService Thread Pool -- 69) JBAS018224: Unregister web context: /jboss-helloworld
      09:51:40,522 INFO  [org.jboss.weld.deployer] (MSC service thread 1-3) JBAS016009: Stopping weld service for deployment jboss-helloworld.war
      09:51:40,536 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment jboss-helloworld.war (runtime-name: jboss-helloworld.war) in 27ms
      09:51:40,621 INFO  [org.jboss.as.repository] (management-handler-thread - 10) JBAS014901: Content removed from location /home/username/EAP_HOME/jboss-eap-6.4/standalone/data/content/44/e1f3c55c84b777b0fc201d69451223c09c9da5/content
      09:51:40,621 INFO  [org.jboss.as.server] (management-handler-thread - 10) JBAS018558: Undeployed "jboss-helloworld.war" (runtime-name: "jboss-helloworld.war")
      
      Copy to Clipboard Toggle word wrap

結果

アプリケーションが、アプリケーションサーバーからアンデプロイされます。

10.7. JBoss EAP 6 にデプロイされたアプリケーションの順序制御

JBoss EAP 6 では、サーバーの起動時にアプリケーションのデプロイメント順序を細かく制御できます。複数の ear ファイルに存在するアプリケーションのデプロイメント順序を厳格に有効にし、再起動後に順序を永続化できます。

手順10.16 EAP 6.0 におけるデプロイメント順序の制御

  1. サーバーの起動または停止時に、順番にアプリケーションをデプロイおよびアンデプロイする CLI スクリプトを作成します。
  2. CLI はバッチモードの概念もサポートします。バッチモードでは、コマンドおよび操作をグループ化し、それらをアトミックユニットとして一緒に実行できます。少なくとも 1 つのコマンドまたは操作が失敗すると、バッチで正常に実行された他のコマンドおよび操作はすべてロールバックされます。

手順10.17 EAP 6.1 以降におけるデプロイメント順序の制御

EAP 6.1 以降では、Inter Deployment Dependencies を使用すると、トップレベルのデプロイメント間で依存関係を宣言できます。
  1. app.ear/META-INF フォルダーの jboss-all.xml ファイルを作成し(存在しない場合)。app.ear は、デプロイする別のアプリケーションアーカイブに依存するアプリケーションアーカイブです。
  2. 以下のように、このファイルに jboss-deployment-dependencies エントリーを作成します。以下の一覧で、framework.ear は、app.ear アプリケーションアーカイブの前にデプロイされる必要がある依存関係アプリケーションアーカイブであることに注意してください。
    <jboss umlns="urn:jboss:1.0">
      <jboss-deployment-dependencies xmlns="urn:jboss:deployment-dependencies:1.0">
        <dependency name="framework.ear" />
      </jboss-deployment-dependencies>
    </jboss>
    Copy to Clipboard Toggle word wrap
    注記
    デプロイメントのランタイム名を jboss-all.xml ファイルの依存関係名として使用できます。
    重要
    jboss-all.xml ファイルを使用すると、サーバーが検出しない依存関係を宣言できますが、厳密な順序付け機能ではありません。JBoss EAP は、jboss-all.xml ファイルに指定されたすべての依存関係がすでにデプロイ済みまたは利用できることを前提とします。不足している依存関係がある場合、JBoss EAP はそれらの依存関係を自動的にデプロイせず、デプロイメントは失敗します。

10.8. デプロイされたコンテンツ用のカスタムディレクトリーの定義

JBoss EAP には、サーバーがデプロイされたコンテンツを格納するために使用する場所を定義するオプションがあります。

スタンドアロンモードでコンテンツをデプロイするカスタムディレクトリーの定義

デフォルトでは、スタンドアロンモードにデプロイされているコンテンツは EAP_HOME/standalone/data/content ディレクトリーに保存されます。

  • この場所を変更するには、サーバーの起動時に -Djboss.server.deploy.dir 引数を渡します。
    ./standalone.sh -Djboss.server.deploy.dir=/path/to/new_deployed_content
    Copy to Clipboard Toggle word wrap
  • 選択する場所は JBoss EAP インスタンスすべてで一意になる必要があります。

注記
jboss.server.deploy.dir 管理コンソールまたは管理 CLI を使用してデプロイされたコンテンツの格納に使用されるディレクトリーを指定します。デプロイメントスキャナーによって監視されるカスタムデプロイメントディレクトリーを定義する場合は、「カスタムデプロイメントスキャナーの定義」 を参照してください。

ドメインモードでコンテンツをデプロイするカスタムディレクトリーの定義

デフォルトでは、ドメインモードにデプロイされたコンテンツは EAP_HOME/domain/data/content ディレクトリーに保存されます。

  • この場所を変更するには、ドメインの起動時に -Djboss.domain.deployment.dir 引数を渡します。
    ./domain.sh -Djboss.domain.deployment.dir=/path/to/new_deployed_content
    Copy to Clipboard Toggle word wrap
  • 選択する場所は JBoss EAP インスタンスすべてで一意になる必要があります。

10.9. デプロイメント記述子の上書き

JBoss EAP 6.1 以降では、実行時にデプロイメント記述子、JAR、クラス、JSP ページ、およびその他のファイルをオーバーライドできます。デプロイメントオーバーレイ は、アーカイブで上書きする必要のあるファイルのルールセットを表します。また、上書きされたファイルの代わりに使用する必要のある新しいファイルへのリンクも提供します。オーバーライドされるファイルがデプロイメントアーカイブに存在しない場合は、デプロイメントに戻ります。

手順10.18 管理 CLI を使用したデプロイメント記述子の上書き

以下の手順は、app.war という名前のデプロイされたアプリケーションがすでにあり、その WEB-INF/web.xml ファイルを /home/user/web.xml にある別の web.xml ファイルで上書きする必要があることを前提としています。
  1. デプロイメントオーバーレイを追加し、そこにコンテンツを追加します。これには、以下の 2 つの方法があります。
    • DMR ツリーの使用

      1. /deployment-overlay=myoverlay:add
        Copy to Clipboard Toggle word wrap
      2. /deployment-overlay=myoverlay/content=WEB-INF\/web.xml:add(content={url=file:///home/user/web.xml})
        Copy to Clipboard Toggle word wrap
        また、2 番目のステートメントを使用してコンテンツルールを追加できます。
    • 便利なメソッドの使用

      deployment-overlay add --name=myoverlay --content=WEB-INF/web.xml=/home/user/web.xml
      Copy to Clipboard Toggle word wrap
  2. オーバーレイをデプロイメントアーカイブにリンクします。これには、以下の 2 つの方法があります。
    • DMR ツリーの使用

      /deployment-overlay=myoverlay/deployment=app.war:add
      Copy to Clipboard Toggle word wrap
    • 便利なメソッドの使用

      deployment-overlay link --name=myoverlay --deployments=app.war
      Copy to Clipboard Toggle word wrap
      複数のアーカイブ名を指定するには、コンマで区切ります。
    デプロイメントアーカイブ名はサーバーに存在しないことに注意してください。名前を指定しますが、まだ実際のデプロイメントにリンクされていません。
  3. アプリケーションの再デプロイ

    /deployment=app.war:redeploy
    Copy to Clipboard Toggle word wrap

10.10. rollout Plan

10.10.1. ロールアウト計画

ドメインまたはホストレベルのリソースでターゲットとなる操作は、複数のサーバーに影響する可能性があります。このような操作には、サーバーに適用される操作の順序を説明する ロールアウト計画 や、一部のサーバーで実行に失敗した場合に操作を元に戻すかどうかの詳細を示すポリシーなどが含まれます。

例10.17 ロールアウト計画の CLI 形式

rollout (id=plan_id | server_group_list) [rollback-across-groups]

server_group_list := server_group [ (sequence_separator | concurrent_separator) server_group ]
sequence_separator := ','
concurrent_separator := '^'
server_group := server_group_name [group_policy_list]
group_policy_list := '(' policy_property_name=policy_property_value (, policy_property_name=policy_property_value)* ')'
policy_property_name := 'rolling-to-servers' | 'max-failed-servers' | 'max-failure-percentage'
Copy to Clipboard Toggle word wrap
policy_property_value の値はプロパティーによって異なります。ブール値や整数などにすることができます。
ロールアウト計画は長く、複雑になる可能性があります。ただし、ドメイン管理モデルの一部として保存し、名前(上記の定義の ID)を使用してコマンドおよび操作から後で参照することができます。保存されたロールアウト計画は rollout-plan コマンドを使用して管理されます。

例10.18 rollout-plan コマンドで管理されるロールアウト計画

rollout-plan add --name=my-plan --content={rollout main-server-group^other-server-group}
:write-attribute(name=my-attr,value=my-value){rollout id=my-plan}
Copy to Clipboard Toggle word wrap

例10.19 保存されたロールアウト計画の使用

rollout-plan add --name=my-plan --content={rollout main-server-group^other-server-group}
:write-attribute(name=my-attr,value=my-value){rollout id=my-plan}
Copy to Clipboard Toggle word wrap

10.10.2. ロールアウト計画を使用した操作

構造は、rollout-plan 内の operation です。
{
"operation" => "write-core-threads",
    "address" => [
        ("profile" => "production"),
        ("subsystem" => "threads"),
        ("bounded-queue-thread-pool" => "pool1")
    ],
    "count" => 0,
    "per-cpu" => 20,
    "operation-headers" => {
        "rollout-plan" => {
            "in-series" => [
                {
                    "concurrent-groups" => {
                        "groupA" => {
                            "rolling-to-servers" => true,
                            "max-failure-percentage" => 20
                        },
                        "groupB" => undefined
                    }
                },
                {
                   "server-group" => {
                        "groupC" => {
                            "rolling-to-servers" => false,
                            "max-failed-servers" => 1
                        }
                    }
                },
                {
                    "concurrent-groups" => {
                        "groupD" => {
                            "rolling-to-servers" => true,
                            "max-failure-percentage" => 20
                        },
                        "groupE" => undefined
                    }
                }
            ],
            "rollback-across-groups" => true
        }
    }
}
Copy to Clipboard Toggle word wrap
rollout-plan は、operation-headers 構造内で入れ子になっています。構造のルートノードは、2 つの子を許可します。
  • in-series - シリーズで実行するステップの一覧。各ステップは次のステップが実行される前に完了します。各ステップには、1 つ以上のサーバーグループのサーバーへの操作の適用が含まれます。リストの各要素の詳細は、以下を参照してください。
  • rollback-across-groups - 1 つのサーバーグループのすべてのサーバーで操作をロールバックする必要があるかどうかを示すブール値。すべてのサーバーグループでロールバックをトリガーします。これは任意の設定で、デフォルトは false に設定されます。
in-series ノード下のリストの各要素には、以下の構造の 1 つまたは他の構造が必要です。
  • concurrent-groups - サーバーグループに操作を適用する方法を制御するサーバーグループ名のマップ。マップの各サーバーグループに対して、操作を同時に適用することができます。server-group ポリシー設定の詳細は、以下を参照してください。
  • server-group - サーバーグループ名のキー/値から、そのサーバーグループに操作を適用する方法を制御するポリシーへの単一のキー/値マッピング。ポリシー設定の詳細は、以下を参照してください。(注意: 単一のエントリーを持つ、これと「concurrent-groups」マップとの間には、プラン実行の違いはありません。)
サーバーグループのサーバーに操作がどのように適用されるかを制御するポリシーには、以下の要素があります(それぞれは任意です)。
  • rolling-to-servers - true に設定すると、操作は連続してグループ内の各サーバーに適用されます。false を指定した場合、操作はグループのサーバーに同時に適用されます。
  • max-failed-servers - グループのすべてのサーバーで元に戻す前に、操作の適用に失敗したサーバーの最大数を取る整数。指定がない場合のデフォルト値はゼロです。つまり、サーバーがグループ全体でロールバックをトリガーします。
  • max-failure-percentage - 0 から 100 までの整数。グループ内のすべてのサーバーで元に戻す前に、操作の適用に失敗したサーバーの合計数の最大パーセンテージを取ります。指定がない場合のデフォルト値はゼロです。つまり、サーバーがグループ全体でロールバックをトリガーします。
max-failed-servers と max-failure-percentage の両方がゼロ以外の値に設定された場合、max-failure-percentage が優先されます。
上記の(簡単な)の例を見ると、ドメインのサーバーへの操作の適用は 3 つのフェーズで実行されます。あるサーバーグループのポリシーによってサーバーグループ全体で操作のロールバックが引き起こされると、他のサーバーグループもすべてロールバックされます。3 つのフェーズは次のとおりです。
  1. サーバーグループ groupA と groupB には同時に操作が適用されます。groupA のサーバーには操作が順次適用され、groupB のすべてのサーバーは操作を同時に処理します。groupA で操作の適用に失敗したサーバーが 20 % を超えると、グループ全体でロールバックが実行されます。groupB で操作を適用できなかったサーバーがあると、そのグループ全体でロールバックが実行されます。
  2. groupA および groupB のすべてのサーバーが完了すると、groupC のサーバーに操作が適用されます。これらのサーバーは操作を同時に処理します。groupC で操作を適用できなかったサーバーが複数ある場合は、グループ全体でロールバックが実行されます。
  3. groupC のすべてのサーバーが完了すると、サーバーグループ groupD と groupE の操作は同時に適用されます。groupD のサーバーには操作が順次適用され、groupE のすべてのサーバーは操作を同時に処理します。groupD で操作の適用に失敗したサーバーが 20 % を超えると、グループ全体でロールバックが実行されます。groupE で操作を適用できなかったサーバーがあると、そのグループ全体でロールバックが実行されます。

デフォルトのロールアウト計画

複数のサーバーに影響する操作はすべてロールアウト計画を使用して実行されます。ただし、実際には操作リクエストでロールアウト計画を指定する必要はありません。rollout-plan が指定されていない場合、デフォルトのプランが生成されます。プランには以下の特徴があります。

  • ハイレベルなフェーズは 1 つのみです。操作に影響するすべてのサーバーグループには同時に操作が適用されます。
  • 各サーバーグループ内では、操作がすべてのサーバーに同時に適用されます。
  • サーバーグループのいずれかのサーバーに操作を適用できないと、グループ全体でロールバックが実行されます。
  • あるサーバーグループに操作を適用できないと、他のすべてのサーバーグループでロールバックが実行されます。

10.10.3. デプロイメント計画の作成

JBoss EAP 6 のクラスター化ドメインにアプリケーションをデプロイするデプロイメントプランの作成方法
  1. rolling-to-servers=true を指定して CLI を使用してロールアウトデプロイメントプランを作成します。パッケージは、サーバーグループの各サーバーに順次デプロイされます。
    シリアルデプロイメント用の CLI デプロイメントプランの例を以下に示します。
    deploy ClusterWebApp.war --name=ClusterWebApp.war --runtime-name=ClusterWebApp.war --server-groups=ha-server-group --headers={rollout ha-server-group(rolling-to-servers=true)}
    
    Copy to Clipboard Toggle word wrap
  2. すべてのサーバーグループにロールアウト計画を適用するには、マスターホストの各 server-group の名前を指定する必要があります。
    deploy /NotBackedUp/PREVIOUS/ALLWAR/ClusterWebApp.war --name=ClusterWebApp.war --runtime-name=ClusterWebApp.war --server-groups=main-server-group,other-server-group --headers={rollout main-server-group(rolling-to-servers=true),other-server-group(rolling-to-servers=true)}
    
    Copy to Clipboard Toggle word wrap

第11章 サブシステムの設定

11.1. サブシステム設定の概要

はじめに

JBoss EAP 6 は簡単な設定を使用し、ドメインごとまたはスタンドアロンサーバーごとに 1 つの設定ファイルを使用します。ドメインモードでは、各ホストコントローラーにも個別のファイルが存在します。設定の変更は自動的に保持されるため、XML 設定ファイルは手動で編集しないでください。設定はスキャンされ、管理 API によって自動的に上書きされます。コマンドラインベースの管理 CLI および Web ベースの管理コンソールを使用すると、JBoss EAP 6 の各側面を設定できます。

JBoss EAP 6 は、モジュラークラスローディングの概念に基づいて構築されます。Platform が提供する各 API またはサービスはモジュールとして実装され、必要に応じてロードおよびアンロードされます。ほとんどのモジュールには、サブシステムと呼ばれる設定可能な要素が含まれています。サブシステム設定情報は、管理対象ドメインの場合は EAP_HOME/domain/configuration/domain.xml、スタンドアロンサーバーの場合は EAP_HOME/standalone/configuration/standalone.xml に保存されます。サブシステムの多くには、以前のバージョンの JBoss EAP でデプロイメント記述子を介して設定された設定の詳細が含まれます。

サブシステム設定スキーマ

各サブシステムの設定は XML スキーマで定義されます。設定スキーマは、インストールの EAP_HOME/docs/schema/ ディレクトリーにあります。

第12章 ロギングサブシステム

12.1. はじめに

12.1.1. ロギングの概要

JBoss EAP 6 は、独自の内部使用とデプロイされたアプリケーションによる使用の両方で設定可能なロギング機能を提供します。logging サブシステムは JBoss LogManager をベースとしており、JBoss Logging だけでなくサードパーティーのアプリケーションロギングフレームワークを複数サポートします。
logging サブシステムはログカテゴリーおよびログハンドラーのシステムを使用して設定されます。ログカテゴリーはキャプチャーするメッセージを定義し、ログハンドラーはこれらのメッセージの処理方法(ディスクへの書き込み、コンソールへの送信など)を定義します。
ロギングプロファイルを使用すると、一意に名前付きのロギング設定のセットを作成し、他のロギング設定とは関係なくアプリケーションに割り当てることができます。ロギングプロファイルの設定はメインの logging サブシステムとほぼ同じです。

12.1.2. JBoss LogManager でサポートされるアプリケーションロギングフレームワーク

JBoss LogManager は次のロギングフレームワークをサポートします。
JBoss LogManager では以下の API がサポートされます。
  • java.util.logging
  • JBoss Logging
  • Log4j
  • SLF4J
  • commons-logging
JBoss LogManager では以下の SPI もサポートされます。
  • java.util.logging Handler
  • Log4j Appender
注記
Log4j APILog4J Appender を使用している場合、オブジェクトは渡される前に string に変換されます。

12.1.3. 起動時のロギング

JBoss EAP の起動中に、Java 環境と各サービスの起動に関するログエントリーが出力されます。ログは、トラブルシューティング時に役に立ちます。デフォルトでは、すべてのログエントリーはファイル server.log に書き込まれます。これはランタイムモードに依存する場所です。
スタンドアロンモード
EAP_HOME/standalone/log/server.log
ドメインモード
EAP_HOME/domain/servers/SERVER_NAME/log/server.log
起動ロギングの設定は、設定ファイル logging.properties に指定されます。これはランタイムモードに依存する場所です。
スタンドアロンモード
EAP_HOME/standalone/configuration/logging.properties
ドメインモード
ドメインモードでは、ドメインコントローラーと各サーバーの logging.properties ファイルがあります。
ドメインコントローラー: EAP_HOME/domain/configuration/logging.properties
Server: EAP_HOME/domain/servers/SERVER_NAME/data/logging.properties
設定ファイルは logging サブシステムが起動し、引き継がるまで logging.properties がアクティブになります。
警告
logging.properties ファイルは、直接編集する必要があるユースケースが不明な場合を除き、直接編集しないことが推奨されます。サポートケースを作成する前に、サポートケースを作成することが推奨されます。
logging.properties ファイルに手動で行った変更は起動時に上書きされます。

12.1.4. 起動エラーの表示

JBoss EAP をトラブルシューティングする場合、最初に行う手順の 1 つとなるよう、起動中に発生したエラーをチェックする必要があります。起動時のエラーを表示する方法は 2 つあり、どちらも利点があります。各メソッドにより、起動時に発生したエラーの一覧が表示されます。提供される情報を使用して原因を診断し、解決します。トラブルシューティングに関しては、Red Hat カスタマーポータルにお問い合わせください。
  • server.log ログファイルを確認します。
    この方法では、各エラーメッセージおよび関連するメッセージを確認でき、エラーが発生した理由の詳細を知ることができます。また、エラーメッセージをプレーンテキスト形式で表示することもできます。
  • JBoss EAP 6.4 から、管理 CLI コマンドの read-boot-errors を使用します。
    この方法では、サーバーのファイルシステムにアクセスする必要がありません。これは管理 CLI コマンドであるため、スクリプトで使用できます。たとえば、複数の JBoss EAP インスタンスを起動し、起動時に発生したエラーをチェックするスクリプトを作成できます。

手順12.1 server.log でエラーの有無を確認する

  1. ファイルビューアーで server.log ファイルを開きます。
  2. ファイルの最後に移動します。
  3. 最新の起動シーケンスの開始 を示すメッセージ識別子の backward015899 を検索します。
  4. ログのその位置から ERROR を前方検索します。各検索一致箇所には、エラーの説明が示され、関連するモジュールがリストされます。

例12.1 Error Description from server.log

以下は、server.log ログファイルのエラー説明の例です。
13:23:14,281 ERROR [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-4) JBWEB003043: Error initializing endpoint: java.net.BindException: Address already in use /127.0.0.1:8080
Copy to Clipboard Toggle word wrap

手順12.2 管理 CLI より起動エラーの一覧表示

  • 以下の管理 CLI コマンドを実行します。
    /core-service=management:read-boot-errors
    Copy to Clipboard Toggle word wrap
    起動中に発生したすべてのエラーがリストされます。
    各エラーのタイムスタンプは Java メソッド currentTimeMillis() を使用します。これは、現在の時間と午前 0 時から 1970 UTC(協定世界時)の間で測定される違いです。

例12.2 read-boot-errors コマンドの出力

{
"outcome" => "success",
"result" => [{
    "failed-operation" => {
        "operation" => "add",
        "address" => [
            ("subsystem" => "web"),
            ("connector" => "http")
        ]
    },
    "failure-timestamp" => 1417560953245L,
    "failure-description" => "{\"JBAS014671: Failed services\" => {\"jboss.web.connector.http\" => \"org.jboss.msc.service.StartException in service jboss.web.connector.http: JBAS018007: Error starting web connector
Caused by: LifecycleException:  JBWEB000023: Protocol handler initialization failed\"}}",
    "failed-services" => {"jboss.web.connector.http" => "org.jboss.msc.service.StartException in service jboss.web.connector.http: JBAS018007: Error starting web connector
Caused by: LifecycleException:  JBWEB000023: Protocol handler initialization failed"}
}]
}
Copy to Clipboard Toggle word wrap

12.1.5. ガベッジコレクションロギング

ガベッジコレクションロギングは、すべてのガベッジコレクションのアクティビティーをプレーンテキストのログファイルに記録します。これらのログファイルは診断を行うのに便利です。JBoss EAP 6 より、ガベッジコレクションのロギングは IBM Java Development Kit 以外 のすべてのサポートされる構成では、スタンドアロン モードではデフォルトで有効になっています。
logging は EAP_HOME/standalone/log/gc.log. のファイルに出力されます。ログローテーションが有効化され、ログファイルの数は 5 に制限され、各ファイルは最大 3 MiB に制限されます。

12.1.6. 暗黙的なロギング API の依存関係

JBoss EAP 6 の logging サブシステムには、コンテナーが暗黙的なロギング API 依存関係をデプロイメントに追加するかどうかを制御する add-logging-api-dependencies 属性があります。デフォルトではこの属性は true に設定されています。これは、暗黙的なロギング API 依存関係がすべてデプロイメントに追加されることを意味します。false に設定すると、暗黙的なロギング API 依存関係が追加されません。
add-logging-api-dependencies 属性は、管理 CLI を使用して設定できます。以下に例を示します。
/subsystem=logging:write-attribute(name=add-logging-api-dependencies, value=false)
Copy to Clipboard Toggle word wrap

12.1.7. デフォルトのログファイルの場所

これらは、デフォルトのロギング設定用に作成されたログファイルです。デフォルト設定は Periodic ログハンドラーを使用してサーバーログファイルを書き込みます。
Expand
表12.1 スタンドアロンサーバーのデフォルトログファイル
ログファイル 説明
EAP_HOME/standalone/log/server.log
サーバーログ。サーバー起動メッセージを含む、すべてのサーバーログメッセージが含まれます。
EAP_HOME/standalone/log/gc.log
ガベッジコレクションのログ。すべてのガベージコレクションの詳細が含まれます。
Expand
表12.2 管理対象ドメイン用のデフォルトログファイル
ログファイル 説明
EAP_HOME/domain/log/host-controller.log
ホストコントローラーのブートログ。ホストコントローラーの起動に関連するログメッセージが含まれます。
EAP_HOME/domain/log/process-controller.log
プロセスコントローラーのブートログ。プロセスコントローラーの起動に関連するログメッセージが含まれます。
EAP_HOME/domain/servers/SERVERNAME/log/server.log
名前付きサーバーのサーバーログ。サーバー起動メッセージなど、そのサーバーのすべてのログメッセージが含まれます。

12.1.8. ロギングのフィルター式

フィルター式は、さまざまな基準に基づいてログメッセージを記録するために使用されます。フィルターチェックは、常に未フォーマットの raw メッセージに対して行われます。ロガーまたはハンドラーのフィルターを含めることができます。ロガーフィルターは、ハンドラーに配置されたフィルターよりも優先されます。
注記
ルートロガーに指定された filter-spec は他のロガーによって継承され ません。代わりに、ハンドラーごとに filter-spec を指定する必要があります。
Expand
表12.3 ロギングのフィルター式
フィルタータイプ
expression
説明 パラメーター
Accept
accept
すべてのログメッセージを許可します。
accept
却下
deny
すべてのログメッセージを拒否します。
deny
Not (否定)
not[filter expression]
フィルター式の逆の値を返します。
1 つのフィルター式をパラメーターとして取ります。
not(match("JBAS"))
All
all[filter expression]
複数のフィルター式より連結された値を返します。
コンマ区切りの複数のフィルター式を取ります。
all(match("JBAS"),match("WELD"))
すべて
any[filter expression]
複数のフィルター式より 1 つの値を返します。
コンマ区切りの複数のフィルター式を取ります。
any(match("JBAS"),match("WELD"))
Level Change
levelChange[level]
指定のレベルでログレコードを変更します。
1 つの文字列ベースのレベルを引数として取ります。
levelChange("WARN")
Levels
levels[levels]
レベルリストにあるレベルの 1 つでログメッセージをフィルターします。
コンマで区切られた複数の文字列ベースのレベルを取ります。
levels("DEBUG","INFO","WARN","ERROR")
Level Range
levelRange[minLevel,maxLevel]
指定されたレベル範囲内でログメッセージをフィルターします。
フィルター式は [ を使用して含まれる最小レベルを示し、a ] を使用して含まれる最大レベルを示します。または、それぞれ または を使用して除外を示すこともできます。式の最初の引数は許可される最小レベルで、2 つ目の引数は最大許容レベルです。
以下に例を示します。
  • levelRange("DEBUG","ERROR")
    最小レベルは DEBUG よりも大きく、最大レベルは ERROR 未満でなければなりません。
  • levelRange["DEBUG","ERROR")
    最小レベルは DEBUG 以上で、最大レベルは ERROR 未満でなければなりません。
  • levelRange["INFO","ERROR"]
    最小レベルは INFO 以上で、最大レベルは ERROR 以下でなければなりません。
Match (match["pattern"]) 正規表現ベースのフィルター。式に指定されたパターンに対してフォーマットされていないメッセージが使用されます。
正規表現を引数として取ります。
match("JBAS\d+")
Substitute (substitute["pattern","replacement value"]) 最初にパターンと一致した値を指定の値に置き換えるフィルター。
式の最初の引数はパターンで、2 つ目の引数は置き換えるテキストです。
substitute("JBAS","EAP")
Replace All(substituteAll["pattern","replacement value"]) パターンと一致したすべての値を指定の値に置き換えるフィルター。
式の最初の引数はパターンで、2 つ目の引数は置き換えるテキストです。
substituteAll("JBAS","EAP")
注記
値のコンマと引用符('\' 演算子で前)をエスケープし、式全体を引用符で囲み、値が正しく 文字列 として解釈されるようにします。それ以外の場合は、リスト として解析されます。正しい形式の例は次のとおりです。
[standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE:write-attribute(name=filter-spec, value="substituteAll(\"JBAS\"\,\"SABJ\")")
Copy to Clipboard Toggle word wrap

12.1.9. ログレベル

ログレベルは、ログメッセージの性質と重大度を示す列挙値の順序付けされたセットです。特定のログメッセージのレベルは、開発者がメッセージを送信するために選択したロギングフレームワークの適切なメソッドを使用して指定します。
JBoss EAP 6 は、サポートされるアプリケーションロギングフレームワークによって使用されるすべてのログレベルをサポートします。最も一般的に使用される 6 つのログレベルは(最低から高い順に) TRACEDEBUGINFOWARNERROR、および FATAL です。
ログレベルはログカテゴリーとログハンドラーによって使用され、それらが担当するメッセージを限定します。各ログレベルには、他のログレベルに対して相対的な順番を示す数値が割り当てられています。ログカテゴリーとハンドラーにはログレベルが割り当てられ、そのレベル以上のログメッセージのみを処理します。たとえば、WARN レベルのログハンドラーは、 WARN ERROR、および FATAL レベルのメッセージのみを記録します。

12.1.10. サポート対象のログレベル

Expand
表12.4 サポート対象のログレベル
ログのレベル Value 説明
FINEST 300
-
FINER 400
-
TRACE 400
アプリケーションの実行状態に関する詳細情報を提供するメッセージに使用します。通常、TRACE のログメッセージはアプリケーションのデバッグ時にのみキャプチャーされます。
DEBUG 500
アプリケーションの個別の要求またはアクティビティーの進捗状況を示すメッセージに使用します。DEBUG のログメッセージは通常、アプリケーションをデバッグする場合にのみキャプチャーされます。
FINE 500
-
CONFIG 700
-
INFO 800
アプリケーションの全体的な進捗状況を示すメッセージに使用します。多くの場合、アプリケーションの起動、シャットダウン、およびその他の主要なライフサイクルイベントに使用されます。
WARN 900
エラーではないが、理想的とは見なされない状況を示すために使用されます。今後エラーが発生する可能性のある状況を示す場合があります。
警告 900
-
ERROR 1000
発生したエラーの中で、現在の活動や要求の完了を妨げる可能性があるが、アプリケーション実行の妨げにはならないエラーを表示するために使用されます。
SEVERE 1000
-
FATAL 1100
クリティカルなサービス障害やアプリケーションのシャットダウンをもたらしたり、JBoss EAP 6 のシャットダウンを引き起こす可能性があるイベントを表示するのに使用されます。

12.1.11. ログカテゴリー

ログカテゴリーは、キャプチャーするログメッセージのセットと、メッセージを処理する 1 つまたは複数のログハンドラーを定義します。
キャプチャーするログメッセージは、元の Java パッケージとログレベルによって定義されます。そのパッケージのクラスおよびそのログレベル以下のメッセージがログカテゴリーによってキャプチャーされ、指定のログハンドラーに送信されます。
ログカテゴリーは、独自のハンドラーの代わりにルートロガーのログハンドラーを任意で使用することができます。

12.1.12. ルートロガーについて

ルートロガーは、ログカテゴリーによってキャプチャーされないサーバー(指定レベルの)に送信されたすべてのログメッセージをキャプチャーします。これらのメッセージは 1 つ以上のログハンドラーに送信されます。
デフォルトでは、ルートロガーはコンソールおよび周期ログハンドラーを使用するように設定されています。Periodic ログハンドラーは、ファイル server.log に書き込むように設定されます。このファイルはサーバーログと呼ばれることもあります。

12.1.13. ログハンドラー

ログハンドラーはキャプチャーしたメッセージの記録方法を定義します。利用できるログハンドラーは、コンソールファイル周期サイズAsyncsyslogPeriodic Size、および Custom です。
注記
ログハンドラーをアクティブにするには、少なくとも 1 つのロガーに追加する必要があります。

12.1.14. ログハンドラーのタイプ

Console
コンソールログハンドラーは、ログメッセージをホストオペレーティングシステムの標準出力(標準出力)または標準エラー(stderr)ストリームに書き込みます。これらのメッセージは、JBoss EAP 6 がコマンドラインプロンプトから実行された場合に表示されます。オペレーティングシステムが標準出力または標準エラーストリームをキャプチャーするように設定されていない限り、Console ログハンドラーからのメッセージは保存されません。
ファイル
File ログハンドラーはログメッセージを指定のファイルに書き込みます。
Periodic
Periodic ログハンドラーは、指定した時間が経過するまで、ログメッセージを指定ファイルに書き込みます。期間が経過したら、指定されたタイムスタンプを追加してファイルの名前が変更され、ハンドラーは元の名前で新規作成されたログファイルに書き込みを継続します。
サイズ
Size ログハンドラーは、指定したファイルが指定したサイズに達するまで、ログメッセージを名前付きファイルに書き込みます。ファイルが指定したサイズに達すると、数値の接尾辞が付いて名前が変更され、ハンドラーは元の名前で新規作成されたログファイルに書き込みを継続します。各サイズログハンドラーは、この方式で保管されるファイルの最大数を指定する必要があります。
Periodic Size
JBoss EAP 6.4 から利用できます。これは Periodic および Size ハンドラーの組み合わせで、組み合わされた属性をサポートします。
現在のログファイルが指定されたサイズに達する 、指定の期間が経過すると、ファイルの名前が変更され、ハンドラーは元の名前で新規作成されたログファイルに書き込みを継続します。
非同期
非同期ログハンドラーは、1 つ以上のログハンドラーに対して非同期動作を提供するラッパーログハンドラーです。これは、待ち時間が長い可能性があるログハンドラーや、ネットワークファイルシステムへのログファイルの書き込みなど、パフォーマンス上の問題がある場合に役立ちます。
カスタム
Custom ログハンドラーを使用すると、実装された新しいタイプのログハンドラーを設定することができます。カスタムハンドラーは、java.util.logging.Handler を拡張し、モジュールに含まれる Java クラスとして実装する必要があります。
syslog
syslog ハンドラーは、リモートのロギングサーバーへメッセージを送信するために使用できます。これにより、複数のアプリケーションが同じサーバーにログメッセージを送信でき、そのサーバーですべてのログメッセージを解析できます。

12.1.15. ログフォーマッター

ログフォーマッターは、ログハンドラーの設定プロパティーで、そのハンドラーからのログメッセージの表示を定義します。これは、java.util.Formatter クラスに基づいた構文を使用する文字列です。
たとえば、デフォルト設定のログフォーマッター文字列 %d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n は、以下のようなログメッセージを作成します。
15:53:26,546 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015951: Admin console listening on http://127.0.0.1:9990
Copy to Clipboard Toggle word wrap

12.1.16. ログフォーマッター構文

Expand
表12.5 ログフォーマッター構文
記号 説明
%c ロギングイベントのカテゴリー
%p ログエントリーのレベル (情報やデバッグなど)
%P ログエントリーのローカライズレベル
%d 現在の日付/時刻 (yyyy-MM-dd HH:mm:ss,SSS 形式)
%r 相対時間 (ログが初期化された以降のミリ秒単位の時間)
%z タイムゾーン
%k ログリソースキー (ログメッセージのローカリゼーションに使用)
%m ログメッセージ (例外トレースを除外)
%s 単純なログメッセージ (例外トレースなし)
%e 例外スタックトレース (拡張モジュール情報なし)
%E 例外スタックトレース (拡張モジュール情報あり)
%t 現在のスレッドの名前
%n 改行文字
%C ログメソッドを呼び出すコードのクラス (低速)
%F ログメソッドを呼び出すクラスのファイル名 (低速)
%l ログメソッドを呼び出すコードのソースロケーション (低速)
%L ログメソッドを呼び出すコードの行番号 (低速)
%M ログメソッドを呼び出すコードのメソッド (低速)
%x ネスト化診断コンテキスト
%X メッセージ診断コンテキスト
%% リテラルパーセント記号 (エスケープ)

12.2. 管理コンソールでのロギングの設定

管理コンソールは、ルートロガー、ログハンドラー、およびログカテゴリーの設定用のグラフィカルユーザーインターフェースを提供します。管理コンソールの詳細は、「管理コンソール」 を参照してください。
ロギング設定にアクセスするには、以下の手順に従います。

手順12.3 アクセスロギングの設定

  1. 管理コンソールへのログイン
  2. logging サブシステム設定に移動します。この手順は、スタンドアロンサーバーとして実行されているサーバーと管理対象ドメインで実行されているサーバーによって異なります。
    • スタンドアロンサーバー

      Configuration をクリックし、Subsystems メニューの Core を展開し、Logging をクリックします。
    • 管理対象ドメイン

      Configuration をクリックし、ドロップダウンメニューから編集するプロファイルを選択します。Subsystems メニューで Core を展開し、Logging をクリックします。
ルートロガーを設定するために実行できるタスクは以下のとおりです。
  • ログレベルを編集します。
  • ログハンドラーを追加および削除します。
ログカテゴリーを設定するために実行できるタスクは以下のとおりです。
  • ログカテゴリーを追加および削除します。
  • ログカテゴリープロパティーを編集します。
  • カテゴリーのログハンドラーを追加および削除します。
ログハンドラーを設定するために実行できる主なタスクは以下のとおりです。
  • 新しいハンドラーを追加します。
  • ハンドラーを設定します。
管理コンソールでは、すべてのサポート対象ログハンドラー (カスタムを含む) を設定できます。

12.3. CLI でのロギング設定

前提条件

管理 CLI が実行され、関連する JBoss EAP インスタンスに接続されている必要があります。詳細はを参照してください。 「管理 CLI の起動」

12.3.1. CLI でのルートロガーの設定

ルートロガーの設定は管理 CLI を使用して確認および編集することができます。
ルートロガーを設定するために実行する主なタスクは以下のとおりです。
  • ルートロガーへのログハンドラーの追加
  • ルートロガー設定の表示
  • ログレベルの変更
  • ルートロガーからのログハンドラーの削除
重要
ルートロガーをスタンドアロンシステムのロギングプロファイルに設定する場合、設定パスのルートは /subsystem=logging/ ではなく /subsystem=logging/logging-profile=NAME/ になります。
管理対象ドメインでは、使用するプロファイルを指定する必要があります。管理対象ドメインの設定パスの先頭にプロファイル名を追加する必要があります。/subsystem=logging//profile=NAME/subsystem=logging/ に置き換えます。
ルートロガーへのログハンドラーの追加
次の構文で add-handler 操作を使用します。HANDLER は追加するログハンドラーの名前です。
/subsystem=logging/root-logger=ROOT:add-handler(name="HANDLER")
Copy to Clipboard Toggle word wrap
ログハンドラーを作成してから、ログハンドラーをルートロガーへ追加する必要があります。

例12.3 ルートロガーの add-handler 操作

[standalone@localhost:9999 /] /subsystem=logging/root-logger=ROOT:add-handler(name="FILE")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
ルートロガーの設定内容の表示
以下の構文で read-resource 操作を使用します。
/subsystem=logging/root-logger=ROOT:read-resource
Copy to Clipboard Toggle word wrap

例12.4 ルートロガーの read-resource 操作

[standalone@localhost:9999 /] /subsystem=logging/root-logger=ROOT:read-resource                                  
{
   "outcome" => "success",
   "result" => {
        "filter" => undefined,
        "filter-spec" => undefined,
        "handlers" => [
            "CONSOLE",
            "FILE"
      ],
      "level" => "INFO"
   }
}
Copy to Clipboard Toggle word wrap
ルートロガーのログレベルの設定
次の構文で write-attribute 操作を使用します。LEVEL はサポートされているログレベルの 1 つになります。
/subsystem=logging/root-logger=ROOT:write-attribute(name="level", value="LEVEL")
Copy to Clipboard Toggle word wrap

例12.5 ルートロガーの write-attribute 操作によるログレベルの設定

[standalone@localhost:9999 /] /subsystem=logging/root-logger=ROOT:write-attribute(name="level", value="DEBUG")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
ルートロガーからのログハンドラーの削除
次の構文で remove-handler を使用します。HANDLER は削除するログハンドラーの名前です。
/subsystem=logging/root-logger=ROOT:remove-handler(name="HANDLER")
Copy to Clipboard Toggle word wrap

例12.6 ログハンドラーの削除

[standalone@localhost:9999 /] /subsystem=logging/root-logger=ROOT:remove-handler(name="FILE")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap

12.3.2. CLI でのログカテゴリー設定

ログカテゴリーは CLI で追加、削除、および編集できます。
ログカテゴリーを設定するために実行する主なタスクは次のとおりです。
  • 新しいログカテゴリーの追加
  • ログカテゴリーの設定表示
  • ログレベルを設定します。
  • ログカテゴリーへのログハンドラーの追加
  • ログカテゴリーからのログハンドラーの削除
  • ログカテゴリーの削除
重要
ログカテゴリーをスタンドアロンシステムのロギングプロファイルに設定する場合、設定パスのルートは /subsystem=logging/ ではなく /subsystem=logging/logging-profile=NAME/ になります。
管理対象ドメインでは、使用するプロファイルを指定する必要があります。管理対象ドメインの設定パスの先頭にプロファイル名を追加する必要があります。/subsystem=logging//profile=NAME/subsystem=logging/ に置き換えます。
ログカテゴリーの追加
以下の構文で add 操作を使用します。CATEGORY を、追加するカテゴリーに置き換えます。
 /subsystem=logging/logger=CATEGORY:add 
Copy to Clipboard Toggle word wrap

例12.7 新規カテゴリーの追加

[standalone@localhost:9999 /] /subsystem=logging/logger=com.company.accounts.rec:add   
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
ログカテゴリーの設定の表示
以下の構文で read-resource 操作を使用します。CATEGORY をカテゴリーの名前に置き換えます。
/subsystem=logging/logger=CATEGORY:read-resource 
Copy to Clipboard Toggle word wrap

例12.8 ログカテゴリーの read-resource 操作

[standalone@localhost:9999 /] /subsystem=logging/logger=org.apache.tomcat.util.modeler:read-resource
{
    "outcome" => "success",
    "result" => {
        "category" => "org.apache.tomcat.util.modeler",
        "filter" => undefined,
        "filter-spec" => undefined,
        "handlers" => undefined,
        "level" => "WARN",
        "use-parent-handlers" => true
    }
}
Copy to Clipboard Toggle word wrap
ログレベルの設定
次の構文で write-attribute 操作を使用します。CATEGORY はログカテゴリーの名前に、LEVEL は設定するログレベルに置き換えます。
/subsystem=logging/logger=CATEGORY:write-attribute(name="level", value="LEVEL") 
Copy to Clipboard Toggle word wrap

例12.9 ログレベルの設定

[standalone@localhost:9999 /] /subsystem=logging/logger=com.company.accounts.rec:write-attribute(name="level", value="DEBUG")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
ルートロガーのログハンドラーを使用するためのログカテゴリの設定
次の構文で write-attribute 操作を使用します。CATEGORY はログカテゴリーの名前に置き換えます。ルートロガーのハンドラーを使用するために、このログカテゴリーの BOOLEAN を true に置き換えます。独自の割り当てられたハンドラーのみを使用する場合は false に置き換えます。
/subsystem=logging/logger=CATEGORY:write-attribute(name="use-parent-handlers", value="BOOLEAN") 
Copy to Clipboard Toggle word wrap

例12.10 use-parent-handlers の設定

[standalone@localhost:9999 /] /subsystem=logging/logger=com.company.accounts.rec:write-attribute(name="use-parent-handlers", value="true")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
ログカテゴリへのログハンドラ追加
次の構文で add-handler 操作を使用します。CATEGORY をカテゴリーの名前に置き換え、HANDLER を追加するハンドラーの名前に置き換えます。
/subsystem=logging/logger=CATEGORY:add-handler(name="HANDLER") 
Copy to Clipboard Toggle word wrap
ログハンドラーを作成してから、ログハンドラーをルートロガーへ追加する必要があります。

例12.11 ログハンドラーの追加

[standalone@localhost:9999 /] /subsystem=logging/logger=com.company.accounts.rec:add-handler(name="AccountsNFSAsync")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
ログカテゴリからのログハンドラの削除
次の構文で remove-handler 操作を使用します。CATEGORY をカテゴリーの名前に置き換え、HANDLER を削除するログハンドラーの名前に置き換えます。
/subsystem=logging/logger=CATEGORY:remove-handler(name="HANDLER")
Copy to Clipboard Toggle word wrap

例12.12 ログハンドラーの削除

[standalone@localhost:9999 /] /subsystem=logging/logger=jacorb:remove-handler(name="AccountsNFSAsync")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
カテゴリーの削除
以下の構文で remove 操作を使用します。CATEGORY は削除するカテゴリーの名前に置き換えます。
/subsystem=logging/logger=CATEGORY:remove 
Copy to Clipboard Toggle word wrap

例12.13 ログカテゴリの削除

[standalone@localhost:9999 /] /subsystem=logging/logger=com.company.accounts.rec:remove   
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap

12.3.3. CLI でのコンソールログハンドラーの設定

コンソールログハンドラーは CLI で追加、削除、および編集できます。
Console ログハンドラーを設定するために実行する主なタスクは次のとおりです。
  • 新しいコンソールログハンドラーの追加
  • コンソールログハンドラーの設定表示
  • ハンドラーのログレベルの設定
  • ハンドラーの出力のターゲットの設定
  • ハンドラーの出力に使用されるエンコーディングの設定
  • ハンドラーの出力に使用されるフォーマッターの設定
  • ハンドラーによる自動フラッシュ使用の有無を設定
  • コンソールログハンドラーの削除
重要
ログハンドラーをスタンドアロンシステムのロギングプロファイルに設定する場合、設定パスのルートは /subsystem=logging/ ではなく /subsystem=logging/logging-profile=NAME/ になります。
管理対象ドメインでは、使用するプロファイルを指定する必要があります。管理対象ドメインの設定パスの先頭にプロファイル名を追加する必要があります。/subsystem=logging//profile=NAME/subsystem=logging/ に置き換えます。
Console ログハンドラーの追加
以下の構文で add 操作を使用します。HANDLER を、追加するコンソールログハンドラーに置き換えます。
/subsystem=logging/console-handler=HANDLER:add 
Copy to Clipboard Toggle word wrap

例12.14 Console ログハンドラーの追加

[standalone@localhost:9999 /] /subsystem=logging/console-handler=ERRORCONSOLE:add     
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
コンソールログハンドラーの設定表示
以下の構文で read-resource 操作を使用します。HANDLER をコンソールログハンドラーの名前に置き換えます。
/subsystem=logging/console-handler=HANDLER:read-resource 
Copy to Clipboard Toggle word wrap

例12.15 コンソールログハンドラーの設定表示

[standalone@localhost:9999 /] /subsystem=logging/console-handler=CONSOLE:read-resource
{
    "outcome" => "success",
    "result" => {
        "autoflush" => true,
        "enabled" => true,
        "encoding" => undefined,
        "filter" => undefined,
        "filter-spec" => undefined,
        "formatter" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n",
        "level" => "INFO",
        "name" => "CONSOLE",
        "named-formatter" => "COLOR-PATTERN",
        "target" => "System.out"
    }
}
Copy to Clipboard Toggle word wrap
ログレベルの設定
次の構文で write-attribute 操作を使用します。HANDLER はコンソールログハンドラーの名前に、LEVEL は設定するログレベルに置き換えます。
/subsystem=logging/console-handler=HANDLER:write-attribute(name="level", value="INFO") 
Copy to Clipboard Toggle word wrap

例12.16 ログレベルの設定

[standalone@localhost:9999 /] /subsystem=logging/console-handler=ERRORCONSOLE:write-attribute(name="level", value="TRACE")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
ターゲットの設定
次の構文で write-attribute 操作を使用します。HANDLER をコンソールログハンドラーの名前に置き換えます。TARGET を、システムエラーストリームまたは標準出力ストリームの System.err または System.out に置き換えます。
/subsystem=logging/console-handler=HANDLER:write-attribute(name="target", value="TARGET") 
Copy to Clipboard Toggle word wrap

例12.17 ターゲットの設定

[standalone@localhost:9999 /] /subsystem=logging/console-handler=ERRORCONSOLE:write-attribute(name="target", value="System.err")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
エンコーディングの設定
次の構文で write-attribute 操作を使用します。HANDLER をコンソールログハンドラーの名前に置き換えます。ENCODING を、必要な文字エンコーディングシステムの名前に置き換えます。
/subsystem=logging/console-handler=HANDLER:write-attribute(name="encoding", value="ENCODING") 
Copy to Clipboard Toggle word wrap

例12.18 エンコーディングの設定

[standalone@localhost:9999 /] /subsystem=logging/console-handler=ERRORCONSOLE:write-attribute(name="encoding", value="utf-8")     
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
フォーマッターの設定
次の構文で write-attribute 操作を使用します。HANDLER をコンソールログハンドラーの名前に置き換えます。FORMAT は必要なフォーマッター文字列に置き換えます。
/subsystem=logging/console-handler=HANDLER:write-attribute(name="formatter", value="FORMAT") 
Copy to Clipboard Toggle word wrap

例12.19 フォーマッターの設定

[standalone@localhost:9999 /] /subsystem=logging/console-handler=ERRORCONSOLE:write-attribute(name="formatter", value="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
自動フラッシュの設定
次の構文で write-attribute 操作を使用します。HANDLER をコンソールログハンドラーの名前に置き換えます。このハンドラーが出力をすぐに書き込む場合は、BOOLEANtrue に置き換えます。
/subsystem=logging/console-handler=HANDLER:write-attribute(name="autoflush", value="BOOLEAN") 
Copy to Clipboard Toggle word wrap

例12.20 自動フラッシュの設定

[standalone@localhost:9999 /] /subsystem=logging/console-handler=ERRORCONSOLE:write-attribute(name="autoflush", value="true")                                  
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
Console ログハンドラーの削除
以下の構文で remove 操作を使用します。HANDLER を、削除するコンソールログハンドラーの名前に置き換えます。
/subsystem=logging/console-handler=HANDLER:remove 
Copy to Clipboard Toggle word wrap

例12.21 Console ログハンドラーの削除

[standalone@localhost:9999 /] /subsystem=logging/console-handler=ERRORCONSOLE:remove
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap

12.3.4. CLI でのファイルログハンドラーの設定

ファイルログハンドラーは CLI で追加、削除、および編集できます。
File ログハンドラーを設定するために実行する主なタスクは以下のとおりです。
  • 新しいファイルログハンドラーの追加
  • ファイルログハンドラーの設定表示
  • ハンドラーのログレベルの設定
  • ハンドラーの追加動作の設定
  • ハンドラーによる自動フラッシュ使用の有無を設定
  • ハンドラーの出力に使用されるエンコーディングの設定
  • ログハンドラーが書き込むファイルの指定
  • ハンドラーの出力に使用されるフォーマッターの設定
  • ファイルログハンドラーの削除
重要
ログハンドラーをスタンドアロンシステムのロギングプロファイルに設定する場合、設定パスのルートは /subsystem=logging/ ではなく /subsystem=logging/logging-profile=NAME/ になります。
管理対象ドメインでは、使用するプロファイルを指定する必要があります。管理対象ドメインの設定パスの先頭にプロファイル名を追加する必要があります。/subsystem=logging//profile=NAME/subsystem=logging/ に置き換えます。
ファイルログハンドラーの追加
以下の構文で add 操作を使用します。PATH を、ログが書き込まれるファイルのファイル名に置き換えます。DIR は、ファイルが存在するディレクトリー名に置き換えます。DIR の値はパス変数になります。
 /subsystem=logging/file-handler=HANDLER:add(file={"path"=>"PATH", "relative-to"=>"DIR"}) 
Copy to Clipboard Toggle word wrap

例12.22 ファイルログハンドラーの追加

[standalone@localhost:9999 /] /subsystem=logging/file-handler=accounts_log:add(file={"path"=>"accounts.log", "relative-to"=>"jboss.server.log.dir"})
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
ファイルログハンドラー設定の表示
以下の構文で read-resource 操作を使用します。HANDLER をファイルログハンドラーの名前に置き換えます。
 /subsystem=logging/file-handler=HANDLER:read-resource 
Copy to Clipboard Toggle word wrap

例12.23 read-resource 操作の使用

[standalone@localhost:9999 /] /subsystem=logging/file-handler=accounts_log:read-resource
{
    "outcome" => "success",
    "result" => {
        "append" => true,
        "autoflush" => true,
        "enabled" => true,
        "encoding" => undefined,
        "file" => {
            "path" => "accounts.log",
            "relative-to" => "jboss.server.log.dir"
        },
        "filter" => undefined,
        "filter-spec" => undefined,
        "formatter" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n",
        "level" => "ALL",
        "name" => "accounts_log",
        "named-formatter" => undefined
    }
}
Copy to Clipboard Toggle word wrap
ログレベルの設定
次の構文で write-attribute 操作を使用します。HANDLER をファイルログハンドラーの名前に置き換えます。LOG_LEVEL_VALUE を設定するログレベルに置き換えます。
 /subsystem=logging/file-handler=HANDLER:write-attribute(name="level", value="LOG_LEVEL_VALUE") 
Copy to Clipboard Toggle word wrap

例12.24 ログレベルの変更

/subsystem=logging/file-handler=accounts_log:write-attribute(name="level", value="DEBUG")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
追加動作の設定
次の構文で write-attribute 操作を使用します。HANDLER をファイルログハンドラーの名前に置き換えます。アプリケーションサーバーが起動されるたびに新しいログファイルを作成する必要がある場合は、BOOLEAN を false に置き換えます。アプリケーションサーバーが同じファイルを使用し続ける必要がある場合は、BOOLEANtrue に置き換えます。
 /subsystem=logging/file-handler=HANDLER:write-attribute(name="append", value="BOOLEAN") 
Copy to Clipboard Toggle word wrap

例12.25 追加プロパティーの変更

[standalone@localhost:9999 /] /subsystem=logging/file-handler=accounts_log:write-attribute(name="append", value="true")
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}
Copy to Clipboard Toggle word wrap
この変更を反映するには、JBoss EAP 6 を再起動する必要があります。
自動フラッシュの設定
次の構文で write-attribute 操作を使用します。HANDLER をファイルログハンドラーの名前に置き換えます。このハンドラーが出力をすぐに書き込む場合は、BOOLEANtrue に置き換えます。
 /subsystem=logging/file-handler=HANDLER:write-attribute(name="autoflush", value="BOOLEAN") 
Copy to Clipboard Toggle word wrap

例12.26 自動フラッシュプロパティーの変更

[standalone@localhost:9999 /] /subsystem=logging/file-handler=accounts_log:write-attribute(name="autoflush", value="false")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
エンコーディングの設定
次の構文で write-attribute 操作を使用します。HANDLER をファイルログハンドラーの名前に置き換えます。ENCODING を、必要な文字エンコーディングシステムの名前に置き換えます。
 /subsystem=logging/file-handler=HANDLER:write-attribute(name="encoding", value="ENCODING") 
Copy to Clipboard Toggle word wrap

例12.27 エンコーディングの設定

[standalone@localhost:9999 /] /subsystem=logging/file-handler=accounts_log:write-attribute(name="encoding", value="utf-8")     
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
ログハンドラーが書き込むファイルの変更
次の構文で write-attribute 操作を使用します。PATH を、ログが書き込まれるファイルのファイル名に置き換えます。DIR は、ファイルが存在するディレクトリー名に置き換えます。DIR の値はパス変数になります。
 /subsystem=logging/file-handler=HANDLER:write-attribute(name="file", value={"path"=>"PATH", "relative-to"=>"DIR"}) 
Copy to Clipboard Toggle word wrap

例12.28 ログハンドラーが書き込むファイルの変更

[standalone@localhost:9999 /] /subsystem=logging/file-handler=accounts_log:write-attribute(name="file", value={"path"=>"accounts-debug.log", "relative-to"=>"jboss.server.log.dir"})
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
フォーマッターの設定
次の構文で write-attribute 操作を使用します。HANDLER をファイルログハンドラーの名前に置き換えます。FORMAT は必要なフォーマッター文字列に置き換えます。
 /subsystem=logging/file-handler=HANDLER:write-attribute(name="formatter", value="FORMAT") 
Copy to Clipboard Toggle word wrap

例12.29 フォーマッターの設定

[standalone@localhost:9999 /] /subsystem=logging/file-handler=accounts_log:write-attribute(name="formatter", value="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
File ログハンドラーの削除
以下の構文で remove 操作を使用します。HANDLER を、削除するファイルログハンドラーの名前に置き換えます。
 /subsystem=logging/file-handler=HANDLER:remove 
Copy to Clipboard Toggle word wrap

例12.30 File ログハンドラーの削除

[standalone@localhost:9999 /] /subsystem=logging/file-handler=accounts_log:remove
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
ログハンドラーは、ログカテゴリーまたは非同期ログハンドラーによって参照されていない場合にのみ削除できます。

12.3.5. CLI での周期ログハンドラーの設定

周期ログハンドラーは、CLI で追加、削除、および編集できます。
Periodic ログハンドラーを設定するために実行する主なタスクは以下のとおりです。
  • 新しい周期ログハンドラーの追加
  • 周期ログハンドラーの設定表示
  • ハンドラーのログレベルの設定
  • ハンドラーの追加動作の設定
  • ハンドラーによる自動フラッシュ使用の有無を設定し ます
  • ハンドラーの出力に使用されるエンコーディングの設定
  • ログハンドラーが書き込むファイルの指定
  • ハンドラーの出力に使用されるフォーマッターの設定
  • ローテーションされるログの接尾辞を設定します。
  • 周期ログハンドラーの削除
これらの各タスクについては以下で説明します。
重要
ログハンドラーをスタンドアロンシステムのロギングプロファイルに設定する場合、設定パスのルートは /subsystem=logging/ ではなく /subsystem=logging/logging-profile=NAME/ になります。
管理対象ドメインでは、使用するプロファイルを指定する必要があります。管理対象ドメインの設定パスの先頭にプロファイル名を追加する必要があります。/subsystem=logging//profile=NAME/subsystem=logging/ に置き換えます。
新しい周期ローテーションファイルログハンドラーの追加
以下の構文で add 操作を使用します。
 /subsystem=logging/periodic-rotating-file-handler=HANDLER:add(file={"path"=>"PATH", "relative-to"=>"DIR"}, suffix="SUFFIX") 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。PATH を、ログが書き込まれるファイルのファイル名に置き換えます。DIR は、ファイルが存在するディレクトリー名に置き換えます。DIR の値はパス変数になります。SUFFIX を、使用されるファイルローテーション接尾辞に置き換えます。

例12.31 新しいハンドラーの追加

[standalone@localhost:9999 /] /subsystem=logging/periodic-rotating-file-handler=HOURLY_DEBUG:add(file={"path"=>"daily-debug.log", "relative-to"=>"jboss.server.log.dir"}, suffix=".yyyy.MM.dd")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
周期ローテーションファイルログハンドラー設定の表示
以下の構文で read-resource 操作を使用します。
 /subsystem=logging/periodic-rotating-file-handler=HANDLER:read-resource 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。

例12.32 read-resource 操作の使用

[standalone@localhost:9999 /] /subsystem=logging/periodic-rotating-file-handler=HOURLY_DEBUG:read-resource
{
    "outcome" => "success",
    "result" => {
        "append" => true,
        "autoflush" => true,
        "enabled" => true,
        "encoding" => undefined,
        "file" => {
            "path" => "daily-debug.log",
            "relative-to" => "jboss.server.log.dir"
        },
        "filter" => undefined,
        "filter-spec" => undefined,
        "formatter" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n",
        "level" => "ALL",
        "name" => "HOURLY_DEBUG",
        "named-formatter" => undefined,
        "suffix" => ".yyyy.MM.dd"
    },
    "response-headers" => {"process-state" => "reload-required"}
}
Copy to Clipboard Toggle word wrap
ログレベルの設定
次の構文で write-attribute 操作を使用します。
 /subsystem=logging/periodic-rotating-file-handler=HANDLER:write-attribute(name="level". value="LOG_LEVEL_VALUE") 
Copy to Clipboard Toggle word wrap
HANDLER を周期ログハンドラーの名前に置き換えます。LOG_LEVEL_VALUE を設定するログレベルに置き換えます。

例12.33 ログレベルの設定

[standalone@localhost:9999 /] /subsystem=logging/periodic-rotating-file-handler=HOURLY_DEBUG:write-attribute(name="level", value="DEBUG")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
追加動作の設定
次の構文で write-attribute 操作を使用します。
 /subsystem=logging/periodic-rotating-handler=HANDLER:write-attribute(name="append", value="BOOLEAN") 
Copy to Clipboard Toggle word wrap
HANDLER を周期ログハンドラーの名前に置き換えます。アプリケーションサーバーが起動されるたびに新しいログファイルを作成する必要がある場合は、BOOLEANfalse に置き換えます。アプリケーションサーバーが同じファイルを使用し続ける必要がある場合は、BOOLEANtrue に置き換えます。
この変更を反映するには、JBoss EAP 6 を再起動する必要があります。

例12.34 追加動作の設定

[standalone@localhost:9999 /] /subsystem=logging/periodic-rotating-file-handler=HOURLY_DEBUG:write-attribute(name="append", value="true")
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}
Copy to Clipboard Toggle word wrap
自動フラッシュの設定
次の構文で write-attribute 操作を使用します。
 /subsystem=logging/periodic-rotating-file-handler=HANDLER:write-attribute(name="autoflush", value="BOOLEAN") 
Copy to Clipboard Toggle word wrap
HANDLER を周期ログハンドラーの名前に置き換えます。このハンドラーが出力をすぐに書き込む場合は、BOOLEANtrue に置き換えます。

例12.35 自動フラッシュ動作の設定

[standalone@localhost:9999 /] /subsystem=logging/periodic-rotating-file-handler=HOURLY_DEBUG:write-attribute(name="autoflush", value="false")
{
    "outcome" => "success",
    "response-headers" => {"process-state" => "reload-required"}
}
Copy to Clipboard Toggle word wrap
エンコーディングの設定
次の構文で write-attribute 操作を使用します。
 /subsystem=logging/periodic-rotating-file-handler=HANDLER:write-attribute(name="encoding", value="ENCODING") 
Copy to Clipboard Toggle word wrap
HANDLER を周期ログハンドラーの名前に置き換えます。ENCODING を、必要な文字エンコーディングシステムの名前に置き換えます。

例12.36 エンコーディングの設定

[standalone@localhost:9999 /] /subsystem=logging/periodic-rotating-file-handler=HOURLY_DEBUG:write-attribute(name="encoding", value="utf-8")     
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
ログハンドラーが書き込むファイルの変更
次の構文で write-attribute 操作を使用します。
 /subsystem=logging/periodic-rotating-file-handler=HANDLER:write-attribute(name="file", value={"path"=>"PATH", "relative-to"=>"DIR"}) 
Copy to Clipboard Toggle word wrap
HANDLER を周期ログハンドラーの名前に置き換えます。PATH を、ログが書き込まれるファイルのファイル名に置き換えます。DIR は、ファイルが存在するディレクトリー名に置き換えます。DIR の値はパス変数になります。

例12.37 ログハンドラーが書き込むファイルの変更

[standalone@localhost:9999 /] /subsystem=logging/periodic-rotating-file-handler=HOURLY_DEBUG:write-attribute(name="file", value={"path"=>"daily-debug.log", "relative-to"=>"jboss.server.log.dir"})
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
フォーマッターの設定
次の構文で write-attribute 操作を使用します。
 /subsystem=logging/periodic-rotating-file-handler=HANDLER:write-attribute(name="formatter", value="FORMAT") 
Copy to Clipboard Toggle word wrap
HANDLER を周期ログハンドラーの名前に置き換えます。FORMAT は必要なフォーマッター文字列に置き換えます。

例12.38 フォーマッターの設定

[standalone@localhost:9999 /] /subsystem=logging/periodic-rotating-file-handler=HOURLY_DEBUG:write-attribute(name="formatter", value="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
ローテーションされるログの接尾辞の設定
次の構文で write-attribute 操作を使用します。
 /subsystem=logging/periodic-rotating-file-handler=HANDLER:write-attribute(name="suffix", value="SUFFIX") 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。SUFFIX を、必要な接尾辞の文字列に置き換えます。

例12.39 ローテーションされるログの接尾辞の設定

[standalone@localhost:9999 /] /subsystem=logging/periodic-rotating-file-handler=HOURLY_DEBUG:write-attribute(name="suffix", value=".yyyy-MM-dd-HH")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
周期ログハンドラーの削除
以下の構文で remove 操作を使用します。
 /subsystem=logging/periodic-rotating-file-handler=HANDLER:remove 
Copy to Clipboard Toggle word wrap
HANDLER を周期ログハンドラーの名前に置き換えます。

例12.40 周期ログハンドラーの削除

[standalone@localhost:9999 /] /subsystem=logging/periodic-rotating-file-handler=HOURLY_DEBUG:remove
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap

12.3.6. CLI でのサイズログハンドラーの設定

サイズローテーションファイルログハンドラーは、CLI で追加、削除、および編集できます。
サイズローテーションファイルログハンドラーを設定するために実行するタスクは以下のとおりです。
  • 新しいログハンドラーの追加
  • ログハンドラーの設定表示
  • ハンドラーのログレベルの設定
  • ハンドラーの追加動作の設定
  • ハンドラーによる自動フラッシュ使用の有無を設定
  • ハンドラーの出力に使用されるエンコーディングの設定
  • ログハンドラーが書き込むファイルの指定
  • ハンドラーの出力に使用されるフォーマッターの設定
  • 各ログファイルの最大サイズを設定します。
  • 保持するバックアップログの最大数の設定
  • サイズローテーションファイルハンドラーにブート時のローテーションオプションを設定します。
  • ローテーションされるログの接尾辞を設定します。
  • ログハンドラーの削除
これらの各タスクについては以下で説明されています。
重要
ログハンドラーをスタンドアロンシステムのロギングプロファイルに設定する場合、設定パスのルートは /subsystem=logging/ ではなく /subsystem=logging/logging-profile=NAME/ になります。
管理対象ドメインでは、使用するプロファイルを指定する必要があります。管理対象ドメインの設定パスの先頭にプロファイル名を追加する必要があります。/subsystem=logging//profile=NAME/subsystem=logging/ に置き換えます。
新しいログハンドラーの追加
以下の構文で add 操作を使用します。
 /subsystem=logging/size-rotating-file-handler=HANDLER:add(file={"path"=>"PATH", "relative-to"=>"DIR"}) 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。PATH を、ログが書き込まれるファイルのファイル名に置き換えます。DIR は、ファイルが存在するディレクトリー名に置き換えます。DIR の値はパス変数になります。

例12.41 新しいログハンドラーの追加

[standalone@localhost:9999 /] /subsystem=logging/size-rotating-file-handler=ACCOUNTS_TRACE:add(file={"path"=>"accounts_trace.log", "relative-to"=>"jboss.server.log.dir"}) 
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
ログハンドラーの設定表示
以下の構文で read-resource 操作を使用します。
 /subsystem=logging/size-rotating-file-handler=HANDLER:read-resource 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。

例12.42 ログハンドラーの設定表示

[standalone@localhost:9999 /] /subsystem=logging/size-rotating-file-handler=ACCOUNTS_TRACE:read-resource
{
    "outcome" => "success",
    "result" => {
        "append" => true,
        "autoflush" => true,
        "enabled" => true,
        "encoding" => undefined,
        "file" => {
            "path" => "accounts_trace.log",
            "relative-to" => "jboss.server.log.dir"
        },
        "filter" => undefined,
        "filter-spec" => undefined,
        "formatter" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n",
        "level" => "ALL",
        "max-backup-index" => 1,
        "name" => "ACCOUNTS_TRACE",
        "named-formatter" => undefined,
        "rotate-on-boot" => false,
        "rotate-size" => "2m",
        "suffix" => undefined
    }
}
Copy to Clipboard Toggle word wrap
ハンドラーのログレベルの設定
次の構文で write-attribute 操作を使用します。
 /subsystem=logging/size-rotating-file-handler=HANDLER:write-attributel(name="level", value="LOG_LEVEL_VALUE") 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。LOG_LEVEL_VALUE を設定するログレベルに置き換えます。

例12.43 ハンドラーのログレベルの設定

[standalone@localhost:9999 /] /subsystem=logging/size-rotating-file-handler=ACCOUNTS_TRACE:write-attribute(name="level", value="TRACE")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
ハンドラーの追加動作の設定
次の構文で write-attribute 操作を使用します。
 /subsystem=logging/size-rotating-file-handler=HANDLER:write-attribute(name="append", value="BOOLEAN") 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。アプリケーションサーバーが起動されるたびに新しいログファイルを作成する必要がある場合は、BOOLEANfalse に置き換えます。アプリケーションサーバーが同じファイルを使用し続ける必要がある場合は、BOOLEANtrue に置き換えます。
この変更を反映するには、JBoss EAP 6 を再起動する必要があります。

例12.44 ハンドラーの追加動作の設定

[standalone@localhost:9999 /] /subsystem=logging/size-rotating-file-handler=ACCOUNTS_TRACE:write-attribute(name="append", value="true")
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}
Copy to Clipboard Toggle word wrap
ハンドラーによる自動フラッシュ使用の有無を設定
次の構文で write-attribute 操作を使用します。
 /subsystem=logging/size-rotating-file-handler=HANDLER:write-attribute(name="autoflush", value="BOOLEAN") 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。このハンドラーが出力をすぐに書き込む場合は、BOOLEANtrue に置き換えます。

例12.45 ハンドラーによる自動フラッシュ使用の有無を設定

[standalone@localhost:9999 /] /subsystem=logging/size-rotating-file-handler=ACCOUNTS_TRACE:write-attribute(name="autoflush", value="true")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
ハンドラーの出力に使用されるエンコーディングの設定
次の構文で write-attribute 操作を使用します。
 /subsystem=logging/size-rotating-file-handler=HANDLER:write-attribute(name="encoding", value="ENCODING") 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。ENCODING を、必要な文字エンコーディングシステムの名前に置き換えます。

例12.46 ハンドラーの出力に使用されるエンコーディングの設定

[standalone@localhost:9999 /] /subsystem=logging/size-rotating-file-handler=ACCOUNTS_TRACE:write-attribute(name="encoding", value="utf-8") 
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
ログハンドラーが書き込むファイルの指定
次の構文で write-attribute 操作を使用します。
 /subsystem=logging/size-rotating-file-handler=HANDLER:write-attribute(name="file", value={"path"=>"PATH", "relative-to"=>"DIR"}) 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。PATH を、ログが書き込まれるファイルのファイル名に置き換えます。DIR は、ファイルが存在するディレクトリー名に置き換えます。DIR の値はパス変数になります。

例12.47 ログハンドラーが書き込むファイルの指定

[standalone@localhost:9999 /] /subsystem=logging/size-rotating-file-handler=ACCOUNTS_TRACE:write-attribute(name="file", value={"path"=>"accounts_trace.log", "relative-to"=>"jboss.server.log.dir"}) 
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
ハンドラーの出力に使用されるフォーマッターの設定
次の構文で write-attribute 操作を使用します。
 /subsystem=logging/size-rotating-file-handler=HANDLER:write-attribute(name="formatter", value="FORMATTER") 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。FORMAT は必要なフォーマッター文字列に置き換えます。

例12.48 ハンドラーの出力に使用されるフォーマッターの設定

[standalone@localhost:9999 /] /subsystem=logging/size-rotating-file-handler=ACCOUNTS_TRACE:write-attribute(name="formatter", value="%d{HH:mm:ss,SSS} %-5p (%c) [%t] %s%E%n")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
各ログファイルの最大サイズの設定
次の構文で write-attribute 操作を使用します。
 /subsystem=logging/size-rotating-file-handler=HANDLER:write-attribute(name="rotate-size", value="SIZE") 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。SIZE はファイルの最大サイズに置き換えます。

例12.49 各ログファイルの最大サイズの設定

[standalone@localhost:9999 /] /subsystem=logging/size-rotating-file-handler=ACCOUNTS_TRACE:write-attribute(name="rotate-size", value="50m")  
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
保持するバックアップログの最大数の設定
次の構文で write-attribute 操作を使用します。
 /subsystem=logging/size-rotating-file-handler=HANDLER:write-attribute(name="max-backup-index", value="NUMBER") 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。NUMBER を、保持するログファイルの数に置き換えます。

例12.50 保持するバックアップログの最大数の設定

[standalone@localhost:9999 /] /subsystem=logging/size-rotating-file-handler=ACCOUNTS_TRACE:write-attribute(name="max-backup-index", value="5")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
size-rotating-file-handlerでの rotate-on-boot オプションの設定
このオプションは、size-rotating-file-handler ファイルハンドラーでのみ利用できます。デフォルトは false で、サーバーの再起動時に新しいログファイルは作成されません。
これを変更するには、次の構文で write-attribute 操作を使用します。
 /subsystem=logging/size-rotating-file-handler=HANDLER:write-attribute(name="rotate-on-boot", value="BOOLEAN") 
Copy to Clipboard Toggle word wrap
HANDLERsize-rotating-file-handler ログハンドラーの名前に置き換えます。再起動時に新しい size-rotating-file-handler ログファイルを作成する場合は、BOOLEANtrue に置き換えます。

例12.51 サーバーの再起動時に新しい size-rotating-file-handler ログファイルを作成するよう指定

[standalone@localhost:9999 /] /subsystem=logging/size-rotating-file-handler=ACCOUNTS_TRACE:write-attribute(name="rotate-on-boot", value="true")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
ローテーションされるログの接尾辞の設定
次の構文で write-attribute 操作を使用します。
 /subsystem=logging/size-rotating-file-handler=HANDLER:write-attribute(name="suffix", value="SUFFIX") 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。SUFFIX を、必要な接尾辞の文字列に置き換えます。

例12.52 ローテーションされるログの接尾辞の設定

[standalone@localhost:9999 /] /subsystem=logging/size-rotating-file-handler=ACCOUNTS_TRACE:write-attribute(name="suffix", value=".yyyy-MM-dd-HH")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
ログハンドラーの削除
以下の構文で remove 操作を使用します。
 /subsystem=logging/size-rotating-file-handler=HANDLER:remove 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。

例12.53 ログハンドラーの削除

[standalone@localhost:9999 /] /subsystem=logging/size-rotating-file-handler=ACCOUNTS_TRACE:remove
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap

12.3.7. CLI での Periodic Size rotating ログハンドラーの設定

Periodic Size Rotating ログハンドラーは CLI で追加、削除、および編集できます。
Periodic Size rotating ハンドラーを設定するために実行する主なタスクは以下のとおりです。
  • 新しい Periodic Size rotating ハンドラーを追加します。
  • Periodic Size rotating ハンドラーの設定を表示します。
  • ハンドラーのログレベルの設定
  • ハンドラーの追加動作の設定
  • ハンドラーによる自動フラッシュ使用の有無を設定し ます
  • ハンドラーの出力に使用されるエンコーディングの設定
  • ログハンドラーが書き込むファイルの指定
  • ハンドラーの出力に使用されるフォーマッターの設定
  • 各ログファイルの最大サイズを設定します。
  • 保持するバックアップログの最大数の設定
  • Periodic Size rotating ハンドラーのブート時のローテーションオプションを設定します。
  • ローテーションされるログの接尾辞を設定します。
  • Periodic Size rotating ハンドラーの削除。
これらの各タスクについては以下で説明します。
重要
スタンドアロンシステムのロギングプロファイルで Periodic Size rotating ハンドラーを設定する場合、設定パスのルートは /subsystem=logging/ ではなく /subsystem=logging/logging-profile=NAME/ になります。
管理対象ドメインでは、使用するプロファイルを指定する必要があります。管理対象ドメインの設定パスの先頭にプロファイル名を追加する必要があります。/subsystem=logging//profile=NAME/subsystem=logging/ に置き換えます。
新しい Periodic Size ローテーションハンドラーの追加
以下の構文で add 操作を使用します。
 /subsystem=logging/periodic-size-rotating-file-handler=HANDLER:add(file={"path"=>"PATH", "relative-to"=>"DIR"}) 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。PATH を、ログが書き込まれるファイルのファイル名に置き換えます。DIR は、ファイルが存在するディレクトリー名に置き換えます。DIR の値はパス変数になります。

例12.54 新しいログハンドラーの追加

[standalone@localhost:9999 /] /subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE:add(file={"path"=>"periodic_size.log","relative-to"=>"jboss.server.log.dir"},suffix=".yyyy.MM.dd")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
ログハンドラーの設定表示
以下の構文で read-resource 操作を使用します。
 /subsystem=logging/periodic-size-rotating-file-handler=HANDLER:read-resource 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。

例12.55 ログハンドラーの設定表示

[standalone@localhost:9999 /] /subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE:read-resource
{
    "outcome" => "success",
    "result" => {
        "append" => true,
        "autoflush" => true,
        "enabled" => true,
        "encoding" => undefined,
        "file" => {
            "relative-to" => "jboss.server.log.dir",
            "path" => "periodic_size.log"
        },
        "filter-spec" => undefined,
        "formatter" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n",
        "level" => "ALL",
        "max-backup-index" => 1,
        "name" => "PERIODIC_SIZE",
        "named-formatter" => undefined,
        "rotate-on-boot" => false,
        "rotate-size" => "2m",
        "suffix" => ".yyyy.MM.dd"
    }
}
Copy to Clipboard Toggle word wrap
ハンドラーのログレベルの設定
次の構文で write-attribute 操作を使用します。
 /subsystem=logging/periodic-size-rotating-file-handler=HANDLER:write-attribute(name="level", value="LOG_LEVEL_VALUE") 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。LOG_LEVEL_VALUE を設定するログレベルに置き換えます。

例12.56 ハンドラーのログレベルの設定

[standalone@localhost:9999 /] /subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE:write-attribute(name="level", value="TRACE")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
ハンドラーの追加動作の設定
次の構文で write-attribute 操作を使用します。
 /subsystem=logging/periodic-size-rotating-file-handler=HANDLER:write-attribute(name="append", value="BOOLEAN") 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。アプリケーションサーバーが起動されるたびに新しいログファイルを作成する必要がある場合は、BOOLEANfalse に置き換えます。アプリケーションサーバーが同じファイルを使用し続ける必要がある場合は、BOOLEANtrue に置き換えます。
この変更を反映するには、JBoss EAP 6 を再起動する必要があります。

例12.57 ハンドラーの追加動作の設定

[standalone@localhost:9999 /] /subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE:write-attribute(name="append", value="true")
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}
Copy to Clipboard Toggle word wrap
ハンドラーによる自動フラッシュ使用の有無を設定
次の構文で write-attribute 操作を使用します。
 /subsystem=logging/periodic-size-rotating-file-handler=HANDLER:write-attribute(name="autoflush", value="BOOLEAN") 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。このハンドラーが出力をすぐに書き込む場合は、BOOLEANtrue に置き換えます。

例12.58 ハンドラーによる自動フラッシュ使用の有無を設定

[standalone@localhost:9999 /] /subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE:write-attribute(name="autoflush", value="true")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
ハンドラーの出力に使用されるエンコーディングの設定
次の構文で write-attribute 操作を使用します。
 /subsystem=logging/periodic-size-rotating-file-handler=HANDLER:write-attribute(name="encoding", value="ENCODING") 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。ENCODING を、必要な文字エンコーディングシステムの名前に置き換えます。

例12.59 ハンドラーの出力に使用されるエンコーディングの設定

[standalone@localhost:9999 /] /subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE:write-attribute(name="encoding", value="utf-8")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
ログハンドラーが書き込むファイルの指定
次の構文で write-attribute 操作を使用します。
 /subsystem=logging/periodic-size-rotating-file-handler=HANDLER:write-attribute(name="file", value={"path"=>"PATH", "relative-to"=>"DIR"}) 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。PATH を、ログが書き込まれるファイルのファイル名に置き換えます。DIR は、ファイルが存在するディレクトリー名に置き換えます。DIR の値はパス変数になります。

例12.60 ログハンドラーが書き込むファイルの指定

[standalone@localhost:9999 /] /subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE:write-attribute(name="file", value={"path"=>"accounts_trace.log", "relative-to"=>"jboss.server.log.dir"})
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
ハンドラーの出力に使用されるフォーマッターの設定
次の構文で write-attribute 操作を使用します。
 /subsystem=logging/periodic-size-rotating-file-handler=HANDLER:write-attribute(name="formatter", value="FORMAT") 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。FORMAT は、設定ファイルで指定されているフォーマッター文字列またはフォーマッターの名前に置き換えます。

例12.61 ハンドラーの出力に使用されるフォーマッターの設定

[standalone@localhost:9999 /] /subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE:write-attribute(name="formatter", value="%d{HH:mm:ss,SSS} %-5p (%c) [%t] %s%E%n")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
各ログファイルの最大サイズの設定
次の構文で write-attribute 操作を使用します。
 /subsystem=logging/periodic-size-rotating-file-handler=HANDLER:write-attribute(name="rotate-size", value="SIZE") 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。SIZE はファイルの最大サイズに置き換えます。

例12.62 各ログファイルの最大サイズの設定

[standalone@localhost:9999 /] /subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE:write-attribute(name="rotate-size", value="50m")  
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
保持するバックアップログの最大数の設定
次の構文で write-attribute 操作を使用します。
 /subsystem=logging/periodic-size-rotating-file-handler=HANDLER:write-attribute(name="max-backup-index", value="NUMBER") 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。NUMBER を、保持するログファイルの数に置き換えます。

例12.63 保持するバックアップログの最大数の設定

[standalone@localhost:9999 /] /subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE:write-attribute(name="max-backup-index", value="5")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
periodic-size-rotating-file-handlerで rotate-on-boot オプションを設定します。
デフォルトは false で、サーバーの再起動時に新しいログファイルは作成されません。
これを変更するには、次の構文で write-attribute 操作を使用します。
 /subsystem=logging/periodic-size-rotating-file-handler=HANDLER:write-attribute(name="rotate-on-boot", value="BOOLEAN") 
Copy to Clipboard Toggle word wrap
HANDLERPeriodic-size-rotating-file-handler ログハンドラー の名前に置き換えます。再起動時に新しい Periodic-size-rotating-file-handler ログファイル を作成する場合は、BOOLEANtrue に置き換えます。

例12.64 サーバーの再起動時に新しい Periodic-size-rotating-file-handler ログファイルを作成するよう指定

[standalone@localhost:9999 /] /subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE:write-attribute(name="rotate-on-boot", value="true")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
ローテーションされるログの接尾辞の設定
次の構文で write-attribute 操作を使用します。
 /subsystem=logging/periodic-size-rotating-file-handler=HANDLER:write-attribute(name="suffix", value="SUFFIX") 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。SUFFIX を、必要な接尾辞の文字列に置き換えます。

例12.65 ローテーションされるログの接尾辞の設定

[standalone@localhost:9999 /] /subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE:write-attribute(name="suffix", value=".yyyy-MM-dd-HH")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
ログハンドラーの削除
以下の構文で remove 操作を使用します。
 /subsystem=logging/periodic-size-rotating-file-handler=HANDLER:remove 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。

例12.66 ログハンドラーの削除

[standalone@localhost:9999 /] /subsystem=logging/periodic-size-rotating-file-handler=PERIODIC_SIZE:remove
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap

12.3.8. CLI での非同期ログハンドラーの設定

非同期ログハンドラーは、CLI で追加、削除、および編集できます。
非同期ログハンドラーを設定するために実行するタスクは以下のとおりです。
  • 新しい非同期ログハンドラーの追加
  • 非同期ログハンドラーの設定表示
  • ログレベルの変更
  • キューの長さの設定
  • オーバーフローアクションの設定
  • サブハンドラーの追加
  • サブハンドラーの削除
  • 非同期ログハンドラーの削除
これらの各タスクについては以下で説明されています。
重要
ログハンドラーをスタンドアロンシステムのロギングプロファイルに設定する場合、設定パスのルートは /subsystem=logging/ ではなく /subsystem=logging/logging-profile=NAME/ になります。
管理対象ドメインでは、使用するプロファイルを指定する必要があります。管理対象ドメインの設定パスの先頭にプロファイル名を追加する必要があります。/subsystem=logging//profile=NAME/subsystem=logging/ に置き換えます。
新しい非同期ログハンドラーの追加
以下の構文で add 操作を使用します。
 /subsystem=logging/async-handler=HANDLER:add(queue-length="LENGTH") 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。LENGTH を、キューに保持できるログリクエストの最大数に置き換えます。

例12.67 新しい非同期ログハンドラーの追加

[standalone@localhost:9999 /] /subsystem=logging/async-handler=NFS_LOGS:add(queue-length="10")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
非同期ログハンドラーの設定表示
以下の構文で read-resource 操作を使用します。
 /subsystem=logging/async-handler=HANDLER:read-resource 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。

例12.68 非同期ログハンドラーの設定表示

[standalone@localhost:9999 /] /subsystem=logging/async-handler=NFS_LOGS:read-resource
{
    "outcome" => "success",
    "result" => {
        "enabled" => true,
        "encoding" => undefined,
        "filter" => undefined,
        "filter-spec" => undefined,
        "formatter" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n",
        "level" => "ALL",
        "name" => "NFS_LOGS",
        "overflow-action" => "BLOCK",
        "queue-length" => "10",
        "subhandlers" => undefined
    },
    "response-headers" => {"process-state" => "reload-required"}
}
Copy to Clipboard Toggle word wrap
ログレベルの変更
次の構文で write-attribute 操作を使用します。
 /subsystem=logging/async-handler=HANDLER:write-attribute(name="level", value="LOG_LEVEL_VALUE") 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。LOG_LEVEL_VALUE を設定するログレベルに置き換えます。

例12.69 ログレベルの変更

[standalone@localhost:9999 /] /subsystem=logging/async-handler=NFS_LOGS:write-attribute(name="level", value="INFO")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
キューの長さの設定
次の構文で write-attribute 操作を使用します。
 /subsystem=logging/async-handler=HANDLER:write-attribute(name="queue-length", value="LENGTH") 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。LENGTH を、キューに保持できるログリクエストの最大数に置き換えます。
この変更を反映するには、JBoss EAP 6 を再起動する必要があります。

例12.70 キューの長さの設定

[standalone@localhost:9999 /] /subsystem=logging/async-handler=NFS_LOGS:write-attribute(name="queue-length", value="150")
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}
Copy to Clipboard Toggle word wrap
オーバーフローアクションの設定
次の構文で write-attribute 操作を使用します。
 /subsystem=logging/async-handler=HANDLER:write-attribute(name="overflow-action", value="ACTION") 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。ACTION は、DISCARD または BLOCK に置き換えます。

例12.71 オーバーフローアクションの設定

[standalone@localhost:9999 /] /subsystem=logging/async-handler=NFS_LOGS:write-attribute(name="overflow-action", value="DISCARD")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
サブハンドラーの追加
次の構文で add-handler 操作を使用します。
 /subsystem=logging/async-handler=HANDLER:add-handler(name="SUBHANDLER") 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。SUBHANDLER を、この非同期ハンドラーのサブハンドラーとして追加するログハンドラーの名前に置き換えます。

例12.72 サブハンドラーの追加

[standalone@localhost:9999 /] /subsystem=logging/async-handler=NFS_LOGS:add-handler(name="NFS_FILE")       
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
サブハンドラーの削除
次の構文で remove-handler 操作を使用します。
/subsystem=logging/async-handler=HANDLER:remove-handler(name="SUBHANDLER")
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。SUBHANDLER を、削除するサブハンドラーの名前に置き換えます。

例12.73 サブハンドラーの削除

[standalone@localhost:9999 /] /subsystem=logging/async-handler=NFS_LOGS:remove-handler(name="NFS_FILE")       
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
非同期ログハンドラーの削除
以下の構文で remove 操作を使用します。
/subsystem=logging/async-handler=HANDLER:remove 
Copy to Clipboard Toggle word wrap
HANDLER をログハンドラーの名前に置き換えます。

例12.74 非同期ログハンドラーの削除

[standalone@localhost:9999 /] /subsystem=logging/async-handler=NFS_LOGS:remove       
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap

12.3.9. CLI でのカスタムハンドラーの設定

カスタムハンドラーは CLI で追加、削除、および編集できます。
カスタムハンドラーを設定するために実行する主なタスクは以下のとおりです。
  • 新しいカスタムハンドラーを追加します。
  • カスタムハンドラーの設定表示
  • ログレベルを設定します。
  • カスタムハンドラーの削除
重要
カスタムハンドラーをスタンドアロンシステムのロギングプロファイルに設定する場合、設定パスのルートは /subsystem=logging/ ではなく /subsystem=logging/logging-profile=NAME/ になります。
管理対象ドメインでは、使用するプロファイルを指定する必要があります。管理対象ドメインの設定パスの先頭にプロファイル名を追加する必要があります。/subsystem=logging//profile=NAME/subsystem=logging/ に置き換えます。
新しいカスタムハンドラーの追加
以下の構文で add 操作を使用します。
/subsystem=logging/custom-handler="MyCustomHandler":add
Copy to Clipboard Toggle word wrap

例12.75 新しいカスタムハンドラーの追加

[standalone@localhost:9999 /] /subsystem=logging/custom-handler="MyCustomHandler":add(class="JdbcLogger",module="com.MyModule",formatter="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n",properties={"maxNumberOfDays"=>"90","fileName"=>"custom.log","compressBackups"=>"true"})
Copy to Clipboard Toggle word wrap
カスタムハンドラーの表示
以下の構文で read-resource 操作を使用します。CUSTOMHANDLER をカスタムハンドラーの名前に置き換えます。
/subsystem=logging/custom-handler=CUSTOMHANDLER:read-resource
Copy to Clipboard Toggle word wrap

例12.76 カスタムハンドラー設定の表示

[standalone@localhost:9999 /] /subsystem=logging/custom-handler="MyCustomHandler":read-resource
{
    "outcome" => "success",
    "result" => {
        "autoflush" => true,
        "enabled" => true,
        "encoding" => undefined,
        "filter" => undefined,
        "filter-spec" => undefined,
        "formatter" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n",
        "level" => "INFO",
        "name" => "CONSOLE",
        "named-formatter" => "COLOR-PATTERN",
        "target" => "System.out"
    }
}
Copy to Clipboard Toggle word wrap
ログレベルの設定
次の構文で write-attribute 操作を使用します。CUSTOMHANDLER はログカテゴリーの名前に、LEVEL は設定するログレベルに置き換えます。
/subsystem=logging/custom-handler=CUSTOMHANDLER:write-attribute(name="level", value="INFO") 
Copy to Clipboard Toggle word wrap

例12.77 ログレベルの設定

[standalone@localhost:9999 /] /subsystem=logging/custom-handler="MyCustomHandler":write-attribute(name="level", value="TRACE")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap
カスタムハンドラーの削除
以下の構文で remove 操作を使用します。CUSTOMHANDLER を、削除するカスタムハンドラーの名前に置き換えます。
/subsystem=logging/custom-handler=CUSTOMHANDLER:remove
Copy to Clipboard Toggle word wrap

例12.78 カスタムハンドラーの削除

[standalone@localhost:9999 /] /subsystem=logging/custom-handler="MyCustomHandler":remove
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap

12.3.10. CLI での Syslog ハンドラーの設定

JBoss EAP 6 のログマネージャーに Syslog ハンドラーが含まれるようになりました。Syslog ハンドラーは、Syslog プロトコル(RFC-3164 または RFC-5424)をサポートするリモートロギングサーバーにメッセージを送信するために使用できます。これにより、複数のアプリケーションのログメッセージを同じサーバーに送信できます。これにより、複数のアプリケーションのログメッセージを解析できます。このトピックでは、管理 CLI を使用して Syslog ハンドラーを作成および設定する方法と、利用可能な設定オプションについて説明します。
Syslog ハンドラー属性の詳細は、「管理インターフェース監査ロギングリファレンス」 を参照してください。

前提条件

  • 管理 CLI のアクセスおよび適切なパーミッション。

手順12.4 Syslog ハンドラーの追加

  • 以下のコマンドを実行して syslog ハンドラーを追加します。
    /subsystem=logging/syslog-handler=HANDLER_NAME:add
    Copy to Clipboard Toggle word wrap

手順12.5 Syslog ハンドラーの設定

  • 以下のコマンドを実行して Syslog ハンドラー属性を設定します。
    /subsystem=logging/syslog-handler=HANDLER_NAME:write-attribute(name=ATTRIBUTE_NAME,value=ATTRIBUTE_VALUE)
    Copy to Clipboard Toggle word wrap

手順12.6 Syslog ハンドラーの削除

  • 以下のコマンドを実行して既存の syslog ハンドラーを削除します。
    /subsystem=logging/syslog-handler=HANDLER_NAME:remove
    Copy to Clipboard Toggle word wrap

12.3.11. CLI でのカスタムログフォーマッターの設定

概要

「ログフォーマッター構文」 で指定したログフォーマッター構文の他に、任意のログハンドラーで使用するカスタムログフォーマッターを作成できます。この手順では、コンソールログハンドラーの XML フォーマッターを作成して説明します。

前提条件

  • JBoss EAP 6 サーバーの管理 CLI へのアクセス。
  • 以前設定されたログハンドラー。この手順例では、Console ログハンドラーを使用します。

手順12.7 ログハンドラーのカスタム XML フォーマッターの設定

  1. カスタムフォーマッターを作成します。
    この例では、以下のコマンドで java.util.logging.XMLFormatter クラスを使用する XML_FORMATTER という名前のカスタムフォーマッターを作成します。
    [standalone@localhost:9999 /] /subsystem=logging/custom-formatter=XML_FORMATTER:add(class=java.util.logging.XMLFormatter, module=org.jboss.logmanager)
    Copy to Clipboard Toggle word wrap
  2. 使用したいログハンドラーのカスタムフォーマッターを登録します。
    この例では、前の手順のフォーマッターがコンソールログハンドラーに追加されます。
    [standalone@localhost:9999 /] /subsystem=logging/console-handler=HANDLER:write-attribute(name=named-formatter, value=XML_FORMATTER)
    Copy to Clipboard Toggle word wrap
  3. JBoss EAP 6 サーバーを再起動し、変更を反映します。
    [standalone@localhost:9999 /] shutdown --restart=true
    Copy to Clipboard Toggle word wrap

結果

カスタム XML フォーマッターがコンソールログハンドラーに追加されます。コンソールログの出力は XML でフォーマットされます。以下に例を示します。

<record>
  <date>2014-03-11T13:02:53</date>
  <millis>1394539373833</millis>
  <sequence>116</sequence>
  <logger>org.jboss.as</logger>
  <level>INFO</level>
  <class>org.jboss.as.server.BootstrapListener</class>
  <method>logAdminConsole</method>
  <thread>282</thread>
  <message>JBAS015951: Admin console listening on http://%s:%d</message>
  <param>127.0.0.1</param>
  <param>9990</param>
</record>
Copy to Clipboard Toggle word wrap

12.4. デプロイメントごとのロギング

12.4.1. デプロイメントごとのロギング

デプロイメントごとのロギングを使用すると、開発者はアプリケーションのロギング設定を事前に設定できます。アプリケーションがデプロイされると、定義された設定に従ってロギングが開始されます。この設定によって作成されたログファイルにはアプリケーションの動作に関する情報のみが含まれます。
この方法では、システム全体のロギングを使用する利点と欠点があります。利点は、JBoss EAP インスタンスの管理者がロギングを設定する必要がないことです。欠点は、デプロイメントごとのロギング設定は起動時に読み取り専用であるため、実行時に変更できないことです。

12.4.2. デプロイメントごとのロギングの無効化

手順12.8 デプロイメントごとのロギングの無効化

  • デプロイメントごとのロギングを無効にする方法は 2 つあります。1 つはすべてのバージョンの JBoss EAP 6 で動作しますが、もう 1 つは JBoss EAP 6.3 以降でのみ動作します。

    • JBoss EAP 6 (全バージョン)

      システムプロパティーを追加します。
      org.jboss.as.logging.per-deployment=false
      
      Copy to Clipboard Toggle word wrap
    • JBoss EAP 6.3 (およびそれ以降のバージョン)

      jboss-deployment-structure.xml ファイルを使用して logging サブシステムを除外します。詳細は、『『開発ガイド』』 の「 『サブシステムをデプロイメントから除外」を』 参照してください。

12.5. ロギングプロファイル

12.5.1. ロギングプロファイル

重要
ロギングプロファイルは、6.1.0 以降のバージョンでのみ利用できます。管理コンソールを使用して設定することはできません。
ロギングプロファイルは、デプロイされたアプリケーションに割り当てることができる独立したロギング設定のセットです。通常の logging サブシステムと同様に、ロギングプロファイルはハンドラー、カテゴリー、ルートロガーを定義できますが、他のプロファイルやメインの logging サブシステムを参照できません。設定を容易にするため、ロギングプロファイルは logging サブシステムと似ています。
ロギングプロファイルを使用すると、管理者は他のロギング設定に影響を与えずに 1 つ以上のアプリケーションに固有するロギング設定を作成できます。各プロファイルはサーバー設定で定義されるため、ロギング設定を変更しても影響を受けるアプリケーションを再デプロイする必要はありません。
各ロギングプロファイルに含めることができる設定は次のとおりです。
  • 一意な名前これは必須です。
  • 任意の数のログハンドラー。
  • 任意の数のログカテゴリー。
  • 最大 1 つのルートロガー。
アプリケーションは logging-profile 属性を使用して MANIFEST.MF ファイルで使用するロギングプロファイルを指定できます。

12.5.2. CLI を使用した新しいロギングプロファイルの作成

以下の CLI コマンドを使用して新しいロギングプロファイルを作成できます。NAME は必要なプロファイル名に置き換えます。
/subsystem=logging/logging-profile=NAME:add
Copy to Clipboard Toggle word wrap
これにより、ハンドラー、カテゴリー、およびルートロガーを追加できる新しい空のプロファイルが作成されます。

12.5.3. CLI を使用したロギングプロファイルの設定

メインロギングシステムを使用した場合とほぼ同じ構文を用いて、ログハンドラー、カテゴリーおよびルートロガーを使用してロギングプロファイルを設定できます。
メインロギングサブシステムの設定とロギングプロファイルの設定で異なる点は以下の 2 つのみです。
  1. ルート設定パスは以下のとおりです。 /subsystem=logging/logging-profile=NAME
  2. ロギングプロファイルに他のロギングプロファイルを追加できません。
以下のロギング管理タスクを参照してください。

例12.79 ロギングプロファイルの作成および設定

ロギングプロファイルの作成およびカテゴリーとファイルログハンドラーの追加。
  1. プロファイルを作成します。
    /subsystem=logging/logging-profile=accounts-app-profile:add
    Copy to Clipboard Toggle word wrap
  2. ファイルハンドラーの作成
    /subsystem=logging/logging-profile=accounts-app-profile/file-handler=ejb-trace-file:add(file={path=>"ejb-trace.log", "relative-to"=>"jboss.server.log.dir"})
    Copy to Clipboard Toggle word wrap
    /subsystem=logging/logging-profile=accounts-app-profile/file-handler=ejb-trace-file:write-attribute(name="level", value="DEBUG")
    Copy to Clipboard Toggle word wrap
  3. ロガーカテゴリーの作成
    /subsystem=logging/logging-profile=accounts-app-profile/logger=com.company.accounts.ejbs:add(level=TRACE)
    Copy to Clipboard Toggle word wrap
  4. ファイルハンドラーをカテゴリーへ割り当て
    /subsystem=logging/logging-profile=accounts-app-profile/logger=com.company.accounts.ejbs:add-handler(name="ejb-trace-file")
    Copy to Clipboard Toggle word wrap

12.5.4. アプリケーションでのロギングプロファイルの指定

アプリケーションは使用するロギングプロファイルを MANIFEST.MF ファイルに指定します。

要件:

  1. このアプリケーションが使用するサーバー上に設定されたロギングプロファイルの名前を知っている必要があります。サーバー管理者に対し、使用するプロファイルの名前を要求します。

手順12.9 ロギングプロファイル設定のアプリケーションへの追加

  • MANIFEST.MFの編集

    アプリケーションに MANIFEST.MF ファイルがない場合: 以下の内容が含まれるファイルを作成します。NAME は必要なプロファイル名に置き換えます。
    Manifest-Version: 1.0
    Logging-Profile: NAME
    Copy to Clipboard Toggle word wrap
    アプリケーションに MANIFEST.MF ファイルがすでにある場合は、以下の行をそのファイルに追加します。NAME は必要なプロファイル名に置き換えます。
    Logging-Profile: NAME
    Copy to Clipboard Toggle word wrap
注記
Maven および maven-war-plugin を使用している場合は、MANIFEST.MF ファイルを src/main/resources/META-INF/ に置き、以下の設定を pom.xml ファイルに追加します。
<plugin>
  <artifactId>maven-war-plugin</artifactId>
  <configuration>
    <archive>
      <manifestFile>src/main/resources/META-INF/MANIFEST.MF</manifestFile>  
    </archive>
  </configuration>
</plugin>
Copy to Clipboard Toggle word wrap
アプリケーションがデプロイされると、ログメッセージに対して指定されたロギングプロファイルの設定を使用します。

12.5.5. ロギングプロファイル設定の例

この例は、ロギングプロファイルの設定と、そのプロファイルを使用するアプリケーションを示しています。CLI セッション、生成された XML 設定、およびアプリケーションの MANIFEST.MF ファイルが表示されます。
ロギングプロファイルの例には以下が指定されています。
  • Name は accounts-app-profile です。
  • ログカテゴリーは com.company.accounts.ejbs です。
  • ログレベル TRACE
  • ログハンドラーは、ejb-trace.log ファイルを使用するファイルハンドラーです。

例12.80 CLI セッション

localhost:bin user$ ./jboss-cli.sh -c
[standalone@localhost:9999 /] /subsystem=logging/logging-profile=accounts-app-profile:add
{"outcome" => "success"}

[standalone@localhost:9999 /] /subsystem=logging/logging-profile=accounts-app-profile/file-handler=ejb-trace-file:add(file={path=>"ejb-trace.log", "relative-to"=>"jboss.server.log.dir"})
{"outcome" => "success"}

[standalone@localhost:9999 /] /subsystem=logging/logging-profile=accounts-app-profile/file-handler=ejb-trace-file:write-attribute(name="level", value="DEBUG")
{"outcome" => "success"}

[standalone@localhost:9999 /] /subsystem=logging/logging-profile=accounts-app-profile/logger=com.company.accounts.ejbs:add(level=TRACE)
{"outcome" => "success"}

[standalone@localhost:9999 /] /subsystem=logging/logging-profile=accounts-app-profile/logger=com.company.accounts.ejbs:add-handler(name="ejb-trace-file")
{"outcome" => "success"}
Copy to Clipboard Toggle word wrap

例12.81 XML の設定

<logging-profiles>
   <logging-profile name="accounts-app-profile">
      <file-handler name="ejb-trace-file">
         <level name="DEBUG"/>
         <file relative-to="jboss.server.log.dir" path="ejb-trace.log"/>
      </file-handler>
      <logger category="com.company.accounts.ejbs">
         <level name="TRACE"/>
         <handlers>
            <handler name="ejb-trace-file"/>
         </handlers>
      </logger>
   </logging-profile>
</logging-profiles>
Copy to Clipboard Toggle word wrap

例12.82 アプリケーションの MANIFEST.MF ファイル

Manifest-Version: 1.0
Logging-Profile: accounts-app-profile
Copy to Clipboard Toggle word wrap

12.6. ロギング設定プロパティー

12.6.1. ルートロガーのプロパティー

Expand
表12.6 ルートロガーのプロパティー
プロパティー データタイプ 説明
level 文字列
ルートロガーが記録するログメッセージの最大レベル。
handlers String[]
ルートロガーによって使用されるログハンドラーの一覧。
filter-spec 文字列
フィルターを定義する式の値。式 not (match("JBAS.*"))は、パターンに一致しないログエントリーを除外するフィルターを定義します。
注記
ルートロガーに指定された filter-spec は他のハンドラーによって継承され ません。代わりに、ハンドラーごとに filter-spec を指定する必要があります。

12.6.2. ログカテゴリーのプロパティー

Expand
表12.7 ログカテゴリーのプロパティー
プロパティー データタイプ 説明
level 文字列
ログカテゴリーが記録するログメッセージの最大レベル。
handlers String[]
ロガーに関連付けられたログハンドラーのリスト。
use-parent-handlers ブール値
true に設定した場合、割り当てられた他のハンドラーだけでなく、ルートロガーのログハンドラーを使用します。
category 文字列
ログメッセージがキャプチャーされるログカテゴリー。
filter-spec 文字列
フィルターを定義する式の値。式 not(match ("JBAS.*")はパターンに一致しないフィルターを定義します。

12.6.3. コンソールログハンドラーのプロパティー

Expand
表12.8 コンソールログハンドラーのプロパティー
プロパティー データタイプ 説明
level 文字列
ログハンドラーが記録するログメッセージの最大レベル。
encoding 文字列
出力に使用する文字エンコーディングスキーム。
formatter 文字列
このログハンドラーで使用するログフォーマッター。
named-formatter 文字列
ハンドラーで使用する定義されたフォーマッターの名前。
target 文字列
ログハンドラーの出力があるシステム出力ストリーム。システムエラーストリームの場合は System.err または System.out のいずれかになります。
autoflush ブール値
true に設定すると、ログメッセージは受信直後にハンドラーのターゲットに送信されます。
name 文字列
このログハンドラーの一意の ID。
enabled ブール値
true に設定された場合、ハンドラーが有効になり、通常とおり機能します。false に設定された場合、ログメッセージの処理時にハンドラーが無視されます。
filter-spec 文字列
フィルターを定義する式の値。式 not(match ("JBAS.*")はパターンに一致しないフィルターを定義します。

12.6.4. ファイルログハンドラープロパティー

Expand
表12.9 ファイルログハンドラープロパティー
プロパティー データタイプ 説明
level 文字列
ログハンドラーが記録するログメッセージの最大レベル。
encoding 文字列
出力に使用する文字エンコーディングスキーム。
formatter 文字列
このログハンドラーで使用するログフォーマッター。
named-formatter 文字列
ハンドラーで使用する定義されたフォーマッターの名前。
append ブール値
true に設定された場合、このハンドラーが書き込んだすべてのメッセージがファイル(すでに存在する場合)に追加されます。false に設定すると、アプリケーションサーバーが起動されるたびに、新しいファイルが作成されます。append を変更するには、サーバーを再起動する必要があります。
autoflush ブール値
true に設定すると、ログメッセージは受信直後にハンドラー割り当てファイルに送信されます。
name 文字列
このログハンドラーの一意の ID。
file オブジェクト
このログハンドラーの出力が書き込まれるファイルを表すオブジェクト。これには、relative-topath の 2 つの設定プロパティーがあります。
relative-to 文字列
これは、ファイルオブジェクトのプロパティーであり、ログファイルが書き込まれるディレクトリーです。ここでは JBoss EAP 6 のファイルパス変数を指定できます。jboss.server.log.dir 変数は、サーバーの log/ ディレクトリーを参照します。
path 文字列
ファイルオブジェクトのプロパティーであり、ログメッセージが書き込まれるファイルの名前です。完全パスを決定するために、relative-to プロパティーの値に追加される相対パス名です。
enabled ブール値
true に設定された場合、ハンドラーが有効になり、通常とおり機能します。false に設定された場合、ログメッセージの処理時にハンドラーが無視されます。
filter-spec 文字列
フィルターを定義する式の値。式 not(match ("JBAS.*")はパターンに一致しないフィルターを定義します。

12.6.5. 周期ログハンドラープロパティー

Expand
表12.10 周期ログハンドラープロパティー
プロパティー データタイプ 説明
append ブール値
true に設定された場合、このハンドラーが書き込んだすべてのメッセージがファイル(すでに存在する場合)に追加されます。false に設定すると、アプリケーションサーバーが起動されるたびに、新しいファイルが作成されます。append への変更を反映するには、サーバーを再起動する必要があります。
autoflush ブール値
true に設定すると、ログメッセージは受信直後にハンドラー割り当てファイルに送信されます。
encoding 文字列
出力に使用する文字エンコーディングスキーム。
formatter 文字列
このログハンドラーで使用するログフォーマッター。
named-formatter 文字列
ハンドラーで使用する定義されたフォーマッターの名前。
level 文字列
ログハンドラーが記録するログメッセージの最大レベル。
name 文字列
このログハンドラーの一意の ID。
file オブジェクト
このログハンドラーの出力が書き込まれるファイルを表すオブジェクト。これには、relative-topath の 2 つの設定プロパティーがあります。
relative-to 文字列
これは、ファイルオブジェクトのプロパティーで、ログファイルが含まれるディレクトリーです。ここでは、ファイルパス変数を指定できます。jboss.server.log.dir 変数は、サーバーの log/ ディレクトリーを参照します。
path 文字列
ファイルオブジェクトのプロパティーであり、ログメッセージが書き込まれるファイルの名前です。完全パスを決定するために、relative-to プロパティーの値に追加される相対パス名です。
接尾辞 文字列
この文字列はローテーションされたログのファイル名に追加され、ローテーションの頻度を決定するために使用されます。接尾辞の形式はドット(.)の後に date String が続きます。これは、SimpleDateFormat クラスによって解析できます。ログは、接尾辞で定義される最小時間単位に基づいてローテーションされます。suffix 属性で許可される最小時間の単位は分であることに注意してください。
たとえば、接尾辞 の値が .YYYY-MM-dd の場合は、ログが毎日ローテーションされます。server.log という名前のログファイルと 接尾辞 の値が .YYYY-MM-dd の場合、2014 年 10 月 20 日にローテーションされたログファイルの名前は server.log.2014-10-19 に なります。Periodic ログハンドラーの場合、接尾辞には最小時間単位の以前の値が含まれます。この例では、dd の値は 19 (前の日)です。
enabled ブール値
true に設定された場合、ハンドラーが有効になり、通常とおり機能します。false に設定された場合、ログメッセージの処理時にハンドラーが無視されます。
filter-spec 文字列
フィルターを定義する式の値。式 not(match("JBAS.*")) はパターンに一致しないフィルターを定義します。

12.6.6. サイズログハンドラープロパティー

Expand
表12.11 サイズログハンドラープロパティー
プロパティー データタイプ 説明
append ブール値
true に設定された場合、このハンドラーが書き込んだすべてのメッセージがファイル(すでに存在する場合)に追加されます。false に設定すると、アプリケーションサーバーが起動されるたびに、新しいファイルが作成されます。append への変更を反映するには、サーバーを再起動する必要があります。
autoflush ブール値
true に設定すると、ログメッセージは受信直後にハンドラー割り当てファイルに送信されます。
encoding 文字列
出力に使用する文字エンコーディングスキーム。
formatter 文字列
このログハンドラーで使用するログフォーマッター。
named-formatter 文字列
ハンドラーで使用する定義されたフォーマッターの名前。
level 文字列
ログハンドラーが記録するログメッセージの最大レベル。
name 文字列
このログハンドラーの一意の ID。
file オブジェクト
このログハンドラーの出力が書き込まれるファイルを表すオブジェクト。これには、relative-topath の 2 つの設定プロパティーがあります。
relative-to 文字列
これは、ファイルオブジェクトのプロパティーで、ログファイルが含まれるディレクトリーです。ここでは、ファイルパス変数を指定できます。jboss.server.log.dir 変数は、サーバーの log/ ディレクトリーを参照します。
path 文字列
ファイルオブジェクトのプロパティーであり、ログメッセージが書き込まれるファイルの名前です。完全パスを決定するために、relative-to プロパティーの値に追加される相対パス名です。
rotate-size 整数
ログファイルがローテーションされる前に到達できる最大サイズです。数字に追加された単一の文字はサイズ単位を示します。バイトの場合は b、キロバイトの場合は k、メガバイトの場合は m、ギガバイトの場合は g になります。たとえば、50 メガバイトの場合は 50m になります。
max-backup-index 整数
保持するローテーションログの最大数。この数に達すると、古いログが再使用されます。デフォルト: 1
JBoss EAP 6.4 から利用できます。suffix 属性が使用された場合は、ローテーションログファイルの接尾辞がローテーションアルゴリズムに含まれます。ログファイルがローテーションされると、名前が name+suffix で始まる最も古いファイルが削除され、残りのローテーションログファイルの数値接尾辞が増分され、新しくローテーションされたログファイルに数値接尾辞 1 が提供されます。
ログファイル名 server.log接尾辞 の値が .YYYY-mm、および max-backup-index の値が 3 を想定します。ログファイルが 2 回ローテーションされると、ログファイル名は server.log、server.log.2014-10.1、および server.log.2014-10.2 の可能性があります。次回のログファイルがローテーションされると、server.log.2014- 10. 2 が削除され、server.log.2014-10.1 の名前が server.log.2014 -10. 2 に変更され、新たにローテーションされたログファイルの名前は server.log.2014-10. 1 になります。
enabled ブール値
true に設定された場合、ハンドラーが有効になり、通常とおり機能します。false に設定された場合、ログメッセージの処理時にハンドラーが無視されます。
filter-spec 文字列
フィルターを定義する式の値。式 not(match ("JBAS.*")はパターンに一致しないフィルターを定義します。
rotate-on-boot ブール値
true に設定されると、新しいログファイルがサーバーの起動時に作成されます。デフォルトは false です。
接尾辞 文字列
JBoss EAP 6.4 から利用できます。この文字列はローテーションログに追加される接尾辞に含まれます。接尾辞 の形式はドット(.)の後に SimpleDateFormat クラスが解析できる日付文字列です。
たとえば、server.log という名前のログファイルと 接尾辞 の値が .YYYY-mm の場合、1 年 10 月 1 日にローテーションされる最初のログファイルの名前は server.log.2014-10.1 になります。この例では、接尾辞の 2014-10 部分は接尾辞の値から派生しています。

12.6.7. Periodic Size rotating ログハンドラープロパティー

Expand
表12.12 Periodic Size ログハンドラープロパティー
プロパティー データタイプ 説明
append ブール値
true に設定された場合、このハンドラーが書き込んだすべてのメッセージがファイル(すでに存在する場合)に追加されます。false に設定すると、アプリケーションサーバーが起動されるたびに、新しいファイルが作成されます。append への変更を反映するには、サーバーを再起動する必要があります。
rotate-size 文字列
ログファイルがローテーションされる前に到達できる最大サイズです。
max-backup-index 整数
保持されるサイズローテーションログの最大数。この数に達すると、古いログが再使用されます。デフォルト: 1
この設定は、ファイルサイズに基づいてローテーションされるログにのみ適用されます。
ファイルが日付形式のサフィックスでローテーションされている場合は、max-backup-index オプションを使用してパージされないことに注意してください。
接尾辞 文字列
この文字列はローテーションされたログのファイル名に追加され、ローテーションの頻度を決定するために使用されます。接尾辞の形式はドット(.)の後に date String が続きます。これは、SimpleDateFormat クラスによって解析できます。ログは、接尾辞で定義される最小時間単位に基づいてローテーションされます。suffix 属性で許可される最小時間の単位は分であることに注意してください。
たとえば、接尾辞 の値が .YYYY-MM-dd の場合は、ログが毎日ローテーションされます。server.log という名前のログファイルと 接尾辞 の値が .YYYY-MM-dd の場合、2014 年 10 月 20 日にローテーションされたログファイルの名前は server.log.2014-10-19 に なります。Periodic ログハンドラーの場合、接尾辞には最小時間単位の以前の値が含まれます。この例では、dd の値は 19 (前の日)です。
autoflush ブール値
true に設定すると、ログメッセージは受信直後にハンドラー割り当てファイルに送信されます。
file オブジェクト
このログハンドラーの出力が書き込まれるファイルを表すオブジェクト。これには、relative-topath の 2 つの設定プロパティーがあります。
relative-to 文字列
これは、ファイルオブジェクトのプロパティーで、ログファイルが含まれるディレクトリーです。ここでは、ファイルパス変数を指定できます。jboss.server.log.dir 変数は、サーバーの log/ ディレクトリーを参照します。
path 文字列
ファイルオブジェクトのプロパティーであり、ログメッセージが書き込まれるファイルの名前です。完全パスを決定するために、relative-to プロパティーの値に追加される相対パス名です。
enabled ブール値
true に設定された場合、ハンドラーが有効になり、通常とおり機能します。false に設定された場合、ログメッセージの処理時にハンドラーが無視されます。
filter-spec 文字列
フィルターを定義する式の値。式 not(match ("JBAS.*")はパターンに一致しないフィルターを定義します。
rotate-on-boot ブール値
true に設定されると、新しいログファイルがサーバーの起動時に作成されます。デフォルトは false です。
formatter 文字列
このログハンドラーで使用するログフォーマッター。
level 文字列
ログハンドラーが記録するログメッセージの最小レベル。
name 文字列
このログハンドラーの一意の ID。
named-formatter 文字列
ハンドラーで使用する定義されたフォーマッターの名前。
encoding 文字列
出力に使用する文字エンコーディングスキーム。

12.6.8. 同期ログハンドラープロパティー

Expand
表12.13 同期ログハンドラープロパティー
プロパティー データタイプ 説明
level 文字列
ログハンドラーが記録するログメッセージの最大レベル。
name 文字列
このログハンドラーの一意の ID。
encoding 文字列
出力に使用する文字エンコーディングスキーム。
formatter 文字列
このログハンドラーで使用するログフォーマッター。
queue-length Integer
サブハンドラーが応答するときに、このハンドラーが保持するログメッセージの最大数。
overflow-action 文字列
キューの長さを超えたときにこのハンドラーがどのように応答するかを示します。これは BLOCK または DISCARD に設定できます。BLOCK により、キューでスペースが利用可能になるまでロギングアプリケーションが待機します。これは、非同期でないログハンドラーと同じ動作です。DISCARD により、ロギングアプリケーションは動作し続けますが、ログメッセージは削除されます。
subhandlers String[]
これは、この非同期ハンドラーがログメッセージを渡すログハンドラーの一覧です。
enabled ブール値
true に設定された場合、ハンドラーが有効になり、通常とおり機能します。false に設定された場合、ログメッセージの処理時にハンドラーが無視されます。
filter-spec 文字列
フィルターを定義する式の値。式 not(match ("JBAS.*")はパターンに一致しないフィルターを定義します。

12.7. ロギング用 XML 設定例

12.7.1. ルートロガーの XML 設定例

<root-logger>
  <level name="INFO"/>
  <handlers>
    <handler name="CONSOLE"/>
      <handler name="FILE"/>
  </handlers>
</root-logger>
Copy to Clipboard Toggle word wrap

12.7.2. ログカテゴリーの XML 設定例

<logger category="com.company.accounts.rec">
  <handlers>
    <handler name="accounts-rec"/>
  </handlers>
</logger>
Copy to Clipboard Toggle word wrap

12.7.3. コンソールログハンドラーの XML 設定例

<console-handler name="CONSOLE">
  <level name="INFO"/>
  <formatter>
    <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
  </formatter>
</console-handler>
Copy to Clipboard Toggle word wrap

12.7.4. ファイルログハンドラーの XML 設定例

<file-handler name="accounts-rec-trail" autoflush="true">
    <level name="INFO"/>
    <file relative-to="jboss.server.log.dir" path="accounts-rec-trail.log"/>
    <append value="true"/>
</file-handler>
Copy to Clipboard Toggle word wrap

12.7.5. 定期ログハンドラーの XML 設定例

<periodic-rotating-file-handler name="FILE">
   <formatter>
      <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
   </formatter>
   <file relative-to="jboss.server.log.dir" path="server.log"/>
   <suffix value=".yyyy-MM-dd"/>
   <append value="true"/>
</periodic-rotating-file-handler>
Copy to Clipboard Toggle word wrap

12.7.6. サイズログハンドラーの XML 設定例

<size-rotating-file-handler name="accounts_debug" autoflush="false">
   <level name="DEBUG"/>
   <file relative-to="jboss.server.log.dir" path="accounts-debug.log"/>
   <rotate-size value="500k"/>
   <max-backup-index value="5"/>
   <append value="true"/>
</size-rotating-file-handler>
Copy to Clipboard Toggle word wrap

12.7.7. Periodic Size Rotating ログハンドラーの XML 設定例

<periodic-size-rotating-file-handler name="Periodic_size_rotating_Handler" autoflush="false">
  <level name="INFO"/>
  <file relative-to="jboss.server.log.dir" path="Sample.log"/>
  <max-backup-index value="1"/>
  <suffix value=".yyyy.MM.dd"/>
  <append value="false"/>
<periodic-size-rotating-file-handler>
Copy to Clipboard Toggle word wrap

12.7.8. 非同期ログハンドラーの XML 設定例

<async-handler name="Async_NFS_handlers">
   <level name="INFO"/>
   <queue-length value="512"/>
   <overflow-action value="block"/>
   <subhandlers>
      <handler name="FILE"/>
      <handler name="accounts-record"/>
   </subhandlers>
</async-handler>
Copy to Clipboard Toggle word wrap

第13章 Infinispan

13.1. Infinispan

Infinispan は Java グリッドプラットフォームです。キャッシュされたデータを管理するための JSR-107 と互換性のあるキャッシュインターフェースを提供します。
JBoss Enterprise Application Platform 6 では以下の Infinispan キャッシュコンテナが使用されます。
  • Web (Web セッションクラスタリング)
  • EJB (ステートフルセッション Bean クラスタリング)
  • hibernate (エンティティーキャッシング)
  • シングルトン キャッシングのシングルトン
各キャッシュコンテナーは「repl」と「dist」キャッシュを定義します。これらのキャッシュは、ユーザーアプリケーションで直接使用しないでください。
重要
ユーザーはキャッシュコンテナーおよびキャッシュをさらに追加し、JNDI 経由で参照できます。ただし、これは JBoss Enterprise Application Platform 6 ではサポートされません。
Infinispan の機能や設定オプションの詳細は Infinispan のドキュメント を参照して ください

13.2. クラスタリングモード

JBoss EAP 6 では Infinispan を使用する 2 つの方法でクラスタリングを設定できます。アプリケーションの正しい方法は要件によって異なります。各モードでは可用性、一貫性、信頼性、スケーラビリティーのトレードオフが発生します。クラスタリングモードを選択する前に、ネットワークで最も重要な点を特定し、これらの要件のバランスを取ることが必要となります。

レプリケートモード

レプリケートモードはクラスターの新規インスタンスを自動的に検出し、追加します。これらのインスタンスに加えられた変更は、クラスター上のすべてのノードにレプリケートされます。ネットワークでレプリケートされる情報量が多いため、通常 Replicatedモードは小型のクラスターでの使用に最も適しています。UDP マルチキャストを使用するよう Infinispan を設定すると、ネットワークトラフィックの輻輳をある程度軽減できます。

ディストリビューションモード

Distribution (分散) モードでは、Infinispan はクラスターを線形にスケールできます。Distribution モードは一貫性のあるハッシュアルゴリズムを使用して、クラスター内で新しいノードを配置する場所を決定します。保持する情報のコピー数は設定可能です。保持するコピー数、データの持続性、およびパフォーマンスの持続性にはトレードオフが生じます。たとえば、保持するコピー数が多いほど、パフォーマンスへの影響が大きくなりますが、サーバーの障害時にデータが失われる可能性は低くなります。ハッシュアルゴリズムは、メタデータのマルチキャストや保存を行わずにエントリーを配置し、ネットワークトラフィックを軽減します。

クラスターサイズが 6-8 ノードを超える場合は Distribution(dist)モードをキャッシュストラテジーとして使用することを検討する必要があります。Distribution モードでは、データはクラスター内のすべてのノード(デフォルトの Replicated モード)ではなくノードのサブセットのみに分散されます。

同期および非同期のレプリケーション

レプリケーションは同期または非同期モードで実行でき、選択するモードは要件やアプリケーションモードによって異なります。同期のレプリケーションでは、ユーザーリクエストを処理するスレッドはレプリケーションが正常に実行されるまでブロックされます。レプリケーションが正常に行われる場合にのみ、応答がクライアントに返され、スレッドがリリースされます。同期レプリケーションはクラスターの各ノードからの応答を必要とするため、ネットワークトラフィックに影響を与えます。ただし、クラスターのすべてのノードへ確実に変更が加えられる利点があります。

非同期レプリケーションはバックグラウンドで実行されます。Infinispan はレプリケーションを実行するバックグラウンドスレッドによって使用されるレプリケーションキューを実装します。レプリケーションは時間ベースまたはキューのサイズのいずれかでトリガーされます。レプリケーションキューは、クラスターノード間の対話が行われないため、パフォーマンスを向上させることができます。非同期レプリケーションとのトレードオフは、非常に正確ではないことです。失敗したレプリケーションはログに書き込まれ、リアルタイムで通知されません。

13.3. キャッシュコンテナー

キャッシュコンテナー
キャッシュコンテナーはサブシステムによって使用されるキャッシュのリポジトリーです。Infinispan のデフォルトのキャッシュコンテナーは設定 xml ファイル(standalone-ha.xml、standalone-full-ha.xml、domain.xml)で定義されます。1 つのキャッシュがデフォルトのキャッシュとして定義されます。これは、クラスタリングに使用されるキャッシュです。

例13.1 standalone-ha.xml 設定ファイルのキャッシュコンテナ定義

<subsystem xmlns="urn:jboss:domain:infinispan:1.5">
       <cache-container name="singleton" aliases="cluster ha-partition" default-cache="default">
          <transport lock-timeout="60000"/>
          <replicated-cache name="default" mode="SYNC" batching="true">
             <locking isolation="REPEATABLE_READ"/>
          </replicated-cache>
       </cache-container>
       <cache-container name="web" aliases="standard-session-cache" default-cache="repl" module="org.jboss.as.clustering.web.infinispan">
        <transport lock-timeout="60000"/>
        <replicated-cache name="repl" mode="ASYNC" batching="true">
          <file-store/>
        </replicated-cache>
        <replicated-cache name="sso" mode="SYNC" batching="true"/>
          <distributed-cache name="dist" l1-lifespan="0" mode="ASYNC" batching="true">
           <file-store/>
          </distributed-cache>
        </cache-container>
Copy to Clipboard Toggle word wrap
各キャッシュコンテナーで定義されたデフォルトのキャッシュに注目してください。この例では、Web キャッシュコンテナーで repl キャッシュがデフォルトとして定義されます。そのため、Web セッションのクラスタリングでは repl キャッシュが使用されます。
キャッシュコンテナとキャッシュ属性は、管理コンソールまたは CLI コマンドを使用して設定できますが、キャッシュコンテナまたはキャッシュの名前を変更することは推奨されません。
キャッシュコンテナーの設定
Infinispan のキャッシュコンテナは CLI または管理コンソールを使用して設定できます。

手順13.1 管理コンソールでの Infinispan キャッシュコンテナの設定

  1. 画面上部の Configuration タブを選択します。
  2. ドメインモードの場合は、左上のドロップダウンメニューから ha または full-ha のいずれかを選択します。
  3. Subsystems メニューを展開し、Infinispan メニューを展開します。Cache Containers を選択します。
  4. Cache Containers テーブルからキャッシュコンテナーを選択します。
  5. デフォルトのキャッシュコンテナの追加、削除、および設定

    1. 新しいキャッシュコンテナーを作成するには、Cache Containers テーブルから Add をクリックします。
    2. キャッシュコンテナーを削除するには、Cache Containers 表のキャッシュコンテナーを選択します。削除 をクリックし、OK をクリックして確定します。
    3. キャッシュコンテナーをデフォルトとして設定するには、Set Default をクリックし、ドロップダウンリストからキャッシュコンテナー名を入力し、Save をクリックして確定します。
  6. キャッシュコンテナーの属性を追加または更新するには、キャッシュコンテナー の表にあるキャッシュコンテナーを選択 ます。画面の Details エリアの AttributesTransport、および Aliases タブから 1 つを選択し、Edit をクリックします。AttributesTransport、および Aliases タブの内容のヘルプは、Need Help? をクリックします。

手順13.2 管理 CLI での Infinispan キャッシュコンテナの設定

  1. 設定可能な属性のリストを取得するには、以下の CLI コマンドを入力します。
    /profile=profile name/subsystem=infinispan/cache-container=container name:read-resource
    Copy to Clipboard Toggle word wrap
  2. 管理 CLI を使用してキャッシュコンテナーを追加、削除、および更新できます。キャッシュコンテナーで使用するコマンドを実行する前に、管理 CLI コマンドで正しいプロファイルを使用するようにしてください。
    1. キャッシュコンテナの追加

      キャッシュコンテナを追加するには、以下の例に従ってコマンドを入力します。
      /profile=profile-name/subsystem=infinispan/cache-container="cache container name":add
      Copy to Clipboard Toggle word wrap
    2. キャッシュコンテナの削除

      キャッシュコンテナを削除するには、以下の例に従ってコマンドを入力します。
      /profile=profile-name/subsystem=infinispan/cache-container="cache container name":remove
      Copy to Clipboard Toggle word wrap
    3. キャッシュコンテナ属性の更新

      write-attribute 操作を使用して、新しい値を属性に書き込みます。タブ補完を使用すると、入力時のコマンド文字列の補完に役立つほか、利用可能な属性を明らかにできます。以下の例は、statistics-enabled を true に更新します。
      /profile=profile name/subsystem=infinispan/cache-container=cache container name:write-attribute(name=statistics-enabled,value=true)
      Copy to Clipboard Toggle word wrap

13.4. Infinispan の統計

監視目的で、Infinispan キャッシュおよびキャッシュコンテナーオブジェクトに関するランタイム統計を有効にできます。パフォーマンス上の理由で、統計の収集はデフォルトでは無効になっています。
警告
Infinispan の統計を有効にすると、Infinispan サブシステムのパフォーマンスに影響を及ぼす可能性があります。統計は必要な場合のみ有効にしてください。
統計収集は、各キャッシュコンテナー、キャッシュ、またはその両方に対して有効にできます。各キャッシュの統計オプションは cache-container のオプションを上書きします。キャッシュコンテナーの統計収集を無効または有効にすると、独自の設定が明示的に指定されている場合以外はそのコンテナーのすべてのキャッシュが設定を継承します。cache-container のみが統計に対して有効になっている場合、有用な統計を使用できます。

13.5. Infinispan 統計収集の有効化

統計収集は、起動設定ファイル( standalone.xmlstandalone-ha.xmldomain.xmlなど)または管理 CLI から有効にできます。

13.5.1. 起動設定ファイルでの Infinispan 統計収集の有効化

手順13.3 起動設定ファイルでの Infinispan 統計の有効化

  • 属性 statistics-enabled=VALUE を Infinispan サブシステム下の必要な cache-container または cache XML タグに追加します。

例13.2 キャッシュの統計収集の有効化

<replicated-cache name="sso" mode="SYNC" batching="true" statistics-enabled="true"/>

Copy to Clipboard Toggle word wrap

例13.3 キャッシュコンテナーの統計収集の有効化

<cache-container name="singleton" aliases="cluster ha-partition" default-cache="default" statistics-enabled="true">

Copy to Clipboard Toggle word wrap

13.5.2. 管理 CLI での Infinispan 統計収集の有効化

手順13.4 管理 CLI での Infinispan 統計収集の有効化

以下の手順では、
  • CACHE_CONTAINER が推奨される キャッシュコンテナー (例: web)です。
  • CACHE_TYPE が推奨されるキャッシュタイプです(例: distributed-cache)。
  • CACHE はキャッシュ名です(例: dist)。
  1. 以下のコマンドを入力します。

    例13.4 キャッシュの統計収集の有効化

    /subsystem=infinispan/cache-container=CACHE_CONTAINER/CACHE_TYPE=CACHE:write-attribute(name=statistics-enabled,value=true)
    Copy to Clipboard Toggle word wrap

    例13.5 キャッシュコンテナーの統計収集の有効化

    /subsystem=infinispan/cache-container=CACHE_CONTAINER:write-attribute(name=statistics-enabled,value=true)
    Copy to Clipboard Toggle word wrap
  2. 以下のコマンドを実行し、サーバーをリロードします。
    reload
    Copy to Clipboard Toggle word wrap
注記
属性を未定義にするには、以下のコマンドを実行します。
/subsystem=infinispan/cache-container=CACHE_CONTAINER/CACHE_TYPE=CACHE:undefine-attribute(name=statistics-enabled)
Copy to Clipboard Toggle word wrap
/subsystem=infinispan/cache-container=CACHE_CONTAINER:undefine-attribute(name=statistics-enabled)
Copy to Clipboard Toggle word wrap

13.5.3. Infinispan 統計収集の有効化を検証

手順13.5 Infinispan 統計収集の有効化を検証

統計収集がキャッシュまたは キャッシュ コンテナー で有効になっているかどうかを確認するかどうかに応じて、以下の管理 CLI コマンドのいずれかを使用します。
    • キャッシュの場合

      /subsystem=infinispan/cache-container=CACHE_CONTAINER/CACHE_TYPE=CACHE:read-attribute(name=statistics-enabled)
      Copy to Clipboard Toggle word wrap
    • キャッシュコンテナーの場合

      /subsystem=infinispan/cache-container=CACHE_CONTAINER:read-attribute(name=statistics-enabled)
      Copy to Clipboard Toggle word wrap

13.6. Web セッションレプリケーションの分散キャッシュモードへの切り替え

Infinispan サブシステムの web キャッシュコンテナを dist から repl に変更します。owners 属性は、セッションデータを保持するクラスターノードの数を定義します。その 1 つはプライマリー所有者と呼ばれ、もう 1 つはバックアップ所有者です。
キャッシュモードを dist プロファイルが使用されていると仮定して、3 つの所有者でキャッシュモードを更新する CLI コマンドは次のとおりです。ha
/subsystem=infinispan/cache-container=web/:write-attribute(name=default-cache,value=dist)
/subsystem=infinispan/cache-container=web/distributed-cache=dist/:write-attribute(name=owners,value=3)
Copy to Clipboard Toggle word wrap
上記の CLI を実行すると、以下の出力が表示されます。
<cache-container name="web" aliases="standard-session-cache" default-cache="dist" module="org.jboss.as.clustering.web.infinispan">
  	<transport lock-timeout="60000"/>
  	...
  	<distributed-cache name="dist" owners="3" l1-lifespan="0" mode="ASYNC" batching="true">
  		<file-store/>
  	</distributed-cache>
</cache-container>
Copy to Clipboard Toggle word wrap

13.7. JGroups

13.7.1. JGroups

JGroups は、システムの信頼性に問題がある場合に開発者が信頼できるメッセージングアプリケーションを作成できるメッセージングツールキットです。JGroups を使用すると、ノードがお互いにメッセージを送信できるクラスターを作成できます。
JGroups サブシステムは、クラスター内のサーバーが相互に対話するためのすべての通信メカニズムを提供します。EAP には 2 つの JGroups スタックが事前設定されています。
  • udp - クラスターのノードは UDP(User Datagram Protocol)マルチキャストを使用してお互いに通信します。通常、UDP は TCP よりも高速ですが、信頼性は低くなります。
  • tcp - クラスターのノードは TCP(Transmission Control Protocol)を使用してお互いに通信します。TCP は UDP よりも遅い傾向がありますが、データを宛先に確実に配信します。
事前定義されたスタックを使用できますが、システムの特定要件に見合うよう独自に定義することもできます。

13.8. JGroups トラブルシューティング

13.8.1. ノードがクラスターを形成しない

マシンで IP マルチキャストが正しくセットアップされていることを確認します。McastReceiverTest と McastSenderTest の検出に使用できるテストプログラムは 2 つあります。以下に例を示します。
java -cp EAP_HOME/bin/client/jboss-client.jar org.jgroups.tests.McastReceiverTest -mcast_addr 230.11.11.11 -port 5555 -bind_addr YOUR_BIND_ADDRESS
Copy to Clipboard Toggle word wrap
次に、別のウィンドウで McastSenderTest を開始します。
java -cp EAP_HOME/bin/client/jboss-client.jar org.jgroups.tests.McastSenderTest -mcast_addr 230.11.11.11 -port 5555 -bind_addr YOUR_BIND_ADDRESS
Copy to Clipboard Toggle word wrap
特定のネットワークインターフェースカード(NIC)にバインドする場合は、-bind_addr 192.168.0.2 を使用します。192.168.0.2 は、バインドする NIC の IP アドレスに置き換えます。送信側と受信側の両方にこのパラメーターを使用します。
McastSenderTest ウィンドウに入力でき、McastReceiverTest ウィンドウで出力を確認できるはずです。そうでない場合は、送信者で -ttl 32 を使用します。それでも失敗する場合は、システム管理者を参照して、IP マルチキャストを正しく設定できるように管理者に連絡し、選択したインターフェースでマルチキャストが機能するか、またはマシンに複数のインターフェースがある場合は、正しいインターフェースを要求するように管理者に依頼してください。クラスターの各マシンでマルチキャストが適切に動作したら、送信側と受信側を別々のマシンに配置し、テストを繰り返します。

13.8.2. FD にハートビートが欠落する原因

ハートビートが一定時間 T(timeout および max_tries によって定義)を受け取っていないため、FD がメンバーに疑われる場合もあります。これには、A、B、C、D のクラスターなど、複数の理由が考えられます(A に B、B が C、C が D および D に ping される可能性があることに注意してください)。
  • B または C が CPU の 100% で稼働している(T 秒以上)。そのため、C がハートビート認証を B に送信しても、B が 100% であるため処理できない場合があります。
  • B または C は、上記と同様にガベッジコレクションです。
  • 上記の 2 つのケースの組み合わせ
  • ネットワークによるパケットの損失が発生する場合。これは通常、ネットワーク上に大量のトラフィックがあり、スイッチがパケットドロップを開始します(通常は最初にブロードキャスト、次に IP マルチキャスト、TCP パケットが最後にブロードキャストされます)。
  • B または C がコールバックを処理する場合。C がチャンネル上でリモートメソッド呼び出しを受信し、T+1 秒かかるとします。この間、C はハートビートなどの他のメッセージを処理しません。そのため、B はハートビート認証を受け取らず、C は疑われます。

第14章 JVM

14.1. JVM

14.1.1. JVM 設定

Java Virtual Machine(JVM)設定の設定は、管理対象ドメインとスタンドアロンサーバーインスタンスによって異なります。管理対象ドメインでは、JVM 設定は host.xml および domain.xml 設定ファイルで宣言され、サーバープロセスを起動および停止するドメインコントローラーコンポーネントによって決定されます。スタンドアロンサーバーインスタンスでは、起動時にサーバーの起動プロセスがコマンドライン設定を渡すことができます。これらはコマンドラインまたは管理コンソールの システムプロパティー画面を 使用して宣言できます。
注記
JAVA_OPTS で設定されていないシステムプロパティーは、起動時に JBoss モジュールによって使用されるプロパティーには使用できません。また、java.util.logging.manager などの他の JVM プロパティーには使用できません。

管理対象ドメイン

管理対象ドメインの重要な機能は、複数のレベルで JVM 設定を定義する機能です。カスタム JVM 設定は、ホストレベル、サーバーグループ、またはサーバーインスタンスにより設定できます。より特殊な子要素は親設定を上書きし、グループまたはホストレベルで除外せずに特定のサーバー設定を宣言できます。これにより、設定が設定ファイルで宣言されるか、実行時に渡されるまで、親設定を他のレベルで継承できます。

例14.1 ドメイン設定ファイルの JVM 設定

以下の例は、domain.xml 設定ファイルのサーバーグループに対する JVM 宣言を示しています。
<server-groups>
       <server-group name="main-server-group" profile="default">
           <jvm name="default">
               <heap size="64m" max-size="512m"/>
           </jvm>
           <socket-binding-group ref="standard-sockets"/>
       </server-group>
       <server-group name="other-server-group" profile="default">
           <jvm name="default">
               <heap size="64m" max-size="512m"/>
           </jvm>
           <socket-binding-group ref="standard-sockets"/>
       </server-group>
</server-groups>
Copy to Clipboard Toggle word wrap
このインスタンスでは、main-server-group という名前のサーバーグループが 64 メガバイトのヒープサイズと最大ヒープサイズ 512 メガバイトを宣言します。このグループに属するサーバーは、この設定を継承します。グループ全体、ホスト、または個々のサーバーの設定を変更できます。

例14.2 ホスト設定ファイルのドメイン設定

以下の例は、host.xml 設定ファイルのサーバーグループの JVM 宣言を示しています。
<servers>
  <server name="server-one" group="main-server-group" auto-start="true">
    <jvm name="default"/>
  </server>
  <server name="server-two" group="main-server-group" auto-start="true">
    <jvm name="default">
      <heap size="64m" max-size="256m"/>
    </jvm>
    <socket-bindings port-offset="150"/>
  </server>
  <server name="server-three" group="other-server-group" auto-start="false">
    <socket-bindings port-offset="250"/>
  </server>
</servers>
Copy to Clipboard Toggle word wrap
この場合、server-two という名前のサーバーは main-server-group という名前のサーバーグループに属し、default JVM グループから JVM 設定を継承します。上記の例では、main-server-group のメインヒープサイズは 512 メガバイトに設定されています。最大ヒープサイズ 256 メガバイトを宣言すると、server-twodomain.xml 設定を上書きし、必要に応じてパフォーマンスを微調整できます。

実行時のスタンドアロンサーバー設定

スタンドアロンサーバーインスタンスの JVM 設定は、サーバーを起動する前に JAVA_OPTS 環境変数を設定することでランタイム時に宣言できます。Linux コマンドラインで JAVA_OPTS 環境変数を設定する例は次のとおりです。

[user@host bin]$ export JAVA_OPTS="-Xmx1024M"
Copy to Clipboard Toggle word wrap
次のように、同じ設定を Microsoft Windows 環境で使用できます。
C:\> set JAVA_OPTS="Xmx1024M"
Copy to Clipboard Toggle word wrap
または、JVM に渡すオプションの例が含まれる EAP_HOME/bin フォルダーにある standalone.conf ファイルに JVM 設定を追加することもできます。
警告
JAVA_OPTS 環境変数を設定すると、JAVA_OPTS 環境変数のデフォルト値が再定義されます。これにより、JBoss EAP の起動が中断または中断される可能性があります。

14.1.2. 管理コンソールでの JVM 状態の表示

スタンドアロンサーバーまたは管理対象ドメインの管理コンソールに Java 仮想マシン(JVM)ステータスを表示できます。コンソールは、サーバーのヒープ使用量、非ヒープ使用、およびスレッドの使用状況を表示します。統計はリアルタイムでは表示されませんが、コンソール表示を更新して JVM リソースの最新の概要を提供できます。
JVM の状態には次の値が表示されます。
Expand
表14.1 JVM 状態属性
タイプ 説明
Max メモリー管理に使用できるメモリーの最大量。最大エバラブメモリーは、軽量グレイのバーで表示されます。
Used 使用されたメモリーの量。使用中のメモリー容量は、ダクグレーのバーで表示されます。
Committed Java 仮想マシンが使用するために確保されるメモリー量。コミットされたメモリーは dark grey バーで表示されます。

手順14.1 管理コンソールでの JVM 状態の表示

    • スタンドアロンサーバーインスタンスの JVM 状態 の表示

      画面の上部にある Runtime タブを選択します。Status メニューを展開し、Platform メニューを展開します。JVM を選択します。
    • 管理対象ドメインの JVM 状態の表示

      画面の上部にある Runtime タブを選択します。Server Status メニューを展開し、Platform メニューを展開します。JVM を選択します。
  1. 管理対象ドメインはサーバーグループのすべてのサーバーインスタンスを表示できますが、サーバーメニューから選択すると一度に 1 つのサーバーのみを表示できます。サーバーグループ内の他のサーバーの状態を表示するには、画面の左側にある Server の変更 をクリックして、グループに表示されるホストおよびサーバーから選択します。必要なサーバーまたはホストを選択し、JVM の詳細が変更されます。Close をクリックして終了します。

結果

サーバーインスタンスに対する JVM 設定の状態が表示されます。

14.1.3. JVM の設定

<jvm></jvm> タグは、<option value="VALUE"/> タグを使用して JVM 設定にパラメーターを追加するために使用できる <jvm-options></jvm-options> の使用をサポートします。

例14.3 <jvm-options> の使用

<jvm name="default">
  <heap size="1303m" max-size="1303m"/>
  <permgen max-size="256m"/>
  <jvm-options>
    <option value="-XX:+UseCompressedOops"/>
  </jvm-options>
</jvm>
Copy to Clipboard Toggle word wrap

CLI を使用した JVM の設定

CLI を使用して JVM を設定するには、以下の構文を使用します。

# cd /server-group=main-server-group/jvm=default

# :add-jvm-option(jvm-option="-XX:+UseCompressedOops")
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => {"main-server-group" => {"host" => {"master" => {
        "server-one" => {"response" => {
            "outcome" => "success",
            "response-headers" => {
                "operation-requires-restart" => true,
                "process-state" => "restart-required"
            }
        }},
        "server-two" => {"response" => {
            "outcome" => "success",
            "response-headers" => {
                "operation-requires-restart" => true,
                "process-state" => "restart-required"
            }
        }}
    }}}}
}

# :read-resource

# Expected Result:

[domain@localhost:9999 jvm=default] :read-resource                                      
  {
    "outcome" => "success",
    "result" => {
    "agent-lib" => undefined,
    "agent-path" => undefined,
    "env-classpath-ignored" => undefined,
    "environment-variables" => undefined,
    "heap-size" => "1303m",
    "java-agent" => undefined,
    "java-home" => undefined,
    "jvm-options" => ["-XX:+UseCompressedOops"],
    "max-heap-size" => "1303m",
    "max-permgen-size" => "256m",
    "permgen-size" => undefined,
    "stack-size" => undefined,
    "type" => undefined
  }
}
Copy to Clipboard Toggle word wrap

jvm-options エントリーの削除

jvm-options エントリーを削除するには、次の構文を使用します。

# cd /server-group=main-server-group/jvm=default

# :remove-jvm-option(jvm-option="-XX:+UseCompressedOops")

# Expected Result:

[domain@localhost:9999 jvm=default] :remove-jvm-option(jvm-option="-XX:+UseCompressedOops")
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => {"main-server-group" => {"host" => {"master" => {
        "server-one" => {"response" => {
            "outcome" => "success",
            "response-headers" => {
                "operation-requires-restart" => true,
                "process-state" => "restart-required"
            }
        }},
        "server-two" => {"response" => {
            "outcome" => "success",
            "response-headers" => {
                "operation-requires-restart" => true,
                "process-state" => "restart-required"
            }
        }}
    }}}}
}
Copy to Clipboard Toggle word wrap

32 ビットまたは 64 ビットアーキテクチャーの指定

Hewlett-Packard HP-UX および Solaris などの一部の環境では、32 ビットまたは 64 ビット JVM で実行されるかどうかを指定するために -d32 または -d64 スイッチが使用されます。指定がない場合はデフォルトで 32 ビットが使用されます。

手順14.2 スタンドアロンサーバーでの 64 ビットアーキテクチャーの指定

  1. EAP_HOME/bin/standalone.conf ファイルを開きます。
  2. 以下の行を追加して、-d64 オプションを JAVA_OPTS に追加します。
    JAVA_OPTS="$JAVA_OPTS -d64"
    Copy to Clipboard Toggle word wrap

手順14.3 管理対象ドメインでの 64 ビットアーキテクチャーの指定

管理対象ドメインで実行している場合は、サーバーインスタンスの他にホストとプロセスコントローラーの 64 ビット環境を指定できます。
  1. 64 ビット JVM で実行するよう、ホストおよびプロセスコントローラーを設定します。
    1. EAP_HOME/bin/domain.conf ファイルを開きます。
    2. 以下の行を追加して、-d64 オプションを JAVA_OPTS に追加します。PROCESS_CONTROLLER_JAVA_OPTS および HOST_CONTROLLER_JAVA_OPTS が設定される前に挿入されていることを確認します。
      JAVA_OPTS="$JAVA_OPTS -d64"
      Copy to Clipboard Toggle word wrap

      例14.4 domain.confの JVM オプション

      #  
      # Specify options to pass to the Java VM.  
      #  
      if [ "x$JAVA_OPTS" = "x" ]; then  
        JAVA_OPTS="-Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true"  
        JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true"  
        JAVA_OPTS="$JAVA_OPTS -Djboss.modules.policy-permissions=true"  
        JAVA_OPTS="$JAVA_OPTS -d64"  
      else  
        echo "JAVA_OPTS already set in environment; overriding default settings with values: $JAVA_OPTS"  
      fi
      Copy to Clipboard Toggle word wrap
  2. 64 ビット JVM で実行するよう、サーバーインスタンスを設定します。
    1. 適切な host.xml 設定ファイルに -d64 を JVM オプションとして追加します。

      例14.5 host.xmlの JVM オプション

      <jvms>  
        <jvm name="default">  
          <heap size="64m" max-size="256m"/>  
          <permgen size="256m" max-size="256m"/>  
          <jvm-options>  
            <option value="-server"/>  
            <option value="-d64"/>  
          </jvm-options>  
        </jvm>  
      </jvms>
      Copy to Clipboard Toggle word wrap
      注記
      管理 CLI では以下のコマンドで、適切なホストに -d64 オプションを追加できます。
      /host=HOST_NAME/jvm=default:add-jvm-option(jvm-option="-d64")
      Copy to Clipboard Toggle word wrap

14.1.4. Java Security Manager について

Java Security Manager は、Java Virtual Machine (JVM) サンドボックスの外部境界を管理するクラスで、JVM 内で実行されるコードが JVM 外のリソースと対話する方法を制御します。Java Security Manager を有効にすると、Java API はさまざまな潜在的に危険な操作を実行する前に、セキュリティーマネージャーで承認を確認します。Java Security Manager はセキュリティーポリシーを使用して、特定のアクションが許可または拒否されるかどうかを判断します。

14.1.5. Java セキュリティーポリシー

Java Security ポリシーは、さまざまなクラスのコードに対する定義されたパーミッションのセットです。Java Security Manager は、アプリケーションによって要求されたアクションをセキュリティーポリシーと比較します。ポリシーがアクションを許可した場合、Security Manager はそのアクションの実行を許可します。ポリシーによりアクションが許可されない場合、セキュリティーマネージャーはそのアクションを拒否します。セキュリティーポリシーは、コードの場所、コードの署名、またはサブジェクトのプリンシパルに基づいてパーミッションを定義できます。
セキュリティーポリシー付与エントリーは、以下の設定要素で構成されます。
CodeBase
コードの起点となる URL の場所(ホストとドメイン情報を除く)。このパラメーターは任意です。
SignedBy
コードの署名に秘密鍵が使用された署名者を参照するキーストアで使用されるエイリアス。これは、単一の値またはコンマ区切りの値のリストになります。このパラメーターは任意です。省略した場合には、署名の有無に関わらず、Java Security Manager には影響がありません。
Principal
実行中のスレッドのプリンシパルセットに存在する必要がある principal_type/principal_name ペアの一覧。Principals エントリーは任意です。これを省略すると、実行中のスレッドのプリンシパルが Java Security Manager には影響しません。
Permissions
パーミッションは、コードに付与されるアクセスです。多くのパーミッションは、Java Enterprise Edition 6(Java EE 6)仕様の一部として提供されます。

14.1.6. Java セキュリティーポリシーの作成

ほとんどの JDK および JRE ディストリビューションに policytool と呼ばれるアプリケーションが含まれており、Java セキュリティーポリシーを作成および編集することを目的としています。policytool に関する詳細情報は、にリンクされてい http://docs.oracle.com/javase/6/docs/technotes/tools/ ます。テキストエディターを使用してセキュリティーポリシーを作成することもできます。

手順14.4 新しい Java Security Manager ポリシーの設定

  1. policytool を起動します。

    policytool ツールを以下のいずれかの方法で起動します。
    • Red Hat Enterprise Linux

      GUI またはコマンドプロンプトで、/usr/bin/policytool を実行します。
    • Microsoft Windows Server

      Start メニューまたは Java インストールの bin\ から policytool.exe を実行します。ロケーションは異なる場合があります。
  2. ポリシーを作成します。

    ポリシーを作成するには、Add Policy Entry を選択します。必要なパラメーターを追加してから、完了 をクリック ます。
    注記
    VFS を使用して、JBoss EAP にデプロイされたアプリケーションのパスを指定します。Linux では、パスは vfs:/content/application.war になります。Microsoft Windows では、vfs:/${user.dir}/content/application.war です。
    以下に例を示します。
    grant codeBase "vfs:/content/application.war/-" {
    permission java.util.PropertyPermission "*", "read";
    };
    
    Copy to Clipboard Toggle word wrap
  3. 既存のポリシーを編集します。

    既存のポリシーの一覧からポリシーを選択し、Edit Policy Entry ボタンを選択します。必要に応じてパラメーターを編集します。
  4. 既存のポリシーを削除します。

    既存のポリシーの一覧からポリシーを選択し、Remove Policy Entry ボタンを選択します。

14.1.7. Java Security Manager 内での JBoss EAP 6 の実行

JBoss EAP 6.4 以降、Java Security Manager(JSM)内で JBoss EAP 6 を実行すると、secmgr オプションを使用します。
重要
-Djava.security.manager Java システムプロパティーの直接使用ができなくなりました。以前の JBoss EAP 6 で Java Security Manager を有効にするために使用されていたこの方法は、JBoss EAP 起動スクリプトのフォールバックメカニズムとしてのみサポートされています。
注記
JBoss EAP 6.4 以降では、カスタムセキュリティーマネージャーは使用できません。
以下の手順では、指定のセキュリティーポリシーを使用して Java Security Manager 内で実行するように JBoss EAP 6 インスタンスを設定する手順を説明します。

前提条件

  • この手順を実行する前に、Java Development Kit(JDK)または Java SE Runtime Environment(JRE)に含まれる policytool アプリケーションを使用してセキュリティーポリシーを記述する必要があります。テキストエディターを使用してセキュリティーポリシーを作成することもできます。
    パーミッションが必要なユーザーデプロイメントには、セキュリティーポリシーが必要です。この手順では、ポリシーが EAP_HOME/bin/server.policy にあることを前提としています。
  • 設定ファイルを編集する前に、ドメインまたはスタンドアロンサーバーを完全に停止する必要があります。
管理対象ドメインで JBoss EAP 6 を使用している場合は、ドメインの各物理ホストまたはインスタンスで以下の手順を実行する必要があります。

手順14.5 JBoss EAP 6 の Java Security Manager の設定

  1. 設定ファイルを開く

    設定ファイルを開いて編集します。編集が必要な設定ファイルは、管理対象ドメインまたはスタンドアロンサーバーとオペレーティングシステムのどちらを使用するかによって異なります。
    • 管理対象ドメイン

      • For Linux: EAP_HOME/bin/domain.conf
      • Windows の場合: EAP_HOME\bin\domain.conf.bat
    • スタンドアロンサーバー

      • For Linux: EAP_HOME/bin/standalone.conf
      • Windows の場合: EAP_HOME\bin\standalone.conf.bat
  2. Java Security Manager の有効化

    以下のいずれかの方法を使用して Java Security Manager を有効にします。
    • JBoss EAP 6 のサーバー起動スクリプトで -secmgr オプションを使用します。
    • 設定ファイルの secmgr="true" 行のコメントを解除します。
      • Linux の場合:

        # Uncomment this to run with a security manager enabled
        SECMGR="true"
        Copy to Clipboard Toggle word wrap
      • Windows の場合:

        rem # Uncomment this to run with a security manager enabled
        set "SECMGR=true"
        Copy to Clipboard Toggle word wrap
  3. Java セキュリティーポリシーの指定

    -Djava.security.policy を使用して、セキュリティーポリシーの場所を指定できます。これは、改行なしで 1 行のみに置く必要があります。-Djava.security.policy を設定する場合は == を使用すると、セキュリティーマネージャーは指定されたポリシーファイル のみ を使用するように指定します。= を使用すると、セキュリティーマネージャーは JAVA_HOME/jre/lib/security/java.securitypolicy.url セクションに設定されたポリシー と組み合わせ て指定されたポリシーを使用するように指定します。
    関連する JBoss EAP 6 設定ファイルでセキュリティーポリシー Java オプションを追加します。管理対象ドメインを使用している場合は、PROCESS_CONTROLLER_JAVA_OPTS および HOST_CONTROLLER_JAVA_OPTS が設定される前に挿入されていることを確認します。
    • Linux の場合:

      JAVA_OPTS="$JAVA_OPTS -Djava.security.policy==EAP_HOME/bin/server.policy -Djboss.home.dir=EAP_HOME"
      Copy to Clipboard Toggle word wrap
    • Windows の場合:

      set "JAVA_OPTS=%JAVA_OPTS% -Djava.security.policy==EAP_HOME\bin\server.policy -Djboss.home.dir=EAP_HOME"
      Copy to Clipboard Toggle word wrap
  4. ドメインまたはサーバーの起動

    ドメインまたはサーバーを通常どおり起動します。

14.1.8. IBM JDK および Java Security Manager

IBM JDK のバージョンによっては、JBoss EAP セキュリティーポリシーと適切に動作しないデフォルトのポリシープロバイダーを使用します。IBM JDK を使用して Java Security Manager を有効にして JBoss EAP をホストする際に問題が発生した場合は、JRE 設定を変更して標準のポリシープロバイダーを使用する必要があります。
IBM JDK の JRE 設定を変更するには、JAVA_HOME/jre/lib/security/java.security ファイルを編集し、policy.provider の値を sun.security.provider.PolicyFile に設定します。
policy.provider=sun.security.provider.PolicyFile
Copy to Clipboard Toggle word wrap

14.1.9. Security Manager ポリシーのデバッグ

デバッグ情報を有効にして、セキュリティーポリシー関連の問題のトラブルシューティングに役立ちます。java.security.debug オプションは、報告されたセキュリティー関連情報のレベルを設定します。java -Djava.security.debug=help コマンドは、デバッグオプションの全範囲でヘルプ出力を生成します。デバッグレベルを all に設定すると、原因が完全に不明ですが、一般的に使用する場合に、情報が過剰に生成されるセキュリティー関連の障害をトラブルシューティングするのに便利です。適切な一般的なデフォルトは access:failure です。

手順14.6 一般的なデバッグの有効化

  • この手順を実行すると、セキュリティー関連デバッグ情報の一般的な機密レベルを有効にすることができます。

    次の行をサーバー設定ファイルに追加します。
    • JBoss EAP 6 インスタンスが管理対象ドメインで実行されている場合は、Linux の場合は bin/domain.conf ファイル、Windows の場合は bin\domain.conf.bat ファイルに追加されます。
    • JBoss EAP 6 インスタンスがスタンドアロンサーバーとして実行されている場合、行は Linux の場合は bin/standalone.conf ファイル、Windows の場合は bin\standalone.conf.bat ファイルに追加されます。
Linux
JAVA_OPTS="$JAVA_OPTS -Djava.security.debug=access:failure"
Copy to Clipboard Toggle word wrap
Windows
set "JAVA_OPTS=%JAVA_OPTS% -Djava.security.debug=access:failure"
Copy to Clipboard Toggle word wrap

結果

セキュリティー関連デバッグ情報の一般的なレベルが有効になります。

第15章 Web サブシステム

15.1. Web サブシステムの設定

Web サブシステムは管理コンソールまたは管理 CLI を使用して設定できます。
管理コンソールで、画面上部の Configuration タブをクリックして Subsystems メニューを展開し、Web メニューを展開します。Servlet/HTTP メニュー項目をクリックし、JSP、connector、および Virtual Servers 設定も Global を設定します。Web Services メニュー項目をクリックし、Web サービスサブシステムを設定します。
管理 CLI では、すべての Web サブシステムパラメーターは標準のコマンド形式を使用して設定されます。
注記
mod_cluster コンポーネントは、プロファイルが管理対象ドメインで ha または full-ha であるか、または standalone-ha または standalone-full-ha プロファイルでスタンドアロンサーバーを起動する場合にのみ利用できます。mod_cluster 設定の詳細は、mod_cluster サブシステムの設定」 を参照してください。

15.2. HTTP セッションタイムアウトの設定

HTTP セッションタイムアウトは、指定された期間内にアクティビティーがないため、HTTP セッションが無効とみなされる期間を定義します。HTTP セッションタイムアウトを変更するには、影響を受けるすべての JBoss EAP インスタンスを再起動する必要があります。これが完了するまで、元の HTTP セッションタイムアウト値が適用されます。
HTTP セッションタイムアウトは、複数の場所で設定できます。以下に優先順に記載します。
  • application - アプリケーションの web.xml 設定ファイルで定義されます。詳細は、『『開発ガイド』』 『の「アプリケーションごとの HTTP タイムアウトの設定』 」を参照してください。
  • server: default-session-timeout 属性で指定します。この設定は JBoss EAP 6.4 からのみ利用できます。
  • デフォルトは 30 分です。

手順15.1 管理コンソールを使用した HTTP セッションタイムアウトの設定

  1. Configuration タブをクリックし、Subsystems,Web に移動し、Servlet/HTTP メニュー項目をクリックします。
  2. Servlet/HTTP Configuration パネルの Global タブをクリックします。
  3. Edit オプションをクリックします。
  4. Default session timeout の新しい値を入力します。
  5. Save ボタンをクリックします。
  6. JBoss EAP サーバーをリロードします。

手順15.2 管理 CLI を使用した HTTP セッションタイムアウトの設定

注記
管理対象ドメインのコマンドに、プレフィックス /host=HOST_NAME を追加します。
  1. 必要な HTTP セッションタイムアウト値を指定します。
    /subsystem=web:write-attribute(name=default-session-timeout, value=timeout)
    Copy to Clipboard Toggle word wrap
  2. JBoss EAP サーバーをリロードします。
    reload
    Copy to Clipboard Toggle word wrap

15.3. サーブレット/HTTP 設定

手順15.3 サーブレット/HTTP 設定

  1. 管理コンソールで、画面上部の Configuration タブをクリックして Subsystems メニューを展開し、Web メニューを展開します。
  2. Servlet/HTTP メニュー項目をクリックします。
  3. コンポーネントの名前をクリックし、Edit をクリックします。
  4. Advanced ボタンをクリックして高度なオプションを表示します。
以下は、高度なサーブレット/HTTP 設定オプションです。
管理 CLI コマンドがプロファイルに適用される場合は、プレフィックス /profile=PROFILE を追加します。

例15.1 このインスタンスの名前の設定

[domain@localhost:9999 /] /profile=full-ha/subsystem=web:write-attribute(name=instance-id,value=worker1)
Copy to Clipboard Toggle word wrap

グローバル設定オプション

デフォルトのセッションタイムアウト
JBoss EAP 6.4 から利用できます。Web コンテナーのデフォルトセッションタイムアウト。
管理 CLI 属性: default-session-timeout
デフォルトの仮想サーバー
Web コンテナーのデフォルト仮想サーバー。
管理 CLI 属性: default-virtual-server
インスタンス ID
ロードバランシングのシナリオでセッションアフィニティーを有効にするのに使用される ID。識別子はクラスター内のすべての JBoss EAP サーバーで一意である必要があり、生成されたセッション識別子に追加されます。これにより、フロントエンドプロキシーは特定のセッションを同じ JBoss EAP インスタンスに転送できます。インスタンス ID はデフォルトとして設定されていません。
管理 CLI 属性: instance-id
ネイティブ
ネイティブ初期化リスナーを Web コンテナーに追加します。
管理 CLI 属性: ネイティブ値: true または falseデフォルト: true

JSP 設定オプション

チェック間隔
バックグラウンドスレッドを使用して JSP 更新を確認する間隔(秒単位)。デフォルト: 0無効
管理 CLI 属性: check-interval
開発
true の場合、開発モード が有効化されます。これにより、より詳細なデバッグ情報が生成されます。デフォルト: false
管理 CLI 属性: 開発
無効
true の場合は、Java ServerPages(JSP)コンテナーが無効になります。JSP を使用しない場合は便利です。デフォルトは false です。
管理 CLI 属性: 無効
ソースの追加表示
true の場合、ランタイムエラーが発生すると JSP ソースフラグメントが表示されます。デフォルト: true
管理 CLI 属性: display-source-fragment
SMAP のダンプ
true の場合、JSR 045 SMAP データはファイルに書き込まれます。デフォルト: false
管理 CLI 属性: dump-smap
文字列を Char アレイとして生成
true の場合、文字列定数は char 配列として生成されます。デフォルト: false
管理 CLI 属性: generate-strings-as-char-arrays
Bean の無効なクラス属性の使用時のエラー
true の場合、useBean で不適切なクラスが使用される場合にエラーの出力を有効にします。デフォルト: false
管理 CLI 属性: error-on-use-bean-invalid-class-attribute
Java Encoding
Java ソースに使用されるエンコーディングを指定します。デフォルト: UTF8
管理 CLI 属性: java-encoding
生成されているままにする
true の場合、生成されたサーブレットを保持します。デフォルト: true
管理 CLI 属性: keep-generated
マップされたファイル
true の場合、デバッグを容易にするために、入力行ごとに 1 つの印刷ステートメントを使用して静的コンテンツが生成されます。デフォルト: true
管理 CLI 属性: true
変更テスト間隔
更新の 2 つのテストの最小時間(秒単位)。デフォルト: 4
管理 CLI 属性: modification-test-interval
Fail での再コンパイル
true の場合、リクエストごとに失敗した JSP コンパイルが再試行されます。デフォルト: false
管理 CLI 属性: recompile-on-fail
スクラッチディレクトリー
別のワークディレクトリーの場所を指定します。
管理 CLI 属性: scratch-dir
SMAP
true の場合、JSR 045 SMAP が有効になります。デフォルト: true
管理 CLI 属性: smap
ソース仮想マシン
ソースファイルと互換性のある Java Development Kit バージョン。デフォルト: 1.5
管理 CLI 属性: source-vm
タグプール
true の場合、タグプーリングは有効になります。デフォルト: true
管理 CLI 属性: tag-pooling
ターゲット仮想マシン
クラスファイルと互換性のある Java Development Kit バージョン。デフォルト: 1.5
管理 CLI 属性: target-vm
トリミング領域
生成されたサーブレットから一部の領域をトリミングします。デフォルト: false
管理 CLI 属性: trim-spaces
x Powered By
true の場合、JSP エンジンは x-powered-by HTTP ヘッダーを使用してアドバタイズされます。デフォルト: true
管理 CLI 属性: x-powered-by
以下のコマンドのいずれかを使用して、これらのコネクターのいずれかの設定を表示します。
[standalone@localhost:9999 /] /subsystem=web/connector=http:read-resource-description
Copy to Clipboard Toggle word wrap
[standalone@localhost:9999 /] /subsystem=web/connector=ajp:read-resource-description
Copy to Clipboard Toggle word wrap
コネクターを設定するには、Connectors タブを選択し、Add をクリックします。コネクターを削除するには、そのエントリーを選択し、Remove をクリックします。コネクターを編集するには、エントリーを選択し、Edit をクリックします。
管理 CLI を使用して新しいコネクターを作成する場合、以下のコマンドなどでオプションがすべて設定されます。

例15.2 新しいコネクターの作成

[domain@localhost:9999 /] /profile=full-ha/subsystem=web/connector=ajp/:add(socket-binding=ajp,scheme=http,protocol=AJP/1.3,secure=false,name=ajp,max-post-size=2097152,enabled=true,enable-lookups=false,redirect-port=8433,max-save-post-size=4096)
Copy to Clipboard Toggle word wrap

デフォルトのコネクター属性

bytes Sent
コネクターによって送信されるバイト数。
管理 CLI 属性: bytesSent
プロキシーポート
リダイレクトの送信時に使用されるポート。
管理 CLI 属性: proxy-port
Secure
コネクターによって送受信されたコンテンツがユーザーパースペクティブからセキュア化されるかどうかを示します。デフォルト: false
管理 CLI 属性: secure
仮想サーバー
このコネクターからアクセス可能な仮想サーバーの一覧。デフォルト: すべての仮想サーバーを許可します。
管理 CLI 属性: virtual-server
エラー数
コネクターによるリクエストの処理時に発生するエラーの数。
管理 CLI 属性: errorCount
最大時間
要求の処理に費やされた最大時間。
管理 CLI 属性: maxTime
ソケットバインディング
コネクターがバインドされる名前付きソケットバインディング。ソケットバインディングは、ソケット名とネットワークポート間のマッピングです。ソケットバインディングは各スタンドアロンサーバーまたは管理対象ドメインのソケットバインディンググループで設定されます。ソケットバインディンググループはサーバーグループに適用されます。
管理 CLI 属性: socket-binding
Scheme
Web コネクタースキーム(HTTP や HTTPS など)。
管理 CLI 属性: scheme
名前
コネクターの一意の名前。
管理 CLI 属性: name
最大 POST サイズ
コンテナーで解析できる POST リクエストの最大サイズ(バイト単位)。デフォルト: 2097152
管理 CLI 属性: max-post-size
リクエスト数
コネクターによって処理されるリクエストの数。
管理 CLI 属性: requestCount
プロキシー名
リダイレクトの送信時に使用されるホスト名。デフォルト: null
管理 CLI 属性: proxy-name
有効
コネクターが起動時に開始されるかどうかを定義します。デフォルト: true
管理 CLI 属性: enabled
プロトコル
AJP または HTTP のいずれかを使用する Web コネクタープロトコル。それぞれのプロトコルについて API を指定し、使用する実装を判別するためにサーバーに残すか、または完全修飾クラス名を指定できます。
管理 CLI 属性: protocol

HTTP
API オプション: HTTP/1.1 または HTTP/1.0
クライアントが HTTP/1.1 に対応していない場合、コネクターは最初の応答で HTTP/1.1 を返し、HTTP/1.0 にフォールバックします。

完全修飾コネクター名 オプション:

  • jio: org.apache.coyote.http11.Http11Protocol
  • NIO2: org.apache.coyote.http11.Http11NioProtocol
  • APR: org.apache.coyote.http11.Http11AprProtocol
AJP
API オプション: AJP/1.3

完全修飾コネクター名 オプション:

  • jio: org.apache.coyote.ajp.AjpProtocol
  • APR: org.apache.coyote.ajp.AjpAprProtocol
注記
APR では、ネイティブコンポーネントパッケージをインストールして有効にしておく必要があります。詳細な手順は、JBoss EAP 『『インストールガイド』 』を参照してください。
ルックアップの有効化
Servlet API の DNS ルックアップを有効にします。
管理 CLI 属性: enable-lookups
エグゼキューター (Executor)
このコネクターの処理スレッドに使用されるエグゼキューターの名前。定義されていない場合は、デフォルトで内部プールを使用します。
管理 CLI 属性: executor
処理時間
コネクターによって使用される処理時間(ミリ秒単位)。
管理 CLI 属性: processingTime
プロキシーバインディング
リダイレクトの送信時に使用されるホストおよびポートを定義するソケットバインディング。デフォルト: null
管理 CLI 属性: proxy-binding
Redirect Port
セキュアなコネクターへリダイレクトするためのポート。デフォルト: 443
同時に設定されている場合に redirect-binding に遅延します。
管理 CLI 属性: redirect-port
受信バイト数
コネクター(POST データ)によって受信されるバイト数。
管理 CLI 属性: bytesReceived
リダイレクトバインディング
リダイレクトバインディングは動作においてポートをリダイレクトするのと似ていますが、ポート番号の代わりにソケットバインディング名 指定する必要があります。redirect-binding オプションでは、事前定義されたソケットバインディング(https、AJP など)をリダイレクト用に特定のポートに使用できるようにするため、設定の柔軟性が高くなります。redirect-port オプションと同じ結果が提供されます。
同時に設定されている場合は、リダイレクトポート よりも優先されます。
管理 CLI 属性: redirect-binding
最大接続
パフォーマンスを最適化してコネクターが処理できる同時接続の最大数。デフォルト値は、使用されるコネクターによって異なります。
管理 CLI 属性: max-connections
最大保存後サイズ
特定の認証スキーム時に保存される POST リクエストの最大サイズ(バイト単位)。デフォルトは 4096 です。
管理 CLI 属性: max-save-post-size
仮想サーバーを設定するには、Virtual Servers タブをクリックします。Add ボタンを使用して新しい仮想サーバーを追加します。仮想サーバーを編集または削除するには、そのエントリーを選択し、編集 または 削除 ボタンをクリックします。
管理 CLI を使用して新しい仮想サーバーを追加する場合、以下のコマンドのようにすべての必須オプションが一度に設定されます。

例15.3 新しい仮想サーバーの追加

/profile=full-ha/subsystem=web/virtual-server=default-host/:add(enable-welcome-root=true,default-web-module=ROOT.war,alias=["localhost","example.com"],name=default-host)
Copy to Clipboard Toggle word wrap

仮想サーバーオプション

アクセスログ
アクセスログ情報をログに記録する方法を記述する要素。
管理 CLI 属性: access-log
  • access-log 属性を追加するには、以下の管理 CLI コマンドを入力します。
    /subsystem=web/virtual-server=default-host/configuration=access-log:add()
    Copy to Clipboard Toggle word wrap
  • access-log 属性には複数の子属性があります。これらの子とそれらの設定オプションを一覧表示するには、以下の管理 CLI コマンドを入力します。
    /subsystem=web/virtual-server=default-host/configuration=access-log:read-resource-description()
    Copy to Clipboard Toggle word wrap
    pattern
    リクエストおよび応答からのさまざまな情報フィールドを特定するフォーマットレイアウト、または標準形式を選択する common または combined という単語を指定します。pattern 属性の値は、フォーマットトークンで構成されます。指定されない場合は、デフォルトの common が使用されます。
    rotate
    ouput をローテーションする必要がある場合にバルブに指示します。指定されていない場合は、デフォルトの true が使用されます。
    プレフィックス
    ログファイルの名前を作成するために使用されるプレフィックスを定義します。指定されていない場合は、デフォルトの access_log が使用されます。
    拡張
    AccessLogValve の代わりに ExtendedAccessLogValve を使用します。指定されていない場合は、デフォルトの false が使用されます。
    resolve-hosts
    ホスト名を解決するかどうかをバルブに指示します。指定されていない場合は、デフォルトの false が使用されます。resolve-host のコネクターの ルックアップ が有効になっていない限り、このオプションは動作しません。これは、resolve-hosttrue に設定すると有効にできます。
Alias
この仮想サーバーでサポートされるホスト名の一覧。管理コンソールでは、1 行あたり 1 つのホスト名を使用します。
管理 CLI 属性: エイリアス
デフォルトの Web モジュール
Web アプリケーションがこの仮想サーバーのルートノードにデプロイされるモジュールで、HTTP リクエストにディレクトリーが指定されていない場合に表示されます。デフォルト: ROOT.war
管理 CLI 属性: default-web-module
Welcome ルートの有効化
この要素は、バンドルされた welcome ディレクトリーがルート Web コンテキストとして使用されるかどうかを定義します。デフォルト: false
管理 CLI 属性: enable-welcome-root
名前
表示目的の仮想サーバーの一意な名前。
管理 CLI 属性: name
rewrite
リライトバルブが仮想ホストに対応するリクエストと実行する必要があるものを記述する要素。rewrite は、処理前にリクエストが書き換えられる方法を記述します。RewriteValvevirtual-server で定義される仮想ホストに追加します。
flag
RewriteRule は、1 つ以上のフラグでその動作を変更できます。フラグはルールの最後に角括弧に含まれており、複数のフラグはコンマで区切ります。
pattern
pattern は、リクエストの URL に適用される perl と互換性のある正規表現です。
置換
書き換えルールの置き換えは、パターンが一致した元の URL に置換(または置換)される文字列です。
管理 CLI 属性: rewrite
SSO
この仮想サーバーの SSO 設定。デフォルト(http の場合): true
管理 CLI 属性: sso
  • SSO 設定を追加するには、以下の管理 CLI コマンドを入力します。
    /subsystem=web/virtual-server=default-host/configuration=sso:add()
    Copy to Clipboard Toggle word wrap
  • SSO 属性には複数の子属性があります。これらの子とそれらの設定オプションを一覧表示するには、以下の管理 CLI コマンドを入力します。
    /subsystem=web/virtual-server=default-host/configuration=sso:read-resource-description()
    Copy to Clipboard Toggle word wrap
    http-only
    cookie http-only フラグが設定されます。
    cache-container
    指定されたクラスター化されたキャッシュコンテナーを使用してクラスター化された SSO を有効にします。
    reauthenticate
    SSO の使用時にレルムと再認証を有効にします。
    domain
    使用されるクッキードメイン。
    cache-name
    キャッシュコンテナーで使用するキャッシュの名前。

15.4. デフォルトの Welcome Web アプリケーションの置き換え

JBoss EAP 6 には Welcome アプリケーションが含まれており、これはポート 8080 でサーバーの URL を開く際に表示されます。以下の手順に従って、このアプリケーションを独自の Web アプリケーションに置き換えることができます。

手順15.4 デフォルトの Welcome Web アプリケーションを独自の Web アプリケーションに置き換える

  1. Welcome アプリケーションを無効にします。

    管理 CLI スクリプト EAP_HOME/bin/jboss-cli.sh を使用して以下のコマンドを実行します。プロファイルを変更して別の管理対象ドメインプロファイルを変更するか、スタンドアロンサーバーのコマンドの /profile=default 部分を削除しなければならない場合があります。
    /profile=default/subsystem=web/virtual-server=default-host:write-attribute(name=enable-welcome-root,value=false)
    Copy to Clipboard Toggle word wrap
  2. ルートコンテキストを使用するよう Web アプリケーションを設定します。

    ルートコンテキスト(/)を URL アドレスとして使用するように Web アプリケーションを設定するには、META-INF/ または WEB-INF/ ディレクトリーにある jboss-web.xml を変更します。< context-root> ディレクティブを、以下のようなディレクティブに置き換えます。
    <jboss-web>
        <context-root>/</context-root>
    </jboss-web>
    Copy to Clipboard Toggle word wrap
  3. アプリケーションをデプロイします。

    最初の手順で変更したサーバーグループまたはサーバーにアプリケーションをデプロイします。アプリケーションが http://SERVER_URL:PORT/ で利用できるようになりました。

15.5. JBossWeb のシステムプロパティー

ここでは、デフォルトの JBossWeb 動作の変更に使用できるシステムプロパティーを示します。system-properties は JBoss Enterprise Web アプリケーション設定で設定できます。再起動して、Web サブシステムに適用する必要があります。
以下の例は、JBossWeb で system-properties を変更する方法の例になります。
standalone@localhost:9999 /] ./system-property=org.apache.catalina.JSESSIONID:add(value="MYID")
{"outcome" => "success"}
standalone@localhost:9999 /] shutdown
Communication error: Channel closed
Closed connection to localhost:9999
Copy to Clipboard Toggle word wrap
プロパティーによっては、reload コマンドを使用して再起動できます。
以下は、reload コマンドを使用して再起動する例です。
[standalone@localhost:9999 /] reload
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}
Copy to Clipboard Toggle word wrap
Expand
表15.1 サーブレットコンテナーおよびコネクター
属性 説明
jvmRoute
jvmRoute 属性のデフォルト値を提供します。standalone-ha.xml などの設定を使用して ha read を使用する場合に、自動生成された値を上書きしません。
reload をサポートします。
org.apache.tomcat.util.buf.StringCache.byte.enabled true の場合、String キャッシュは ByteChunk に対して有効になります。値の指定がない場合は、デフォルト値の false が使用されます。
org.apache.tomcat.util.buf.StringCache.char.enabled true の場合、String キャッシュは CharChunk に対して有効になります。値の指定がない場合は、デフォルト値の false が使用されます。
org.apache.tomcat.util.buf.StringCache.cacheSize String キャッシュのサイズ。値の指定がない場合は、デフォルト値の 5000 が使用されます。
org.apache.tomcat.util.buf.StringCache.maxStringSize キャッシュされる String の最大長。値の指定がない場合は、デフォルト値の 128 が使用されます。
org.apache.tomcat.util.http.FastHttpDateFormat.CACHE_SIZE 解析およびフォーマットされた日付値を使用するキャッシュのサイズ。値の指定がない場合は、デフォルト値の 1000 が使用されます。
org.apache.catalina.core.StandardService.DELAY_CONNECTOR_STARTUP true の場合、コネクターは自動的に起動されません。これは埋め込みモードで便利です。
org.apache.catalina.connector.Request.SESSION_ID_CHECK true の場合、Servlet コンテナーは、ID でセッションを作成する前に、指定されたセッション ID のコンテキストにセッションが存在することを確認します。
org.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER true の場合、HTTP ヘッダー内でカスタムの HTTP ステータスメッセージが使用されます。XSS の脆弱性を防ぐために、このようなメッセージがメッセージに特に入力されている場合は ISO-8859-1 でエンコードされていることを確認する必要があります。値の指定がない場合は、デフォルト値の false が使用されます。
org.apache.tomcat.util.http.Parameters.MAX_COUNT ポストボディーで解析できるパラメーターの最大量です。この値を超えると、IllegalStateException によって解析に失敗します。デフォルト値は 512 パラメーターです。
org.apache.tomcat.util.http.MimeHeaders.MAX_COUNT
HTTP リクエストで送信できるヘッダーの最大量。この値を超えると、IllegalStateException によって解析に失敗します。デフォルト値は 128 ヘッダーです。
org.apache.tomcat.util.net.MAX_THREADS コネクターがリクエストの処理に使用するスレッドの最大数。デフォルト値は 32 x Runtime.getRuntime().availableProcessors()です。(JIO コネクターの場合は 512 x Runtime.getRuntime().availableProcessors())
org.apache.coyote.http11.Http11Protocol.MAX_HEADER_SIZE HTTP ヘッダーのバイト単位の最大サイズ。この値を超えると、ArrayOutOfBoundsExceptions を使用して解析に失敗します。デフォルト値は 8192 バイトです。
org.apache.coyote.http11.Http11Protocol.COMPRESSION HTTP コネクターでの簡単な圧縮の使用を許可します。デフォルト値は off で、on 値を使用して圧縮を有効にし、条件付きで有効にするか、常に強制的に有効にすることができます。
org.apache.coyote.http11.Http11Protocol.COMPRESSION_RESTRICTED_UA 圧縮されたコンテンツを受け取らないユーザーエージェント regexps。デフォルト値は空です。
org.apache.coyote.http11.Http11Protocol.COMPRESSION_MIME_TYPES 圧縮可能なコンテンツのコンテンツタイプ接頭辞。デフォルト値は text/html,text/xml,text/plain です。
org.apache.coyote.http11.Http11Protocol.COMPRESSION_MIN_SIZE 圧縮されるコンテンツの最小サイズ。デフォルト値は 2048 バイトです。
org.apache.coyote.http11.DEFAULT_CONNECTION_TIMEOUT デフォルトのソケットタイムアウト。デフォルト値は 60000 ミリ秒です。
org.jboss.as.web.deployment.DELETE_WORK_DIR_ONCONTEXTDESTROY このプロパティーを使用して .java および .class ファイルを削除し、JSP ソースが再コンパイルされるようにします。デフォルト値は false です。keep alive のデフォルトのソケットタイムアウト。デフォルト値は -1 ミリ秒で、デフォルトのソケットタイムアウトを使用します。
org.apache.tomcat.util.buf.StringCache.trainThreshold キャッシュをアクティベートする前に toString() を呼び出す必要のある回数を指定します。デフォルト値は 100000 です。
Expand
表15.2 EL
属性 説明
org.apache.el.parser.COERCE_TO_ZERO true の場合、式を数字 "" に変換し、null は仕様で必要なようにゼロに強制されます。値の指定がない場合は、デフォルト値の true が使用されます。
Expand
表15.3 JSP
属性 説明
org.apache.jasper.compiler.Generator.VAR_EXPRESSIONFACTORY 式言語の式ファクトリーに使用される変数の名前。値の指定がない場合は、デフォルト値の _el_expressionfactory が使用されます。
org.apache.jasper.compiler.Generator.VAR_INSTANCEMANAGER インスタンスマネージャーファクトリーに使用する変数の名前。値の指定がない場合は、デフォルト値の _jsp_instancemanager が使用されます。
org.apache.jasper.compiler.Parser.STRICT_QUOTE_ESCAPING false の場合、JSP 属性の引用符をエスケープする要件が緩和され、必要な引用符が欠落しているとエラーが発生しません。値の指定がない場合は、仕様に準拠するデフォルトの true が使用されます。
org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE org.apache.jasper.Constants.DEFAULT_TAG_BUFFER_SIZE を超えるタグバッファーは破棄され、デフォルトサイズの新しいバッファーが作成されます。値の指定がない場合は、デフォルト値の 512 が使用されます。
org.apache.jasper.runtime.JspFactoryImpl.USE_POOL true の場合、ThreadLocal PageContext プールが使用されます。値の指定がない場合は、デフォルト値の true が使用されます。
org.apache.jasper.runtime.JspFactoryImpl.POOL_SIZE ThreadLocal PageContext のサイズ。値の指定がない場合は、デフォルト値の 8 が使用されます。
org.apache.jasper.Constants.JSP_SERVLET_BASE JSP から生成されたサーブレットのベースクラス。値の指定がない場合は、デフォルト値の org.apache.jasper.runtime.HttpJspBase が使用されます。
org.apache.jasper.Constants.SERVICE_METHOD_NAME ベースクラスによって呼び出されるサービスメソッドの名前。値の指定がない場合は、デフォルト値の _jspService が使用されます。
org.apache.jasper.Constants.SERVLET_CLASSPATH JSP のクラスパスを提供する ServletContext 属性の名前。値の指定がない場合は、デフォルト値の org.apache.catalina.jsp_classpath が使用されます。
org.apache.jasper.Constants.JSP_FILE サーブレット定義の <jsp-file> 要素の request 属性の名前。リクエストに存在する場合は、request.getServletPath()によって返される値を上書きし、実行される JSP ページを選択します。値の指定がない場合は、デフォルト値の org.apache.catalina.jsp_file が使用されます。
org.apache.jasper.Constants.PRECOMPILE JSP エンジンがサーブレットを事前生成し、呼び出しは行わないようにするクエリーパラメーターの名前。値の指定がない場合は、デフォルト値の org.apache.catalina.jsp_precompile が使用されます。
org.apache.jasper.Constants.JSP_PACKAGE_NAME コンパイルされた jsp ページのデフォルトのパッケージ名。値の指定がない場合は、デフォルト値の org.apache.jsp が使用されます。
org.apache.jasper.Constants.TAG_FILE_PACKAGE_NAME タグファイルから生成されたタグハンドラーのデフォルトのパッケージ名。値の指定がない場合は、デフォルト値の org.apache.jsp.tag が使用されます。
org.apache.jasper.Constants.TEMP_VARIABLE_NAME_PREFIX 生成された一時的な変数名に使用する接頭辞。値の指定がない場合は、デフォルト値の _jspx_temp が使用されます。
org.apache.jasper.Constants.USE_INSTANCE_MANAGER_FOR_TAGS true の場合、インスタンスマネージャーはタグハンドラーインスタンスの取得に使用されます。値の指定がない場合は true が使用されます。
org.apache.jasper.Constants.INJECT_TAGS true の場合、タグに指定されたアノテーションは処理およびインジェクトされます。簡単なタグを使用する場合やタグプーリングが無効になっている場合はパフォーマンスに影響することがあります。値の指定がない場合は false が使用されます。
Expand
表15.4 セキュリティー
属性 説明
org.apache.catalina.connector.RECYCLE_FACADES true の場合や、セキュリティーマネージャーが使用中の場合は、リクエストごとに新しいファサードオブジェクトが作成されます。値の指定がない場合は、デフォルト値の false が使用されます。
org.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH true の場合、「\」文字はパス区切り文字として使用できます。値の指定がない場合は、デフォルト値の false が使用されます。
org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH true の場合、「%2F」と「%5C」はパス区切り文字として使用できます。値の指定がない場合は、デフォルト値の false が使用されます。
Expand
表15.5 仕様
属性 説明
org.apache.catalina.STRICT_SERVLET_COMPLIANCE
値の指定がない場合は true が使用されます。true の場合、以下のアクションが発生します。
  • アプリケーションディスパッチャーに渡されるラップされた要求または応答オブジェクトは、元の要求または応答がラップされるようにチェックされます。(SRV.8.2 / SRV.14.2.5.1)
  • 文字エンコーディングが指定されていない場合に Response.getWriter()を呼び出すと、後続の Response.getCharacterEncoding()が ISO-8859-1 を返し、Content-Type 応答ヘッダーに charset=ISO-8859-1 コンポーネントが含まれます。(SRV.15.2.22.1)
  • セッションに関連するすべてのリクエストにより、リクエストが明示的にセッションにアクセスしたかどうかに関わらず、セッションの最終アクセス時間が更新されます。(SRV.7.6)
org.apache.catalina.core.StandardWrapperValve.SERVLET_STATS true を指定した場合または org.apache.catalina.STRICT_SERVLET_COMPLIANCE が true の場合、ラッパーは各サーブレットの JSR-77 統計を収集します。値の指定がない場合は、デフォルト値の false が使用されます。
org.apache.catalina.session.StandardSession.ACTIVITY_CHECK true の場合や、org.apache.catalina.STRICT_SERVLET_COMPLIANCE が true の場合、Tomcat は各セッションのアクティブなリクエストの数を追跡します。セッションが有効であるかを判断するとき、アクティブなセッションが 1 つ以上あるセッションは常に有効であると見なされます。値の指定がない場合は、デフォルト値の false が使用されます。

15.6. http のみのセッション管理クッキー

セッション管理クッキーの http-only 属性は、HTTP 以外の API(JavaScript など)からのアクセスを制限することで、セキュリティーの脆弱性のリスクを軽減します。この制限は、クロスサイトスクリプティング攻撃によるセッションクッキーの脅威を軽減するのに役立ちます。クライアント側では、JavaScript またはその他のスクリプトメソッドを使用して Cookie にアクセスできません。これはセッション管理クッキーにのみ適用され、他のブラウザークッキーには適用されません。デフォルトでは、http-only 属性は有効になっています。
まだ行われていない場合は、http-only 属性を使用するには、Web サブシステムの仮想サーバーに SSO を追加する必要があります。

例15.4 仮想サーバーへの SSO の追加

以下の管理 CLI コマンドを入力して、Web サブシステムの仮想サーバーに SSO を追加します。
/subsystem=web/virtual-server=default-host/configuration=sso:add
Copy to Clipboard Toggle word wrap
注記
このコマンドで「JBAS014803: Duplicate resource」が失敗すると、SSO がすでに仮想サーバー設定に追加されていることを意味します。このエラーは無視して、続行することができます。
注記
JSESSIONID および JSESSIONIDSSO はセッション追跡クッキーです。デフォルトでは、http 専用 であるため、スクリプトでアクセスすることはできません。

例15.5 http-only 属性の検証

以下の管理 CLI コマンドを入力して、http-only 属性の値を確認します。
/subsystem=web/virtual-server=default-host/configuration=sso:read-resource
{
    "outcome" => "success",
    "result" => {
        "cache-container" => undefined,
        "cache-name" => undefined,
        "domain" => undefined,
        "http-only" => true,
        "reauthenticate" => undefined
    },
    "response-headers" => {"process-state" => "reload-required"}
}
Copy to Clipboard Toggle word wrap

例15.6 http-only 属性の有効化

以下の管理 CLI コマンドを入力して http-only 属性を有効にします。
/subsystem=web/virtual-server=default-host/configuration=sso:write-attribute(name=http-only,value=true)
Copy to Clipboard Toggle word wrap

第16章 Web サービスサブシステム

16.1. Web サービスオプションの設定

Web サービスオプションは、管理コンソールまたは管理 CLI を使用して設定できます。
管理コンソールで、画面上部の Configuration タブをクリックして Subsystems メニューを展開し、Web メニューを展開します。Web Services メニュー項目をクリックし、Web サービスサブシステムを設定します。オプションは以下の表で説明されています。
Expand
表16.1 Web サービス設定オプション
オプション 説明 CLI コマンド
Modify WSDL Address
WSDL アドレスをアプリケーションで変更できるかどうか。デフォルトは true です。
/profile=full-ha/subsystem=webservices/:write-attribute(name=modify-wsdl-address,value=true)
Copy to Clipboard Toggle word wrap
WSDL Host
JAX-WS Web サービスの WSDL コントラクトには、エンドポイントの場所を示す <soap:address> 要素が含まれます。<soap:address> の値が有効な URL の場合、modify-wsdl-addresstrue に設定されていない限り上書きされません。<soap:address> の値が有効な URL ではない場合、wsdl-host の値と wsdl-port または wsdl-secure-port のいずれかを使用して上書きされます。wsdl-hostjbossws.undefined.host に設定された場合、リクエスターのホストアドレスは <soap-address> の書き換え時に使用されます。デフォルトは ${jboss.bind.address:127.0.0.1} で、JBoss EAP 6 の起動時にバインドアドレスが指定されていない場合は 127.0.0.1 を使用します。
/profile=full-ha/subsystem=webservices/:write-attribute(name=wsdl-host,value=127.0.0.1)
Copy to Clipboard Toggle word wrap
WSDL Port
SOAP アドレスを書き換えるために使用されるセキュアではないポート。これが設定されない場合(デフォルト)、ポートはインストールされたコネクターのリストを問い合わせることにより識別されます。
/profile=full-ha/subsystem=webservices/:write-attribute(name=wsdl-port,value=80)
Copy to Clipboard Toggle word wrap
WSDL Secure Port
SOAP アドレスを書き換えるために使用されるセキュアなポート。これが設定されない場合(デフォルト)、ポートはインストールされたコネクターのリストを問い合わせることにより識別されます。
/profile=full-ha/subsystem=webservices/:write-attribute(name=wsdl-secure-port,value=443)
Copy to Clipboard Toggle word wrap
注記
プロファイルを変更して別の管理対象ドメインを変更するか、スタンドアロンサーバーのコマンドの /profile=full-ha 部分を削除する必要があることがあります。

Web サービスサブシステム

Apache CXF でのロギングを有効にするには、standalone/domain.xml ファイルに以下のシステムプロパティーを設定します。

<system-properties>
<property name="org.apache.cxf.logging.enabled" value="true"/>
</system-properties>
Copy to Clipboard Toggle word wrap

16.2. ハンドラーおよびハンドラーチェーンの概要

各エンドポイント設定は PRE および POST ハンドラーチェーンに関連付けることができます。各ハンドラーチェーンには JAXWS 準拠のハンドラーを含めることができます。送信メッセージの場合、PRE ハンドラーチェーンハンドラーは、@HandlerChain アノテーションなどの標準の JAXWS を使用してエンドポイントにアタッチされたハンドラーの前に実行されます。POST ハンドラーチェーンハンドラーは、通常のエンドポイントハンドラーの後に実行されます。受信メッセージには、逆が適用されます。JAX-WS は XML ベースの Web サービスの標準 API で、で http://jcp.org/en/jsr/detail?id=224 説明されています。
ハンドラーチェーンには、チェーンが起動するプロトコルを設定する protocol-bindings 属性も含まれます。
JAXWS ハンドラーは、ハンドラーチェーン内の子要素 ハンドラー です。ハンドラーは、ハンドラー クラス の完全修飾クラス名である class 属性を取ります。エンドポイントがデプロイされると、参照デプロイメントごとにそのクラスのインスタンスが作成されます。デプロイメントクラスローダーまたはモジュール org.jboss.as.webservices.server.integration のクラスローダーのいずれかがハンドラークラスをロードできる必要があります。

手順16.1 CLI で handler-chains およびハンドラーを追加する方法

  1. JBoss EAP CLI の起動
    EAP_HOME/bin/jboss-cli.sh
    
    Copy to Clipboard Toggle word wrap
  2. JBoss CLI よりハンドラーチェーンおよびハンドラーを追加します。

    例16.1 ハンドラーチェーンの追加

    [standalone@localhost:9999 /] /subsystem=webservices/endpoint-config=Standard-Endpoint-Config/post-handler-chain=my-handlers:add(protocol-bindings="##SOAP11_HTTP")
    Copy to Clipboard Toggle word wrap

    例16.2 ハンドラーの追加

    [standalone@localhost:9999 /] /subsystem=webservices/endpoint-config=Standard-Endpoint-Config/post-handler-chain=my-handlers/handler=foo-hander:add(class="org.jboss.ws.common.invocation.RecordingServerHandler")
    Copy to Clipboard Toggle word wrap

    例16.3 ハンドラーの追加

    [standalone@localhost:9999 /] /subsystem=webservices/endpoint-config=Standard-Endpoint-Config/post-handler-chain=my-handlers/handler=bar-handler:add(class="com.arjuna.webservices11.wsarj.handler.InstanceIdentifierInHandler")
    Copy to Clipboard Toggle word wrap
  3. サーバーをリロードします。
    [standalone@localhost:9999 /] reload
    Copy to Clipboard Toggle word wrap
  4. handler-chain およびハンドラーが正しく追加されたことを確認します。

    例16.4 handler-chain の読み取り

    [standalone@localhost:9999 /] /profile=default/subsystem=webservices/endpoint-config=Standard-Endpoint-Config/post-handler-chain=my-handlers:read-resource
    Copy to Clipboard Toggle word wrap

    例16.5 ハンドラーの読み取り

    [standalone@localhost:9999 /] /profile=default/subsystem=webservices/endpoint-config=Standard-Endpoint-Config/post-handler-chain=my-handlers/handler=bar-handler:read-resource
    Copy to Clipboard Toggle word wrap
上記コマンドで使用されるオプションは、ハンドラーの追加または変更の必要に応じて変更できます。
JBoss EAP で利用可能なハンドラーについては、『API ドキュメント』 javadoc を参照してください。
ハンドラー、handler-chains、エンドポイント、および関連する問題に関する詳細は、『JBoss EAP『開発ガイド』』 を参照してください。 https://access.redhat.com/documentation/ja-jp/red_hat_jboss_enterprise_application_platform/?version=6.4

第17章 HTTP クラスタリングおよび負荷分散

17.1. HTTP サーバー名の規則

以下の表は、HTTPD 関連のトピックを説明する際に使用される命名規則および場所規則の概要を示しています。
Expand
表17.1 オペレーティングシステムが提供する Apache HTTP Server
Operating System HTTPD_CONF.D HTTPD_CONF HTTPD_MODULES
Red Hat Enterprise Linux (httpd) /etc/httpd/conf.d /etc/httpd/conf /etc/httpd/modules
HPUX(Web Server Suite) 以下の注記を参照してください。 /opt/hpws/apache/conf /opt/hpws/apache/modules
注記
Apache HTTP Server 用の HP-UX の Web サーバースイートには conf.d はありません。ただし、以下のように作成できます。

手順17.1 title

  1. Create /opt/hpws/apache/conf.d.
  2. Include conf.d/*.confhttpd.conf ファイルに追加します。
Expand
表17.2 JBoss Enterprise Web Server
Operating System HTTPD_CONF.D HTTPD_CONF HTTPD_MODULES
ディストリビューション
Red Hat Enterprise Linux /EWS_HOME/httpd/conf.d /EWS_HOME/httpd/conf /EWS_HOME/httpd/modules
zip
Red Hat Enterprise Linux
/etc/httpd/conf.d
/etc/httpd/conf
/usr/lib/httpd/modules
rpm
Solaris /EWS_HOME/etc/httpd/conf.d /EWS_HOME/etc/httpd/conf /EWS_HOME/lib/httpd/modules
zip
Windows /EWS_HOME/etc/httpd/conf.d /EWS_HOME/etc/httpd/conf
/EWS_HOME/lib/httpd/modules
zip
注記

パスの差異:

  • 64 ビットアーキテクチャーを使用している場合は、上記の表のファイルパスを修正して lib64/ ディレクトリーを使用します。
  • Red Hat Enterprise Linux 7 インストールを使用している場合は、httpd ディレクトリーの名前が httpd22 になります。

17.2. はじめに

17.2.1. 高可用性および負荷分散クラスター

クラスタリング とは、サーバーなどの複数のリソースを単一のエンティティーとして使用することを指します。主なクラスタリングには、負荷分散(LB)と 高可用性(HA) の 2 つのタイプがあります。LB クラスターでは、すべてのリソースが同時に実行され、管理層はそれらの間で負荷を分散します。
HA クラスタリングでは、1 つのリソースが実行され、もう 1 つは最初のリソースが利用できなくなった場合にステップで使用できます。HA クラスタリングの目的は、ハードウェア、ソフトウェア、またはネットワークの停止による影響を軽減することです。
JBoss EAP 6 は、クラスタリングを複数のレベルでサポートします。高可用性を実現できるランタイムおよびアプリケーションのコンポーネントには、以下が含まれます。
  • アプリケーションサーバーのインスタンス
  • 内部 JBoss Web サーバー、Apache HTTP サーバー、Microsoft IIS、または Oracle iPlanet Web Server と併用される Web アプリケーション
  • ステートフル、ステートレス、およびエンティティー Enterprise JavaBean (EJB)
  • シングルサインオン (SSO) メカニズム
  • 分散キャッシュ
  • HTTP セッション
  • JMS サービスおよびメッセージ駆動型 Bean (MDB)
JBoss EAP 6 では、jgroupsmodcluster の 2 つのサブシステムによってクラスタリングが使用できるようになります。ha プロファイルおよび full-ha プロファイルではこれらのシステムが有効になります。JBoss EAP 6 では、これらのサービスは必要に応じて起動およびシャットダウンしますが、配布可能 として設定されたアプリケーションがサーバーにデプロイされた場合のみ起動します。
JBoss EAP 6 では、Infinispan はキャッシュプロバイダーとして提供されます。Infinispan は JBoss EAP 6 のクラスタリングとレプリケーションキャッシュを管理します。

17.2.2. 高可用性が有益なコンポーネント

高可用性 (HA) は、JBoss EAP 6 の幅広いカテゴリーに分類されます。

コンテナ

JBoss EAP 6 の複数のインスタンス(スタンドアロンサーバーとして実行)またはサーバーグループのメンバー(管理対象ドメインの一部として実行)を高可用性に設定することが可能です。つまり、1 つのインスタンスまたはメンバーがクラスターから停止または非表示になると、そのワークロードがピアに移動します。負荷負荷も管理できるため、負荷分散機能も提供することができます。そのため、サーバーまたはサーバーグループのより優れたリソースを持つリソースを持つサーバーやサーバーグループは、負荷が高いときに追加で追加することも、負荷が高いときに追加で追加したりできます。

Web サーバー

互換性のある負荷分散メカニズムの 1 つを使用して、Web サーバー自体を HA 用にクラスター化することができます。最も柔軟性の高い mod_cluster コネクターは、JBoss EAP 6 コンテナーと密接に統合されています。その他の選択肢は、Apache mod_jk または mod_proxy コネクター、ISAPI コネクター、NSAPI コネクターなどです。

アプリケーション

Java Enterprise Edition 6(Java EE 6)仕様により、デプロイされたアプリケーションを高可用性にすることが可能です。ステートレスまたはステートフルセッション EJB をクラスター化できるため、作業に関与するノードがなくなると、別のノードが引き継ぎ、ステートフルセッション Bean の場合は状態が保持されます。

17.2.3. HTTP コネクターの概要

JBoss EAP 6 には、Apache Web Server、Microsoft IIS、Oracle iPlanet などの外部 Web サーバーに構築された負荷分散および高可用性メカニズムを使用する機能があります。JBoss EAP 6 はコネクターを使用して外部 Web サーバーと通信します。これらのコネクターは JBoss EAP 6 の web サブシステム内に設定されます。
Web サーバーには、HTTP リクエストが JBoss EAP 6 ノードにルーティングされる方法を制御するソフトウェアモジュールが含まれます。これらのモジュールの挙動や設定方法はモジュールごとに異なります。モジュールは、複数の JBoss EAP 6 ノード全体でワークロードを分散したり、障害発生時にワークロードを別のサーバーに移動したりするために設定されます。これらの機能は、ロードバランシング および 高可用性(HA) と呼ばれます。
JBoss EAP 6 は複数のコネクターをサポートします。使用中の Web サーバーや必要な機能に応じてコネクターを選択します。
以下の表は、JBoss EAP 6 と互換性のある HTTP コネクターの違いを示しています。HTTP コネクターのサポートされる構成に関する最新情報は、を参照してください https://access.redhat.com/articles/111663
Expand
表17.3 HTTP コネクター機能および制約
コネクター Web サーバー サポート対象オペレーティングシステム サポート対象プロトコル デプロイメント状態への適合 スティッキーセッションのサポート
mod_cluster JBoss Enterprise Web Server の httpd、オペレーティングシステム (Red Hat Enterprise Linux、Hewlett-Packard HP-UX) によって提供される httpd Red Hat Enterprise Linux、Microsoft Windows Server、Oracle Solaris、Hewlett-Packard HP-UX HTTP、HTTPS、AJP 必要。アプリケーションのデプロイメントとアンデプロイメントを検出し、アプリケーションがそのサーバーにデプロイされたかどうかに基づいて、サーバーにクライアント要求を送信するかどうかを動的に決定します。 はい
mod_jk JBoss Enterprise Web Server の httpd、オペレーティングシステム (Red Hat Enterprise Linux、Hewlett-Packard HP-UX) によって提供される httpd Red Hat Enterprise Linux、Microsoft Windows Server、Oracle Solaris、Hewlett-Packard HP-UX AJP 不可。 アプリケーションの状態に関係なく、コンテナーが利用可能な限り、クライアント要求をコンテナーに送信します。 はい
mod_proxy JBoss Enterprise Web Server の httpd Red Hat Enterprise Linux、Microsoft Windows Server、Oracle Solaris HTTP、HTTPS、AJP 不可。 アプリケーションの状態に関係なく、コンテナーが利用可能な限り、クライアント要求をコンテナーに送信します。 はい
ISAPI コネクター Microsoft IIS Microsoft Windows Server AJP 不可。 アプリケーションの状態に関係なく、コンテナーが利用可能な限り、クライアント要求をコンテナーに送信します。 はい
NSAPI コネクター Oracle iPlanet Web Server Oracle Solaris AJP 不可。 アプリケーションの状態に関係なく、コンテナーが利用可能な限り、クライアント要求をコンテナーに送信します。 はい
JBoss EAP 6 でサポートされる構成は次のとおり https://access.redhat.com/articles/111663 です。

17.2.4. ノードのタイプ

HTTP コネクターノード

ワーカーノードは、ノード と呼ばれることもあります。これは、プロキシーとして機能する 1 つ以上のクライアント向け HTTP サーバーからの要求を許可する JBoss EAP 6 サーバーインスタンスです。JBoss EAP 6 は、Apache HTTP Server、Microsoft IIS、または Oracle iPlanet Web Server(旧名 Netscape Web Server)からの HTTP、HTTPS および AJP リクエストを許可できます。

JBoss EAP 6 でサポートされる HTTP コネクターの概要と設定方法は、「HTTP コネクターの概要」 を参照してください。

クラスターノード

クラスターノード はワーカーノードの特殊な設定です。このようなクラスターは、負荷分散、高可用性、またはその両方です。負荷分散クラスターでは、状況固有の測定により、中央マネージャーはノードに負荷を均等に分散します。高可用性クラスターでは、一部のノードがアクティブに作業を行い、アクティブなノードの 1 つがクラスターから離れる場合にステップを待機しています。

例17.1 mod_cluster が設定された Apache HTTP Server

たとえば、mod_cluster が設定された Apache HTTP Server がクライアントのリクエストへの負荷分散プロキシーとして動作する設定が可能です。これらの要求は、現在の負荷に従って特定のクラスターノードに転送されます。スティッキーセッションが無効の場合、受信リクエストはすべて現在の負荷に従って分散されます。スティッキーセッションが有効な場合(デフォルト)、すでに作成されたセッション内の後続のリクエストは、セッションが作成されたワーカーノードにルーティングされます。これらのクラスターノードのいずれかが停止またはオーバーロードすると、負荷分散プロキシーとして動作する mod_cluster がある Apache HTTP Server はクライアントのリクエストを別のクラスターノードに転送します。クラスター内のセッションレプリケーションにより、クライアントのデータは失われません。
同様に、クラスター化されていないワーカーノードの設定が簡単に行えます。ワーカーノードが停止している場合、その近傍に former セッションデータがない場合には、クライアントは HTTP 200 以外のエラーコードを取得しません。
スティッキーセッションの設定は、ワーカーノードがクラスター化されているかどうかに拘らず、負荷分散プロキシーは重要ではありません。

17.3. コネクター設定

17.3.1. JBoss EAP 6 にて HTTP コネクターのスレッドプールを定義

概要

JBoss EAP 6 のスレッドプールは、Executor モデルを使用して異なるコンポーネント間で共有できます。これらのプールは、異なる(HTTP)コネクターによる共有だけでなく、Executor モデルをサポートする JBoss EAP 6 内の他のコンポーネントも共有できます。現在の Web パフォーマンス要件に一致するように HTTP コネクタースレッドプールを取得することは複雑です。現在のスレッドプールと現在の Web 負荷要求と予想される Web 負荷要求を詳細に監視する必要があります。このタスクでは、Executor モデルを使用して HTTP コネクターのスレッドプールを設定する方法を説明します。管理 CLI と XML 設定ファイルの両方を使用してこれを設定する方法を説明します。

注記
JBoss EAP をドメインモードで実行している場合は、この手順で接頭辞 /profile=PROFILE_NAME をすべての管理 CLI コマンドに追加します。

手順17.2 HTTP コネクターのスレッドプールの設定

  1. スレッドファクトリーの定義

    設定ファイルを開きます(スタンドアロンサーバーに対して変更する場合はstandalone.xml、ドメインベースの設定に対して変更する場合は domain.xml )。このファイルは EAP_HOME/standalone/configuration または EAP_HOME/domain/configuration フォルダーにあります。
    次のサブシステムエントリーを追加します。値はサーバーの要件に合わせて変更します。
    <subsystem xmlns="urn:jboss:domain:threads:1.1">
        <thread-factory name="http-connector-factory" thread-name-pattern="HTTP-%t" priority="9" group-name="uq-thread-pool"/>
    </subsystem>
    
    Copy to Clipboard Toggle word wrap
    管理 CLI を使用してこのタスクを実行する場合は、CLI コマンドプロンプトで次のコマンドを実行します。
    [standalone@localhost:9999 /] ./subsystem=threads/thread-factory=http-connector-factory:add(thread-name-pattern="HTTP-%t", priority="9", group-name="uq-thread-pool")
    Copy to Clipboard Toggle word wrap
  2. エクゼキューターの作成

    6 つの組み込みエクゼキュータークラスの 1 つを使用して、このファクトリーのエクゼキューターとして動作します。6 つのエクゼキューターは以下のとおりです。
    • unbounded-queue-thread-pool: このタイプのスレッドプールは常にタスクを許可します。実行されているスレッドの最大数を下回ると、新しいスレッドが起動し、送信されたタスクが実行されます。それ以外の場合、タスクはスレッドが利用可能になるとバインドされていない FIFO キューに置かれます。
      注記
      Executors.singleThreadExecutor() が提供する単一スレッドエグゼキュータータイプは、スレッド制限が 1 つに制限されているバインドされていないキューエグゼキューターです。このタイプのエクゼキューターは unbounded-queue-thread-pool-executor 要素を使用してデプロイされます。
    • bounded-queue-thread-pool: このタイプのエクゼキューターは固定長のキューと、core サイズと maximum サイズという 2 つのプールサイズを維持します。タスクが受け入れられると、実行中のプールスレッドの数が core サイズ未満の場合は、タスクの実行に新しいスレッドが開始されます。スペースがキューに残ると、タスクはキューに配置されます。実行中のプールスレッドの数が maximum サイズ未満の場合は、新しいスレッドが開始されてタスクを実行します。エグゼキューターでブロックが有効になっていると、呼び出しスレッドは、キューで領域が利用可能になるまでブロックします。ハンドオフエクゼキューターが設定されている場合、タスクは Handoff エグゼキューターに委任されます。そうでない場合は、タスクは拒否されます。
    • blocking-bounded-queue-thread-pool: スレッドの送信タスクがブロックされるバインドされたキューを持つスレッドプールエクゼキューター。このようなスレッドプールにはコアおよび最大サイズがあり、指定されたキューの長さがあります。タスクが送信されると、実行中のスレッド数がコアサイズ未満の場合、新しいスレッドが作成されます。そうでないと、キューに余裕がある場合はタスクはキューに置かれます。実行中スレッドの数が最大サイズ未満の場合は、新しいスレッドが作成されます。そうでないと、呼び出し元は、その部屋がキューで利用可能になるまでブロックされます。
    • queueless-thread-pool: 場合によっては、別のスレッドでタスクを実行するには単純なスレッドプールが必要であり、キューを干渉しないタスクを完了するため、スレッドを再利用する必要があります。このタイプのプールは、タスクを受け入れ、他の実行中のタスクが完了するまで実行を遅らせるのではなく、タスクは常に承認直後に開始するなど、長時間実行されるタスクを処理するのに適しています。このタイプのエクゼキューターは queueless-thread-pool-executor 要素を使用して宣言されます。
    • blocking-queueless-thread-pool: スレッドの送信タスクがブロックされるキューのないスレッドプールエクゼキューター。タスクが送信されると、実行中のスレッド数が最大サイズ未満の場合は、新しいスレッドが作成されます。それ以外の場合は、呼び出し元は、別のスレッドがタスクを完了し、新しいタスクを許可するまでブロックします。
    • scheduled-thread-pool: これは、java.util.concurrent.ScheduledThreadPoolExecutor クラスに基づいて、特定の時間および時間間隔でタスクを実行する特別なタイプのエクゼキューターです。このタイプのエクゼキューターは scheduled-thread-pool-executor 要素で設定されます。
    この例では、unbounded-queue-thread-pool を使用してエクゼキューターとして機能します。サーバーのニーズに合わせて max-threads および keepalive-time パラメーターの値を変更します。
    <unbounded-queue-thread-pool name="uq-thread-pool">
      <thread-factory name="http-connector-factory" />
      <max-threads count="10" />
      <keepalive-time time="30" unit="seconds" />
    </unbounded-queue-thread-pool>
    Copy to Clipboard Toggle word wrap
    管理 CLI を使用する場合は、以下を行います。
    [standalone@localhost:9999 /] ./subsystem=threads/unbounded-queue-thread-pool=uq-thread-pool:add(thread-factory="http-connector-factory", keepalive-time={time=30, unit="seconds"}, max-threads=30)
    Copy to Clipboard Toggle word wrap
  3. HTTP Web コネクターがこのスレッドプールを使用するようにする

    同じ設定ファイルで、Web サブシステム下にある HTTP コネクター要素を見つけ、前の手順で定義したスレッドプールを使用するよう編集します
    <connector name="http" protocol="HTTP/1.1" scheme="http" socket-binding="http" executor="uq-thread-pool" />
    Copy to Clipboard Toggle word wrap
    管理 CLI を使用する場合は、以下を実行します。
    [standalone@localhost:9999 /] ./subsystem=web/connector=http:write-attribute(name=executor, value="uq-thread-pool")
    Copy to Clipboard Toggle word wrap
  4. サーバーの再起動

    サーバー(スタンドアロンまたはドメイン)を再起動して、変更を有効にします。以下の管理 CLI コマンドを使用して、上記の手順からの変更が実施されたかどうかを確認します。
    [standalone@localhost:9999 /] ./subsystem=threads:read-resource(recursive=true)
    {                  
        "outcome" => "success",
        "result" => {
            "blocking-bounded-queue-thread-pool" => undefined,
            "blocking-queueless-thread-pool" => undefined,
            "bounded-queue-thread-pool" => undefined,
            "queueless-thread-pool" => undefined,
            "scheduled-thread-pool" => undefined,
            "thread-factory" => {"http-connector-factory" => {
                "group-name" => "uq-thread-pool",
                "name" => "http-connector-factory",
                "priority" => 9,
                "thread-name-pattern" => "HTTP-%t"
            }},
            "unbounded-queue-thread-pool" => {"uq-thread-pool" => {
                "keepalive-time" => {
                    "time" => 30L,
                    "unit" => "SECONDS"
                },
                "max-threads" => 30,
                "name" => "uq-thread-pool",
                "thread-factory" => "http-connector-factory"
            }}
        }
    }
    [standalone@localhost:9999 /] ./subsystem=web/connector=http:read-resource(recursive=true)
    {
        "outcome" => "success",
        "result" => {
            "configuration" => undefined,
            "enable-lookups" => false,
            "enabled" => true,
            "executor" => "uq-thread-pool",
            "max-connections" => undefined,
            "max-post-size" => 2097152,
            "max-save-post-size" => 4096,
            "name" => "http",
            "protocol" => "HTTP/1.1",
            "proxy-name" => undefined,
            "proxy-port" => undefined,
            "redirect-port" => 443,
            "scheme" => "http",
            "secure" => false,
            "socket-binding" => "http",
            "ssl" => undefined,
            "virtual-server" => undefined
        }
    }
    
    Copy to Clipboard Toggle word wrap

結果

スレッドファクトリーとエクゼキューターが正常に作成され、このスレッドプールを使用するよう HTTP コネクターが編集されます。

17.4. Web サーバーの設定

17.4.1. スタンドアロン Apache HTTP Server

JBoss EAP 6 は、認定されたバージョンの Red Hat Enterprise Linux 6 に含まれる Apache HTTP サーバーでテストされ、サポートされています。Apache HTTP サーバーは、Microsoft Windows Server などの他のオペレーティングシステムにも利用可能です。しかし、Apache HTTP サーバーは Apache Foundation によって作成された個別の製品であるため、お客様が使用した Apache HTTP サーバーのバージョンが JBoss EAP と互換性があることを確認することは容易ではありませんでした。
スタンドアロン Apache HTTP サーバーバンドルが JBoss EAP 6 の個別ダウンロードとして利用できるようになりました。これにより、Red Hat Enterprise Linux 以外の環境や、Apache HTTP サーバーが設定されていて、Web アプリケーションに別のインスタンスを使用するシステムにおいて、インストールと設定が容易になります。この Apache HTTP Server は、インストールプラットフォームで利用可能な JBoss EAP 6 ダウンロードの配下にある Customer Service Portal で個別ダウンロードとしてダウンロードできます。

17.4.2. HTTPD 変数規則

Expand
表17.4 ネイティブ
製品 HTTPD_CONF HTTPD_MODULES
Red Hat Enterprise Linux /etc/httpd/conf /etc/httpd/modules
HPUX /opt/hpws/apache/conf /opt/hpws/apache/modules
Expand
表17.5 EWS
製品 HTTPD_CONF HTTPD_MODULES
Red Hat Enterprise Linux /HTTPD_HOME/EWS-ROOT/httpd/conf /HTTPD_HOME/EWS-ROOT/httpd/modules
Solaris /HTTPD_HOME/EWS-ROOT/etc/httpd/conf
/HTTPD_HOME/EWS-ROOT/lib/httpd/modules
または
/HTTPD_HOME/EWS-ROOT/lib64/httpd/modules
Windows /HTTPD_HOME/EWS-ROOT/etc/httpd/conf
/HTTPD_HOME/EWS-ROOT/lib/httpd/modules
または
/HTTPD_HOME/EWS-ROOT/lib64/httpd/modules

17.4.3. Red Hat Enterprise Linux 5、6、7 への Apache HTTP Server のインストール(Zip)

前提条件

  • root または管理者権限。
  • サポートされるバージョンの Java がインストールされている必要があります。
  • 以下のパッケージがインストールされている必要があります:
    • krb5-workstation
    • mod_auth_kerb (Kerberos 機能に必要)
    • elinksapachectl 機能に必要)
    • apr-util-devel (Apache Portability Runtime(APR))
    • apr-util-ldap (Red Hat Enterprise Linux 7 のみ。LDAP 認証機能に必要です)
Apache HTTP Server Zip アーカイブには、複数の Kerberos モジュールへのシンボリックリンクが含まれます。そのため、mod_auth_kerb パッケージが前提条件となります。Kerberos 機能が必要ない場合は、mod_auth_kerb パッケージをインストールする必要はなく、関連するシンボリックリンクを削除できます( EAP_HOME/httpd/modules/mod_auth_kerb.so )。

手順17.3 Apache HTTP Server のインストール

  1. Red Hat カスタマーポータル上でご使用のプラットフォームの JBoss EAP ダウンロードリストへ移動します。

    カスタマーポータル にログインし、Software Downloads ページに移動します。適切な Product および Version を選択します。
  2. 一覧から Apache HTTP Server バイナリーを選択します。

    オペレーティングシステムおよびアーキテクチャー用の Apache HTTP Server オプションを検索します。Download リンクをクリックします。Apache HTTP Server ディストリビューションを含む Zip ファイルがコンピューターにダウンロードされます。
  3. Apache HTTP Server バイナリーを実行するシステムに Zip を展開します。

    任意のサーバーの Zip ファイルを一時的な場所に展開します。Zip ファイルには、jboss-ews-version-number フォルダーの下に httpd ディレクトリーが含まれます。httpd フォルダーをコピーし、EAP_HOME ディレクトリー内に配置します。
    Apache HTTP Server が EAP_HOME/httpd/ ディレクトリーにあります。このディレクトリーは HTTPD_HOME と呼ばれます。
  4. インストール後のスクリプトを実行して、Apache ユーザーおよびグループ アカウントを作成します。

    端末エミュレーターで EAP_HOME/httpd ディレクトリーに移動し、root ユーザー権限で以下のコマンドを実行します。
    ./.postinstall
    Copy to Clipboard Toggle word wrap
    次に、以下のコマンドを実行して、apache ユーザーがシステムにインストールされていることを確認します。
    id apache
    Copy to Clipboard Toggle word wrap
    ユーザーが存在しない場合は、適切なユーザーグループと共に追加する必要があります。これを行うには、root ユーザー権限で実行します。
    getent group apache >/dev/null || groupadd -g 48 -r apache
    getent passwd apache >/dev/null || useradd -r -u 48 \
    -g apache -s /sbin/nologin  -d HTTPD_HOME/httpd/www -c "Apache" apache
    
    Copy to Clipboard Toggle word wrap
    この作業が完了したら、apache ユーザーが Apache HTTP Server サービスを実行している場合、HTTP ディレクトリーの所有者を変更する必要があります。
    chown -R apache:apache httpd
    Copy to Clipboard Toggle word wrap
    上記のコマンドが正常に行われたことを確認するには、apache ユーザーに Apache HTTP Server のインストールパスの実行権限があることを確認します。
    ls -l
    Copy to Clipboard Toggle word wrap
    出力は以下のようになります。
    drwxrwxr-- 11 apache apache 4096 Feb 14 06:52 httpd
    Copy to Clipboard Toggle word wrap
  5. Apache HTTP Server を設定します。

    Apache HTTP Server を起動する前に、組織のニーズに合わせて設定します。一般的なガイダンスは、Apache Foundation の http://httpd.apache.org/ のドキュメントを参照してください。
  6. Apache HTTP Server を起動します。

    以下のコマンドを使用して Apache HTTP Server を起動します。
    HTTPD_HOME/httpd/sbin/apachectl start
    Copy to Clipboard Toggle word wrap
  7. Apache HTTP Server を停止します。

    Apache HTTP Server を停止するには、以下のコマンドを実行します。
    HTTPD_HOME/httpd/sbin/apachectl stop
    Copy to Clipboard Toggle word wrap

17.4.4. Red Hat Enterprise Linux (RHEL) 5、6、および 7 への Apache HTTP Server のインストール (RPM)

前提条件

  • ルートレベルのアクセス。
  • 最新バージョンの elinks パッケージがインストールされています(apachectl 機能に必要)。
  • Red Hat Enterprise Linux (RHEL) チャンネルをサブスクライブする必要があります (RHEL チャンネルから Apache HTTP Server をインストールするため)。
  • jbappplatform-6-ARCH-server-VERS-rpm Red Hat Network(RHN)チャンネルをサブスクライブする必要があります(Apache HTTP Server の EAP 固有のディストリビューションをインストールするため)。
以下の方法の 1 つを使用して Apache HTTP Server をインストールできます。
  • Red Hat Enterprise Linux (RHEL) チャンネルからのインストール。Apache HTTP Server のインストールには Red Hat Enterprise Linux (RHEL) チャンネルの有効なサブスクリプションが必要です。
  • jbappplatform-6-ARCH-server-VERS-rpm チャンネル(JBoss EAP 固有のディストリビューション)から以下を行います。JBoss EAP は Apache HTTP Server の独自のバージョンを配布します。Apache HTTP Server の JBoss EAP 固有のディストリビューションをインストールするには、jbappplatform-6-ARCH-server-VERS-rpm チャンネルへのアクティブなサブスクリプションが必要です。

手順17.4 Red Hat Enterprise Linux 5 および 6 への Apache HTTP Server のインストールおよび設定 (RPM)

  1. httpdのインストール

    JBoss EAP 固有のバージョンの httpd パッケージをインストールするには、以下のコマンドを実行します。
    yum install httpd
    Copy to Clipboard Toggle word wrap
    Red Hat Enterprise Linux(RHEL)チャンネルから httpd を明示的にインストールするには、以下のコマンドを実行します。
     yum install httpd --disablerepo=jbappplatform-6-*
    Copy to Clipboard Toggle word wrap
    注記
    上記のコマンドのいずれかを実行して、システムに httpd パッケージをインストールする必要があります。
  2. サービスブートの挙動設定

    コマンドラインまたはサービス設定のグラフィカルツールから、システムの起動時に httpd サービスのサービス動作を定義できます。次のコマンドを実行して動作を定義します。
     chkconfig httpd on
    Copy to Clipboard Toggle word wrap
    サービス設定ツールを使用するには、以下のコマンドを実行し、表示されたウインドウでサービス設定を変更します。
     system-config-services
    Copy to Clipboard Toggle word wrap
  3. Start httpd

    以下のコマンドを使用して httpd を起動します。
    service httpd start
    Copy to Clipboard Toggle word wrap
  4. Stop httpd

    以下のコマンドを使用して httpd を停止します。
    service httpd stop
    Copy to Clipboard Toggle word wrap

手順17.5 Red Hat Enterprise Linux 7 への Apache HTTP Server のインストールおよび設定 (RPM)

  1. Install httpd22

    JBoss EAP 固有のバージョンの httpd22 パッケージをインストールするには、以下のコマンドを実行します。
    yum install httpd22
    Copy to Clipboard Toggle word wrap
  2. サービスブートの挙動設定

    以下のコマンドを実行して、システムの起動時に httpd22 サービスを起動します。
    systemctl enable httpd22.service
    Copy to Clipboard Toggle word wrap
  3. Start httpd22

    以下のコマンドを使用して httpd22 を起動します。
    systemctl start httpd22.service
    Copy to Clipboard Toggle word wrap
  4. Stop httpd22

    以下のコマンドを使用して httpd22 を停止します。
    systemctl stop httpd22.service
    Copy to Clipboard Toggle word wrap

17.4.5. Microsoft Windows Server 環境向け Apache HTTP Server サービスの管理

手順17.6 Microsoft Windows Server 環境用の Apache HTTP Server サービスのインストール

  • このコマンドを使用して Apache HTTP Server サービスをインストールします。

    cd /D "%EWS_HOME%\bin"
    httpd -k install
    Copy to Clipboard Toggle word wrap
    このコマンドは、Apache2.2 という名前の Apache HTTP Server サービスをインストールします。
    サービスに別の名前(ApacheBalancer など)を指定するには、以下のコマンドを使用します。
    cd /D "%EWS_HOME%\bin"
    httpd -k install -n ApacheBalancer
    Copy to Clipboard Toggle word wrap

手順17.7 Microsoft Windows Server 環境用の Apache HTTP Server サービスの開始

  • サービスを起動するには、httpd.exe またはサービスマネージャーを使用します。

    httpd.exe の使用:
    cd /D "%EWS_HOME%\bin"
    httpd -k start -n Apache2.2
    Copy to Clipboard Toggle word wrap
    サービスマネージャーの使用:
    net start Apache2.2
    Copy to Clipboard Toggle word wrap

手順17.8 Microsoft Windows Server 環境の Apache HTTP Server サービスを停止します。

  • サービスを停止するには、httpd.exe またはサービスマネージャーを使用します。

    httpd.exe の使用:
    cd /D "%EWS_HOME%\bin"
    httpd -k stop -n Apache2.2
    Copy to Clipboard Toggle word wrap
    サービスマネージャーの使用:
    net stop Apache2.2
    Copy to Clipboard Toggle word wrap

手順17.9 Microsoft Windows Server 環境用の Apache HTTP Server サービスのアンインストール

  • サービスをアンインストールするには、名前で参照する必要があります。たとえば、サービス名 ApacheBalancer をアンインストールするには、以下のコマンドを使用します。

    cd /D "%EWS_HOME%\bin"
    httpd -k uninstall -n ApacheBalancer
    Copy to Clipboard Toggle word wrap

17.4.6. Apache HTTP Server での mod_cluster 設定

概要

mod_cluster コネクターは Apache HTTP Server ベースのロードバランサーです。通信チャネルを使用して、リクエストを Apache HTTP Server からアプリケーションサーバーノードのセットの 1 つに転送します。以下の派生を設定して mod_cluster を設定できます。

注記
mod_cluster は Apache HTTP Server に転送される必要がある URL を自動的に設定するため、ProxyPass ディレクティブを使用する必要はありません。
Expand
表17.6 mod_cluster の派生
派生 説明
CreateBalancers バランサーが Apache HTTP Server の VirtualHosts でどのように作成されるかを定義します。 ProxyPass /balancer://mycluster1/ のようなディレクティブを許可し ます。
0: Apache HTTP Server に定義されるすべての VirtualHosts を作成します。
1: バランサーを作成してはいけない (バランサー名の定義に最低でも 1 つの ProxyPass または ProxyMatch が必要)
2: メインサーバーのみを作成する
デフォルト: 2
値 1 を使用する場合は、必ず ProxyPass ディレクティブにバランサーを設定するようにしてください。これは、デフォルト値は空の stickysession および nofailover=Off であり、MCMP CONFIG メッセージを介して受信された値は無視されます。
UseAlias エイリアスがサーバー名に対応することを確認します。
0: エイリアスを無視する
1: エイリアスを確認する
デフォルト: 0
LBstatusRecalTime 負荷分散論理がノードの状態を再計算する間隔 (秒単位)。
デフォルト: 5 秒
WaitBeforeRemove 削除されたノードを httpd が記憶しなくなるまでの時間 (分単位)。
デフォルト: 10 秒
ProxyPassMatch/ProxyPass
ProxyPassMatch および ProxyPass は(バックエンド URL ではなく) ! を使用する場合、パスのリバースプロキシーを防ぐ mod_proxy ディレクティブです。これは、Apache HTTP Server が静的なコンテンツに対応できるようにするために使用されます。以下に例を示します。
ProxyPassMatch ^(/.*\.gif)$ !
上記の例では、Apache HTTP Server は直接 .gif ファイルに対応できます。
mod_cluster ロジックのホットスタンバイノードは、他のすべてのノードがダウンした場合にすべての要求がルーティングされる最後のノードです。これは mod_proxy のホットスタンバイ論理と似ています。
ホットスタンバイノードを設定するには、mod_cluster サブシステムの dynamic-load-provider を、ファクターが 0 に設定されている simple-load-provider に置き換えます。
<subsystem xmlns="urn:jboss:domain:modcluster:1.2">
    <mod-cluster-config advertise-socket="modcluster" connector="ajp">
-        <dynamic-load-provider>
-            <load-metric type="busyness"/>
-        </dynamic-load-provider>
+        <simple-load-provider factor="0"/>
    </mod-cluster-config>
</subsystem>

Copy to Clipboard Toggle word wrap
mod_cluster-manager コンソールでは、ノードが OK ステータスと Load: 0 で表示されます。詳細は、『JBoss Enterprise 『Application Platform『開発ガイド』』 の「Apache mod_cluster-manager』 アプリケーション」を参照してください。
たとえば、以下の 3 つのノードがあるとします。
  • ノード A、Load: 10
  • ノード B、Load: 10
  • ノード C、Load: 0
この場合、負荷はノード A と B の間で分散されます。両方のノードが使用できない場合は、ノード C に負荷が集中します。

mod_manager

mod_manager ディレクティブのコンテキストは、指定がある場合を除きすべて VirtualHost になります。サーバー設定 コンテキストは、ディレクティブが VirtualHost 設定外になければならないことを示します。そうでない場合、エラーメッセージが表示され、Apache HTTP Server が開始しません。

Expand
表17.7 mod_manager の派生
派生 説明
EnableMCPMReceive VirtualHost がノードから MCPM を受信できるようにします。mod_cluster が動作するようにするため、Apache HTTP Server 設定に EnableMCPMReceive が含まれます。VirtualHost のアドバタイズを設定する場所に保存します。
MemManagerFile
設定の保存、共有メモリーまたはロックされたファイルのキーの生成に mod_manager が使用する名前のベース名。絶対パス名である必要があります。ディレクトリーは必要な場合に作成されます。
これらのファイルは NFS 共有ではなくローカルドライブに格納することが推奨されます。 コンテキスト: server config
$server_root/logs/
Maxcontext mod_cluster によってサポートされるコンテキストの最大数。
コンテキスト: server config
デフォルト: 100
Maxnode mod_cluster によってサポートされるノードの最大数。
コンテキスト: server config
デフォルト: 20
Maxhost mod_cluster によってサポートされるホスト(エイリアス)の最大数。バランサーの最大数も含まれます。
コンテキスト: server config
デフォルト: 20
Maxsessionid
mod_cluster-manager ハンドラーにアクティブなセッションの数を提供するために保存されるアクティブな sessionid の数。5 分以内に mod_cluster がセッションから情報を受信しないとセッションは非アクティブになります。
コンテキスト: server config
このフィールドはデモおよびデバッグの目的のみで使用されます。
0: 論理はアクティベートされない。
MaxMCMPMaxMessSize 他の Max ディレクティブからの MCMP メッセージの最大サイズ。 他の Max ディレクティブより計算されます。最小: 1024
ManagerBalancerName JBoss EAP インスタンスがバランサー名を提供しない場合に使用されるバランサーの名前。
mycluster
PersistSlots ファイルのノード、エイリアス、およびコンテキストを保持するよう mod_slotmem に伝えます。
コンテキスト: server config
オフ
CheckNonce mod_cluster-manager ハンドラーを使用する際に nonce のチェックを切り替えます。
on/off
デフォルト: on - Nonce をチェック
AllowDisplay mod_cluster-manager メインページの追加表示を切り替えます。
on/off
デフォルト: off - バージョンのみを表示
AllowCmd mod_cluster-manager の URL を使用するコマンドを許可します。
on/off
デフォルト: on - コマンドを許可
ReduceDisplay メインの mod_cluster-manager ページに表示される情報を減らし、ページ上により多くのノードを表示できるようにします。
on/off
デフォルト: off - 情報をすべて表示
SetHandler mod_cluster-manager
mod_cluster がクラスターから可視できるノードの情報を表示します。情報には一般的な情報が含まれ、追加でアクティブなセッションの数を調べます。
						<Location /mod_cluster-manager>
							SetHandler mod_cluster-manager
							Order deny,allow
							Allow from 127.0.0.1
							</Location>
Copy to Clipboard Toggle word wrap
on/off
デフォルト: off
注記
httpd.conf に定義された場所にアクセスする場合:
Transferred: バックエンドサーバーに送信された POST データに対応。
Connected: mod_cluster の状態ページが要求されたときに処理された要求の数に対応。
Num_sessions: mod_cluster がアクティブと報告するセッションの数に対応 (過去 5 分以内に要求があった場合)。Maxsessionid がゼロの場合、このフィールドは存在しません。 このフィールドはデモおよびデバッグの目的でのみ使用されます。

17.4.7. 外部 Web サーバーを JBoss EAP 6 アプリケーションの Web フロントエンドとして使用

概要

外部 Web サーバーを Web フロントエンドとして使用する理由や、JBoss EAP 6 でサポートされるさまざまな HTTP コネクターの利点と欠点については、「HTTP コネクターの概要」 を参照してください。場合によっては、お使いのオペレーティングシステムに同梱される Apache HTTP Server を使用できます。それ以外の場合は、JBoss Enterprise Web Server の一部として同梱される Apache HTTP Server を使用できます。

使用する Web サーバーおよび HTTP コネクターを決定したら、以下のいずれかの手順を参照してください。

17.4.8. 外部 Web サーバーからの要求を許可するよう JBoss EAP 6 を設定

概要

JBoss EAP 6 は、リクエストを許可するプロキシー、検索するポートおよびプロトコルのみを認識する必要はありません。これは mod_cluster ではなく、JBoss EAP 6 の設定と密接に結合されます。しかし、mod_jkmod_proxyISAPI コネクター、および NSAPI コネクター では、以下のタスクが動作します。この例のプロトコルおよびポートを設定する必要のあるプロトコルおよびポートに置き換えます。

mod_cluster に対して JBoss EAP 6 を設定するには、「mod_cluster ワーカーノードの設定」 を参照してください。

前提条件

  • このタスクを実行するには、管理 CLI または管理コンソールにログインする必要があります。タスクの正確な手順では管理 CLI を使用しますが、管理コンソールでは同じ基本的な手順が使用されます。
  • 使用するプロトコル (HTTP、HTTPS、または AJP) のリストが必要です。

手順17.10 設定の編集およびソケットバインディングの追加

  1. jvmRoute システムプロパティーを設定します。

    スタンドアロンモードインスタンスの場合は、/host=NODE_NAME のプレフィックスを削除します。NODE_NAME は、ホスト名に置き換えます。
    /host=NODE_NAME/system-property=jvmRoute/:add(value=NODE_NAME)
    Copy to Clipboard Toggle word wrap
  2. Web サブシステムで利用可能なコネクターをリストします。

    注記
    この手順は、スタンドアロンサーバーまたは管理対象ドメインのサーバーグループに ha または full-ha プロファイルを使用していない場合のみ必要になります。これらの設定には、必要なコネクターがすべて含まれています。
    外部 Web サーバーが JBoss EAP 6 の Web サーバーに接続できるようにするには、web サブシステムにコネクターが必要です。各プロトコルには、ソケットグループに関連付けられる独自のコネクターが必要です。
    現在利用可能なコネクターをリストするには、以下のコマンドを実行します。
    /subsystem=web:read-children-names(child-type=connector)
    Copy to Clipboard Toggle word wrap
    必要なコネクター (HTTP、HTTPS、AJP) を示す行がない場合は、コネクターを追加する必要があります。
  3. コネクターの設定を確認します。

    コネクターの設定方法の詳細を確認するには、その設定を読み取ります。以下のコマンドは、AJP コネクターの設定を読み取ります。他のコネクターの設定出力も同様になります。
    /subsystem=web/connector=ajp:read-resource(recursive=true)
    {
        "outcome" => "success",
        "result" => {
            "enable-lookups" => false,
            "enabled" => true,
            "max-post-size" => 2097152,
            "max-save-post-size" => 4096,
            "protocol" => "AJP/1.3",
            "redirect-port" => 8443,
            "scheme" => "http",
            "secure" => false,
            "socket-binding" => "ajp",
            "ssl" => undefined,
            "virtual-server" => undefined
        }
    }
    
    Copy to Clipboard Toggle word wrap
  4. 必要なコネクターを Web サブシステムに追加します。

    コネクターを Web サブシステムに追加するには、ソケットバインディングが必要です。ソケットバインディングは、サーバーまたはサーバーグループによって使用されるソケットバインディンググループに追加されます。以下の手順は、サーバーグループが server-group-one で、ソケットバインディンググループが standard-sockets であることを前提としています。
    1. ソケットをソケットバインディンググループに追加します。

      ソケットをソケットバインディンググループに追加するには、以下のコマンドを実行し、プロトコルとポートを必要なものに置き換えます。
      /socket-binding-group=standard-sockets/socket-binding=ajp:add(port=8009)
      Copy to Clipboard Toggle word wrap
    2. ソケットバインディングを Web サブシステムに追加します。

      以下のコマンドを発行してコネクターを Web サブシステムに追加し、ソケットバインディング名とプロトコルを必要なものに置き換えます。
      /subsystem=web/connector=ajp:add(socket-binding=ajp, protocol="AJP/1.3", enabled=true, scheme="http")
      Copy to Clipboard Toggle word wrap

17.5. クラスタリング

17.5.1. クラスタリングサブシステムに TCP 通信を使用

デフォルトでは、クラスターノードは UDP プロトコルを使用して相互のステータスを監視します。一部のネットワークでは TCP のみを使用できます。このような場合には、TCPPING プロトコルスタックを設定に追加し、デフォルトのメカニズムとして使用することができます。これらの設定オプションは、コマンドラインベースの管理 CLI で利用できます。
mod_cluster サブシステムはデフォルトで UDP 通信も使用し、ここで TCP を使用することも可能です。
ネットワーク通信に TCP を使用するには、次の 2 つの手順を参照して JGroups および mod_cluster サブシステムを設定します。

17.5.2. TCP を使用するよう JGroups サブシステムを設定

デフォルトでは、JGroups サブシステムはマルチキャスト UDP を使用して通信します。以下の手順に従って、代わりにユニキャスト TCP を使用するように JGroups サブシステムを設定します。
TCP も使用するように mod_cluster サブシステムを設定する場合は、mod_cluster サブシステムのアドバタイズの無効化」 を参照してください。
  1. お使いの環境に合わせて以下のスクリプトを変更します。

    以下のスクリプトをテキストエディターにコピーします。管理対象ドメインで別のプロファイルを使用する場合は、プロファイル名を変更します。スタンドアロンサーバーを使用する場合は、コマンドの /profile=full-ha の部分を削除します。以下のように、コマンドの下部に記載されているプロパティーを変更します。これらのプロパティーはそれぞれオプションです。
    initial_hosts
    よく知られており、最初のメンバーシップを検索するのに利用できる HOST[PORT] 構文を使用したホストのカンマ区切りのリスト。
    port_range
    必要に応じて、ポート範囲を割り当てることができます。ポート範囲を 2 に割り当て、ホストの初期ポートが 7600 である場合は、TCPPING はポート 7600-7602 のホストへの接続を試みます。ポート範囲は、initial_hosts で指定された各アドレスに適用されます。このプロパティーはオプションです。
    timeout
    クラスターメンバーの任意のタイムアウト値 (ミリ秒単位)
    num_initial_members
    クラスターが完了とみなされるまでのノード数。このプロパティーはオプションです。
    batch
    ##  If  tcp  is already added then you can remove it  ##
    /profile=full-ha/subsystem=jgroups/stack=tcp:remove
    /profile=full-ha/subsystem=jgroups/stack=tcp:add(transport={"type" =>"TCP", "socket-binding" => "jgroups-tcp"})
    /profile=full-ha/subsystem=jgroups/stack=tcp/:add-protocol(type=TCPPING)
    /profile=full-ha/subsystem=jgroups/stack=tcp/:add-protocol(type=MERGE2)
    /profile=full-ha/subsystem=jgroups/stack=tcp/:add-protocol(type=FD_SOCK,socket-binding=jgroups-tcp-fd)
    /profile=full-ha/subsystem=jgroups/stack=tcp/:add-protocol(type=FD)
    /profile=full-ha/subsystem=jgroups/stack=tcp/:add-protocol(type=VERIFY_SUSPECT)
    /profile=full-ha/subsystem=jgroups/stack=tcp/:add-protocol(type=BARRIER)
    /profile=full-ha/subsystem=jgroups/stack=tcp/:add-protocol(type=pbcast.NAKACK)
    /profile=full-ha/subsystem=jgroups/stack=tcp/:add-protocol(type=UNICAST2)
    /profile=full-ha/subsystem=jgroups/stack=tcp/:add-protocol(type=pbcast.STABLE)
    /profile=full-ha/subsystem=jgroups/stack=tcp/:add-protocol(type=pbcast.GMS)
    /profile=full-ha/subsystem=jgroups/stack=tcp/:add-protocol(type=UFC)
    /profile=full-ha/subsystem=jgroups/stack=tcp/:add-protocol(type=MFC)
    /profile=full-ha/subsystem=jgroups/stack=tcp/:add-protocol(type=FRAG2)
    /profile=full-ha/subsystem=jgroups/stack=tcp/:add-protocol(type=RSVP)
    /profile=full-ha/subsystem=jgroups:write-attribute(name=default-stack,value=tcp)
    run-batch
    /profile=full-ha/subsystem=jgroups/stack=tcp/protocol=TCPPING/property=initial_hosts/:add(value="HostA[7600],HostB[7600]")
    /profile=full-ha/subsystem=jgroups/stack=tcp/protocol=TCPPING/property=port_range/:add(value=0)
    /profile=full-ha/subsystem=jgroups/stack=tcp/protocol=TCPPING/property=timeout/:add(value=3000)
    /profile=full-ha/subsystem=jgroups/stack=tcp/protocol=TCPPING/property=num_initial_members/:add(value=3)
    Copy to Clipboard Toggle word wrap
  2. スクリプトをバッチモードで実行します。

    警告
    バッチファイルを実行する前に、プロファイルを実行しているサーバーをシャットダウンする必要があります。
    端末エミュレーターで、jboss-cli.sh スクリプトが含まれるディレクトリーに移動し、以下のコマンドを入力します。
    ./jboss-cli.sh -c --file=SCRIPT_NAME
    Copy to Clipboard Toggle word wrap
    SCRIPT_NAME は、スクリプトを含むパスの名前に置き換えます。

結果

TCPPING スタックが JGroups サブシステムで利用できるようになりました。これを使用すると、JGroups サブシステムはすべてのネットワーク通信に TCP を使用します。TCP も使用するように mod_cluster サブシステムを設定する場合は、mod_cluster サブシステムのアドバタイズの無効化」 を参照してください。

17.5.3. mod_cluster サブシステムのアドバタイズの無効化

デフォルトでは、mod_cluster サブシステムのバランサーはマルチキャスト UDP を使用して可用性をバックグラウンドワーカーにアドバタイズします。必要に応じて、アドバタイズメントを無効にできます。この動作を設定するには、以下の手順を使用します。

手順17.11

  1. Apache HTTP Server 設定を変更します。

    Apache HTTP Server 設定を変更し、サーバーのアドバタイズを無効にし、代わりにプロキシーリストを使用します。プロキシー一覧はワーカーで設定され、ワーカーが対話できるすべての mod_cluster対応 Web サーバーが含まれます。
    Web サーバーの mod_cluster 設定は HTTPD_HOME にあります。ファイル自体の詳細は、「Apache HTTP Server または JBoss Enterprise Web Server への mod_cluster モジュールのインストール (Zip)」 および 「mod_cluster が有効な Web サーバーに対するサーバーアドバタイズメントプロパティーの設定」 を参照してください。MCPM 要求をリッスンする仮想ホスト( EnableMCPMReceive ディレクティブを使用)が含まれるファイルを開き、以下のように ServerAdvertise ディレクティブを変更してサーバーのアドバタイズを無効にします。
    ServerAdvertise Off
    Copy to Clipboard Toggle word wrap
  2. JBoss EAP 6 の mod_cluster サブシステム内でアドバタイズを無効にし、プロキシーのリストを提供します。

    Web ベースの管理コンソールまたはコマンドライン管理 CLI を使用して、mod_cluster サブシステムのアドバタイズを無効にし、プロキシーのリストを提供できます。mod_cluster サブシステムはアドバタイズが無効になっているとプロキシーを自動的に検出できないため、プロキシーのリストが必要です。
    • 管理コンソール

      管理対象ドメインを使用する場合は、mod_cluster プロファイルや ha プロファイルなど、有効化されているプロファイルでのみ full-ha を設定できます。
      1. 管理コンソールにログインし、画面の上部にある Configuration タブを選択します。管理対象ドメインを使用する場合は、左上の Profile ドロップダウンメニューから ha または full-ha プロファイルを選択します。
      2. Subsystems メニューを展開し、Web メニューを展開し、mod_cluster を選択します。
      3. mod_clusterAdvertising タブで Edit をクリックします。アドバタイズを無効にするには、Advertise の横にあるチェックボックスの選択を解除し、Save をクリックします。

        図17.1 mod_cluster アドバタイズ設定画面

      4. プロキシー タブをクリックします。Edit をクリックし、Proxy List フィールドにプロキシーサーバーの一覧を入力します。正しい構文は、以下のような HOSTNAME:PORT 文字列のコンマ区切りリストです。
        10.33.144.3:6666,10.33.144.1:6666
        Copy to Clipboard Toggle word wrap
        Save ボタンをクリックして終了します。
    • 管理 CLI

      以下の 2 つの管理 CLI コマンドは、上記の管理コンソールの手順と同じ設定を作成します。ここでは、管理対象ドメインを実行し、サーバーグループが full-ha プロファイルを使用していることを仮定します。別のプロファイルを使用する場合は、コマンドで名前を変更します。standalone-ha プロファイルを使用してスタンドアロンサーバーを使用する場合は、コマンドの /profile=full-ha の部分を削除します。
      /profile=full-ha/subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=advertise,value=false)
      
      /profile=full-ha/subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=proxy-list,value="10.33.144.3:6666,10.33.144.1:6666")
      Copy to Clipboard Toggle word wrap

結果

Apache HTTP Server のバランサーがその存在をワーカーノードにアドバタイズしなくなり、UDP マルチキャストが使用されないようになります。

注記
属性 advertise="false" を設定するには、proxy-list="address:port" 属性も設定する必要があります。proxy-list 属性が空の場合、advertise="false" 属性は無視されます。mod_cluster サブシステムを完全に無効にするには、サーバー設定から削除します。

17.5.4. HornetQ クラスタリングの UDP の TCP への変更

以下の例では、EAP 6 に同梱されるデフォルトの standalone-full-ha.xml ファイルが使用されます。
注記
セキュリティーが有効になっている場合、cluster-password 属性を設定する必要があります。
<cluster-password>${jboss.messaging.cluster.password:ChangeMe>}</cluster-password>
Copy to Clipboard Toggle word wrap
  1. broadcast-groups および discovery-groups を削除します。

    <broadcast-groups>
        <broadcast-group name="bg-group1">
            <socket-binding>messaging-group</socket-binding>
            <broadcast-period>5000</broadcast-period>
            <connector-ref>netty</connector-ref>
        </broadcast-group>
    </broadcast-groups>
    <discovery-groups>
        <discovery-group name="dg-group1">
            <socket-binding>messaging-group</socket-binding>
            <refresh-timeout>10000</refresh-timeout>
        </discovery-group>
    </discovery-groups
    
    Copy to Clipboard Toggle word wrap
  2. "messaging-group" ソケットバインディングを削除します (任意設定)。

    <socket-binding name="messaging-group" port="0" multicast-address="${jboss.messaging.group.address:231.7.7.7}" multicast-port="${jboss.messaging.group.port:9876}"/>
    Copy to Clipboard Toggle word wrap
  3. 適切な Netty コネクターを設定します (クラスターの他のノードごとに 1 つ)。

    たとえば、クラスターが 3 ノードの場合は 2 つの Netty コネクターを設定し、クラスターが 2 ノードの場合は 1 つの Netty コネクターを設定します。3 ノードクラスターの設定例を以下に示します。
    <netty-connector name="other-cluster-node1" socket-binding="other-cluster-node1"/>
    <netty-connector name="other-cluster-node2" socket-binding="other-cluster-node2"/>
    Copy to Clipboard Toggle word wrap
  4. 関連するソケットバインディングを設定します。

    注記
    必要な場合は、host または port に対してシステムプロパティーの置換を使用できます。
    <outbound-socket-binding name="other-cluster-node1">
        <remote-destination host="otherNodeHostName1" port="5445"/>
    </outbound-socket-binding>
    <outbound-socket-binding name="other-cluster-node2">
        <remote-destination host="otherNodeHostName2" port="5445"/>
    </outbound-socket-binding>
    Copy to Clipboard Toggle word wrap
  5. デフォルトで使用される discovery-group の代わりに、これらのコネクターを使用する cluster-connection を設定します。

    <cluster-connection name="my-cluster">
        <address>jms</address>
        <connector-ref>netty</connector-ref>
        <static-connectors>
            <connector-ref>other-cluster-node1</connector-ref>
            <connector-ref>other-cluster-node2</connector-ref>
        </static-connectors>
    </cluster-connection>
    Copy to Clipboard Toggle word wrap
    各ノードが、クラスターの他のノードすべて対してコネクターを持つように、この処理を各クラスターノードで繰り返す必要があります。
    注記
    ノード自体への接続を設定しないでください。これは、設定が間違っていると見なされます。

17.6. Web、HTTP コネクター、および HTTP クラスタリング

17.6.1. mod_cluster HTTP コネクター

mod_cluster モジュールは負荷分散を有効にし、コネクター と呼ばれます。他のコネクターについては、以下のいずれかを参照してください。
他のコネクターと比べて mod_cluster コネクターには複数の利点があります。
  • mod_cluster Management Protocol (MCMP)は、JBoss Enterprise Application Platform 6 サーバーと mod_cluster モジュールが有効になっている Apache HTTP Server との間の追加接続です。HTTP メソッドのカスタムセットを使用してサーバー側の負荷分散係数およびライフサイクルイベントを Apache HTTP Server サーバーに返信するために JBoss Enterprise Application Platform サーバーによって使用されます。
  • mod_cluster がある Apache HTTP Server を動的に設定すると、手動で設定せずに JBoss EAP 6 サーバーが負荷分散配置に参加できます。
  • JBoss EAP 6 は、mod_cluster を使用する Apache HTTP Server に依存せずに負荷分散係数の計算を行います。これにより、負荷分散メトリックが他のコネクターよりも正確になります。
  • mod_cluster コネクターにより、アプリケーションライフサイクルを細かく制御できるようになります。各 JBoss EAP 6 サーバーは Web アプリケーションコンテキストライフサイクルイベントを Apache HTTP Server に転送するため、特定のコンテキストのルーティングリクエストを開始または停止するよう通知します。これにより、リソースを使用できないことが原因の HTTP エラーがエンドユーザーに表示されないようになります。
  • AJP、HTTP、または HTTPS トランスポートを使用できます。

17.6.2. mod_cluster サブシステムの設定

mod_cluster サブシステムは、管理コンソールおよび管理 CLI を使用して設定できます。このトピックでは、管理コンソールに表示されるさまざまな設定オプションについて説明します。各オプションの管理 CLI コマンドの例が提供されます。
注記
mod_cluster 設定ページは、ha プロファイルと full- ha プロファイルでのみ表示されます。管理対象ドメインの場合、これらのプロファイルは ha および full-ha で、スタンドアロンサーバーの場合は standalone-ha および standalone-full-ha になります。

管理コンソール

Configuration タブをクリックします。管理対象ドメインを設定する場合は、Profile ドロップダウンリストから正しいプロファイルを選択します。Subsystems メニューを展開し、Web メニューを展開し、mod_cluster を選択します。

Expand
表17.8 mod_cluster アドバタイズの設定オプション
オプション 説明 CLI コマンド
負荷分散グループ (Load Balancing Group)
null でない場合、要求はロードバランサーの特定の負荷分散グループに送信されます。ロードバランシンググループを使用しない場合は、空欄のままにします。これは、デフォルトでは未設定です。
/subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=load-balancing-group,value=myGroup)
Copy to Clipboard Toggle word wrap
バランサー (Balancer)
この属性は、Apache HTTP Server の mod_cluster により自動的に設定される mod_proxy バランサーを指定します。デフォルトは none です。この場合、mycluster のデフォルトが使用されます(mod_proxy 用語で表される場合はbalancer://mycluster/ )。このデフォルト値は、ManagerBalancerName ディレクティブで Apache HTTP Server 側で設定されます。
JBoss EAP 6 のワーカーインスタンスで 2 つの異なる balancer 属性値を使用する場合、Apache HTTP Server で mod_cluster によって自動的に作成される 2 つの異なる mod_proxy バランサーがあります。
/subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=balancer,value=myBalancer)
Copy to Clipboard Toggle word wrap
ソケットのアドバタイズ (Advertise Socket)
クラスターのアドバタイズに使用するソケットバインディングの名前です。
/subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=advertise-socket,value=modcluster)
Copy to Clipboard Toggle word wrap
セキュリティーキーのアドバタイズ (Advertise Security Key)
アドバタイズのセキュリティーキーが含まれる文字列。
/subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=advertise-security-key,value=myKey)
Copy to Clipboard Toggle word wrap
アドバタイズ (Advertise)
アドバタイズを有効にするかどうか。デフォルトは true です。
/subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=advertise,value=true)
Copy to Clipboard Toggle word wrap
Expand
表17.9 mod_cluster セッション設定オプション
オプション 説明 CLI コマンド
スティッキーセッション (Sticky Session)
リクエストにスティッキーセッションを使用するかどうか。つまり、クライアントが特定のノードに接続すると、利用不可能でない限り、追加の通信が同じノードにルーティングされます。デフォルトは true で、推奨される設定です。
/subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=sticky-session,value=true)
Copy to Clipboard Toggle word wrap
スティッキーセッションの強制 (Sticky Session Force)
true の場合、最初のノードが利用できなくなりますが、失敗すると、リクエストは新しいノードにリダイレクトされません。デフォルトは false です。
/subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=sticky-session-force,value=false)
Copy to Clipboard Toggle word wrap
スティッキーセッションの削除 (Sticky Session Remove)
フェイルオーバー時にセッション情報を削除します。デフォルトは false です。
/subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=sticky-session-remove,value=false)
Copy to Clipboard Toggle word wrap
Expand
表17.10 mod_cluster Web コンテキスト設定オプション
オプション 説明 CLI コマンド
コンテキストの自動有効化 (Auto Enable Contexts)
デフォルトで新しいコンテキストを mod_cluster に追加するかどうか。デフォルトは true です。デフォルトを変更し、コンテキストを手動で有効にする必要がある場合、Web アプリケーションは enable() MBean メソッドを使用するか、mod_cluster マネージャーを使用してコンテキストを有効にできます。これは、httpd の設定に指定される名前付き仮想ホストまたはポートで httpd プロキシーで実行される Web アプリケーションです。
/subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=auto-enable-contexts,value=true)
Copy to Clipboard Toggle word wrap
除外されたコンテキスト (Excluded Contexts)
mod_cluster が無視すべきコンテキストのコンマ区切りリスト。ホストが指定されていない場合、ホストは localhost であると想定されます。ROOT Web アプリケーションのルートコンテキストを示します。デフォルト値は ROOT,invoker,jbossws,juddi,console です。
/subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=excluded-contexts,value="ROOT,invoker,jbossws,juddi,console")
Copy to Clipboard Toggle word wrap
Expand
表17.11 mod_cluster プロキシー設定オプション
オプション 説明 CLI コマンド
プロキシー URL
定義された場合、この値は MCMP コマンドの URL の前に付加されます。
/subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=proxy-url,value=myhost)
Copy to Clipboard Toggle word wrap
プロキシリスト (Proxy List)
hostname:port 形式の httpd プロキシーアドレスのコンマ区切りリスト。これは、mod_cluster プロセスが最初の通信を試みるプロキシーのリストを示します。
/subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=proxy-list,value="127.0.0.1,127.0.0.2")
Copy to Clipboard Toggle word wrap

SSL 通信の設定 mod_cluster

デフォルトでは、mod_cluster 通信は暗号化されていない HTTP リンク上で行われます。コネクタースキームを HTTPS に設定すると( 表17.9「mod_cluster セッション設定オプション」を参照)、以下の設定は、接続を暗号化する情報を見つける場所を mod_cluster に指示します。

Expand
表17.12 mod_cluster SSL 設定オプション
オプション 説明 CLI コマンド
キーエイリアス (Key Alias)
証明書が作成されたときに選択されたキーエイリアス。
/subsystem=modcluster/mod-cluster-config=configuration/ssl=configuration/:write-attribute(name=key-alias,value=jboss)
Copy to Clipboard Toggle word wrap
パスワード
このパスワードは、certificate-key-file(Key File)と ca-certificate-file(Cert File)の両方のキーストアパスワードで、Cert File 内の Key Alias で指定するキー/証明書エントリーの両方です。
注記
@CA-certificate-password はトラストストアのパスワードであり、指定がない場合は値は undefined のままになります。
/subsystem=modcluster/mod-cluster-config=configuration/ssl=configuration/:write-attribute(name=password,value=changeit)
Copy to Clipboard Toggle word wrap
CA 証明書ファイル/トラストストア
Web サーバー証明書の検証に使用されるトラストストア。
/subsystem=modcluster/mod-cluster-config=configuration/ssl=configuration/:write-attribute(name=ca-certificate-file,value=${user.home}/jboss.crt)
Copy to Clipboard Toggle word wrap
キーストア (Key Store)
このインスタンスを識別する証明書および秘密鍵を保持するキーストア。
/subsystem=modcluster/mod-cluster-config=configuration/ssl=configuration/:write-attribute(name=certificate-key-file,value=${user.home}/.keystore)
Copy to Clipboard Toggle word wrap
暗号スイート (Cipher Suite)
許可された暗号スイート。
/subsystem=modcluster/mod-cluster-config=configuration/ssl=configuration/:write-attribute(name=cipher-suite,value=ALL)
Copy to Clipboard Toggle word wrap
失効 URL (Revocation URL)
証明局失効リストの URL。
/subsystem=modcluster/mod-cluster-config=configuration/ssl=configuration/:write-attribute(name=ca-revocation-url,value=jboss.crl)
Copy to Clipboard Toggle word wrap
プロトコル
有効 な SSL プロトコル。
また、プロトコルの組み合わせ(コンマ区切り)を指定することもできます。例: TLSv1、TLSv1.1、TLSv1.2
警告
Red Hat は、影響を受けるすべてのパッケージで TLSv1.1 または TLSv1.2 を利用するために SSL を明示的に無効にすることを推奨します。
/subsystem=modcluster/mod-cluster-config=configuration/ssl=configuration/:write-attribute(name=protocol,value="TLSv1, TLSv1.1,TLSv1.2")
Copy to Clipboard Toggle word wrap

mod_cluster ネットワーク設定

利用可能な mod_cluster ネットワークオプションは、mod_cluster サービスが通信するさまざまなタイプのサービスに対して、さまざまなタイムアウト動作を制御します。

Expand
表17.13 mod_cluster ネットワーク設定オプション
オプション 説明 CLI コマンド
ノードタイムアウト (Node Timeout)
ワーカーへのプロキシー接続のタイムアウト (秒単位)。mod_cluster はこの期間バックエンド応答を待ち、その経過後にエラーを返します。node-timeout 属性が未定義の場合は、httpd ProxyTimeout ディレクティブが使用されます。ProxyTimeout が定義されていない場合は、httpd Timeout ディレクティブが使用されます。デフォルトは 300 秒です。
/subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=node-timeout,value=-1)
Copy to Clipboard Toggle word wrap
ソケットタイムアウト (Socket Timeout)
タイムアウトの前およびプロキシーをエラーのように警告する前に、httpd プロキシーから MCMP コマンドへの応答を待つ秒数。
/subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=socket-timeout,value=20)
Copy to Clipboard Toggle word wrap
停止コンテキストタイムアウト (Stop Context Timeout)
コンテキストがクリーンにシャットアウトされるまでの、stopContextTimeoutUnit で指定された単位の時間 (配布可能なコンテキストに対する保留中の要求の完了、または配布可能でないコンテキストに対するアクティブなセッションの破棄/期限切れ)。
/subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=stop-context-timeout,value=10)
Copy to Clipboard Toggle word wrap
セッション排出ストラテジ (Session Draining Strategy)
Web アプリケーションをアンデプロイする前にセッションを排出 (drain) するかどうか。
DEFAULT
web アプリケーションが分散可能でない場合のみ、web アプリケーションのアンデプロイ前にセッションをドレインします。
ALWAYS
web アプリケーションが分散可能であっても、web アプリケーションのアンデプロイ前に常にセッションをドレインします。
NEVER
Web アプリケーションをアンデプロイする前にセッションを排出 (drain) しません (配布不可能な Web アプリケーションを含む)。
/subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=session-draining-strategy,value=DEFAULT)
Copy to Clipboard Toggle word wrap
最大試行回数 (Max Attempts)
httpd プロキシーがノードに対して指定のリクエストの送信を試みる回数。この回数試行してから停止します。最小値は 1 で、1 回のみ試行します。mod_proxy のデフォルト値は 1 でもあるため、再試行は行われません。
/subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=max-attempts,value=1)
Copy to Clipboard Toggle word wrap
パケットのフラッシュ (Flush Packets)
Web サーバーへのパケットのフラッシュを有効にするかどうか。デフォルトは false です。
/subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=flush-packets,value=false)
Copy to Clipboard Toggle word wrap
フラッシュの待機 (Flush Wait)
Web サーバーにパケットをフラッシュするまでの待機時間(秒単位)。デフォルトは -1 です。- 1 を値として指定すると、パケットをフラッシュする前に永久に待機します。
/subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=flush-wait,value=-1)
Copy to Clipboard Toggle word wrap
Ping
ワーカーからの ping への応答を待つ時間(秒単位)。デフォルトは 10 秒です。
/subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=ping,value=10)
Copy to Clipboard Toggle word wrap
SMAX
ソフト最大アイドル接続数(mod_proxy ドキュメントでは smax と同じ)。最大値は httpd スレッド設定によって異なり、ThreadsPerChild または 1 のいずれかになります。
profile=full-ha/subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=smax,value=ThreadsPerChild)
Copy to Clipboard Toggle word wrap
TTL
smax より上のアイドル接続の残存時間 (秒数単位)。デフォルト値は 60 です。
/subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=ttl,value=-1)
Copy to Clipboard Toggle word wrap

mod_cluster Load Provider 設定オプション

以下の mod_cluster 設定オプションは管理コンソールでは使用できませんが、管理 CLI を使用してのみ設定できます。

動的ロードプロバイダーが存在しない場合には、単純なロードプロバイダーが使用されます。各クラスターメンバーに負荷係数 1 を割り当て、負荷分散アルゴリズムを適用せずに作業を均等に分散します。これを追加するには、以下の管理 CLI コマンドを使用します。
[standalone@localhost:9990 /] /subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=simple-load-provider, value=1)
Copy to Clipboard Toggle word wrap
次のリクエストを受信するワーカーを決定するために、動的ロードプロバイダーはさまざまなアルゴリズムの組み合わせを使用するように設定できます。ロードプロバイダーを作成してお使いの環境に合わせて設定できます。また、CLI で複数の負荷メトリクスを同時に追加することで、同時に複数の負荷メトリックをアクティブにすることができます。デフォルトの動的ロードプロバイダーは負荷メトリックの決定にビジー状態を使用します。動的ロードプロバイダーオプションと可能な負荷メトリックを以下に示します。
Expand
表17.14 mod_cluster 動的ロードプロバイダーオプション
オプション 説明 CLI コマンド
衰退 (Decay)
履歴メトリックの重要性が衰退すべき要因。
/subsystem=modcluster/mod-cluster-config=configuration/dynamic-load-provider=configuration/:write-attribute(name=decay,value=2)
Copy to Clipboard Toggle word wrap
履歴
負荷を決定するときに考慮する、負荷メトリックの履歴記録数。
/subsystem=modcluster/mod-cluster-config=configuration/dynamic-load-provider=configuration/:write-attribute(name=history,value=9)
Copy to Clipboard Toggle word wrap
負荷メトリック (Load Metric)
JBoss EAP 6 の動的ロードプロバイダーに含まれるデフォルトの負荷メトリックはビジー状態であり、リクエストに対応するスレッドプールのスレッド数からワーカーの負荷を計算します。実際の負荷を分割するこのメトリックの容量を設定できます(calculated_load / capacity)。動的ロードプロバイダー内に複数の負荷メトリクスを設定できます。
/subsystem=modcluster/mod-cluster-config=configuration/dynamic-load-provider=configuration/load-metric=busyness/:write-attribute(name=capacity,value=1.0)
Copy to Clipboard Toggle word wrap
/subsystem=modcluster/mod-cluster-config=configuration/dynamic-load-provider=configuration/load-metric=busyness/:write-attribute(name=type,value=busyness)
Copy to Clipboard Toggle word wrap
/subsystem=modcluster/mod-cluster-config=configuration/dynamic-load-provider=configuration/load-metric=busyness/:write-attribute(name=weight,value=1)
Copy to Clipboard Toggle word wrap

負荷メトリックアルゴリズム

cpu
cpu 負荷メトリックは、CPU 負荷の平均を使用して次のワークロードを取得するノードを決定します。
mem
mem 負荷メトリックは、空きネイティブメモリーを負荷メトリックとして使用します。このメトリクスの使用は推奨されません。これはバッファーやキャッシュを含む値を提供するため、メモリー管理が良いすべてのシステムにおいて非常に低い値になります。
heap
ヒープ 負荷メトリックは、ヒープ使用率を使用して次のワークロードを取得するワーカーを決定します。
セッション
セッション 負荷メトリックは、アクティブなセッションの数をメトリックとして使用します。
requests
要求 負荷メトリックは、クライアント要求の数を使用して次のワークロードを受け取るワーカーを決定します。たとえば、容量 1000 は、1000 要求/秒がフルロードであると見なされます。
send-traffic
send-traffic 負荷メトリックは、ワーカーからクライアントに送信されるトラフィックの量を使用します。たとえば、デフォルトの容量が 512 の場合は、平均送信トラフィックが 512 KB/秒以上である場合に、ノードがフルロードであると見なされます。
receive-traffic
receive-traffic 負荷メトリックは、クライアントからワーカーに送信されるトラフィックの量を使用します。たとえば、デフォルトの容量が 1024 の場合は、平均受信トラフィックが 1024 KB/秒以上である場合にワーカーがフルロードであると見なされます。
busyness
このメトリックは、要求の処理で負荷が大きいスレッドプールからのスレッドの量を表します。

例17.2 負荷メトリックの追加

負荷メトリックを追加するには、add-metric コマンドを使用します。
/subsystem=modcluster/mod-cluster-config=configuration/:add-metric(type=sessions)
Copy to Clipboard Toggle word wrap

例17.3 既存メトリックの値設定

既存のメトリックの値を設定するには、write-attribute コマンドを使用します。
/subsystem=modcluster/mod-cluster-config=configuration/dynamic-load-provider=configuration/load-metric=cpu/:write-attribute(name="weight",value="3")
Copy to Clipboard Toggle word wrap

例17.4 既存メトリックの値変更

既存のメトリックの値を変更するには、write-attribute コマンドを使用します。
/subsystem=modcluster/mod-cluster-config=configuration/dynamic-load-provider=configuration/load-metric=cpu/:write-attribute(name="type",value="busyness")
Copy to Clipboard Toggle word wrap

例17.5 既存メトリックの削除

既存のメトリックを削除するには、remove-metric コマンドを使用します。
/subsystem=modcluster/mod-cluster-config=configuration/:remove-metric(type=sessions)
Copy to Clipboard Toggle word wrap

前提条件

  • このタスクを実行するには、Red Hat Enterprise Linux 6 または JBoss Enterprise Web Server にインストールされた Apache HTTP Server を使用するか、JBoss EAP 6 のダウンロード可能な個別コンポーネントとして含まれるスタンドアロン Apache HTTP Server を使用する必要があります。
  • Red Hat Enterprise Linux 6 に Apache HTTP Server をインストールする必要がある場合は、『 『Red Hat Enterprise Linux 6 デプロイメントガイド』』 に記載された手順を実行します。
  • JBoss EAP 6 の個別のダウンロード可能なコンポーネントとして含まれるスタンドアロンの Apache HTTP Server をインストールする必要がある場合は、「Red Hat Enterprise Linux 5、6、7 への Apache HTTP Server のインストール(Zip)」 を参照してください。
  • JBoss Enterprise Web Server をインストールする必要がある場合は、『JBoss Enterprise Web Server インストールガイド』 に記載された手順を実行します。
  • Red Hat カスタマーポータル( https://access.redhat.com )から、お使いのオペレーティングシステムおよびアーキテクチャー用の Webserver Connecter Natives パッケージをダウンロードします。このパッケージには、お使いのオペレーティングシステム用に事前にコンパイルされた mod_cluster バイナリー Web サーバーモジュールが含まれます。アーカイブを抽出した後に、モジュールは EAP_HOME/modules/system/layers/base/native/lib/httpd/modules ディレクトリーにあります。
    etc/ ディレクトリーには設定ファイルのサンプルが含まれ、share/ ディレクトリーには補足ドキュメントがいくつか含まれています。
  • 管理 (root) 権限を使用してログインする必要があります。
備考
64 ビットシステムを使用する場合、mod_cluster バイナリー web サーバーモジュールは EAP_HOME/modules/system/layers/base/native/lib64/httpd/modules に配置されます。モジュールへのアクセスが必要な場合は、このパスを使用する必要があります。

手順17.12 mod_cluster モジュールのインストール

  1. Apache HTTP Server の設定場所を判断します。

    Apache HTTP Server の設定場所は、Red Hat Enterprise Linux の Apache HTTP Server を使用しているか、JBoss EAP 6 でダウンロード可能な個別コンポーネントとして含まれるスタンドアロン Apache HTTP Server を使用しているか、JBoss Enterprise Web Server で利用可能な Apache HTTP Server を使用しているかによって異なります。これは、以下の 3 つのオプションの 1 つであり、このタスクの残りの部分では HTTPD_HOME と呼ばれます。
    • Apache HTTP Server - /etc/httpd/
    • JBoss EAP 6 Apache HTTP Server - この場所はインフラストラクチャーの要件に基づいてユーザーによって選択されます。
    • JBoss Enterprise Web Server Apache HTTP Server - EWS_HOME/httpd/
  2. モジュールを Apache HTTP Server モジュールディレクトリーにコピーします。

    4 つのモジュール( .soで終わるファイル)を、展開された Webserver Natives アーカイブの EAP_HOME/modules/system/layers/base/native/lib/httpd/modules ディレクトリーから HTTPD_MODULES/ ディレクトリーにコピーします。
  3. JBoss Enterprise Web Server の場合は、mod_proxy_balancer モジュールを無効にします。

    JBoss Enterprise Web Server を使用する場合、mod_proxy_balancer モジュールはデフォルトで有効になります。これは mod_cluster と互換性がありません。これを無効にするには、HTTPD_CONF/httpd.conf を編集し、モジュールを読み込む行の前に # (ハッシュ)記号を追加して以下の行をコメントアウトします。この行はコメントなしで表示され、以下のように表示されます。
    LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
    Copy to Clipboard Toggle word wrap
    # LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
    Copy to Clipboard Toggle word wrap
    ファイルを保存してから閉じます。
  4. mod_cluster モジュールを設定します。

    Webserver Natives アーカイブには、サンプルの mod_cluster.conf ファイル(EAP_HOME/modules/system/layers/base/native/etc/httpd/conf)が含まれます。このファイルはガイドとして使用するか、または編集して HTTPD_CONF.D/JBoss_HTTP.conf ファイルを作成します。
    注記
    JBoss_HTTP.conf という名前を使用することは、本書の任意の規則です。設定ファイルは、.conf 拡張子が conf.d/ ディレクトリーに保存されている場合、その名前に関係なく読み込まれます。
    以下を設定ファイルに追加します。
    LoadModule slotmem_module modules/mod_slotmem.so
    LoadModule manager_module modules/mod_manager.so
    LoadModule proxy_cluster_module modules/mod_proxy_cluster.so
    LoadModule advertise_module modules/mod_advertise.so
    
    Copy to Clipboard Toggle word wrap
    これにより、Apache HTTP Server は mod_cluster が機能するために必要なモジュールを自動的に読み込みます。
  5. プロキシサーバーリスナーを作成します。

    HTTPD_CONF.D/JBoss_HTTP.conf の編集を継続し、大文字の値を環境に適した値に置き換えて、以下の最低限の設定を追加します。
    Listen IP_ADDRESS:PORT
    <VirtualHost IP_ADDRESS:PORT>  
    	  <Location />
              Order deny,allow
              Deny from all
              Allow from *.MYDOMAIN.COM
    	  </Location>
    	  
    	  KeepAliveTimeout 60
    	  MaxKeepAliveRequests 0
    	  EnableMCPMReceive
    	  
    	  ManagerBalancerName mycluster
    	  ServerAdvertise On
    	  
    </VirtualHost>
    Copy to Clipboard Toggle word wrap
    これらのディレクティブは、IP_ADDRESS:PORT でリッスンする新しい仮想サーバーを作成し、MYDOMAIN.COM からの接続を許可し、mycluster という名前のバランサーとしてアドバタイズします。これらのディレクティブは、Apache Web Server のドキュメントに記載されています。ServerAdvertise ディレクティブおよび EnableMCPMReceive ディレクティブの詳細とサーバーアドバタイズの影響については、「mod_cluster が有効な Web サーバーに対するサーバーアドバタイズメントプロパティーの設定」 を参照してください。
    ファイルを保存して終了します。
  6. Apache HTTP サーバーを再起動します。

    Apache HTTP Server の再起動方法は、Red Hat Enterprise Linux の Apache HTTP Server を使用しているか、JBoss Enterprise Web Server に含まれる Apache HTTP Server を使用しているかによって異なります。以下の 2 つの方法のいずれかを選択します。
    • Red Hat Enterprise Linux 6 の Apache HTTP Server

      以下のコマンドを実行します。
      [root@host]# service httpd restart
      Copy to Clipboard Toggle word wrap
    • JBoss Enterprise Web Server の Apache HTTP Server

      JBoss Enterprise Web Server は、Red Hat Enterprise Linux と Microsoft Windows Server の両方で実行されます。Apache HTTP Server の再起動方法はそれぞれ異なります。
      • Red Hat Enterprise Linux

        Red Hat Enterprise Linux では、JBoss Enterprise Web Server は Apache HTTP Server をサービスとしてインストールします。Apache HTTP Server を再起動するには、以下の 2 つのコマンドを実行します。
        [root@host ~]# service httpd stop
        [root@host ~]# service httpd start
        Copy to Clipboard Toggle word wrap
      • Microsoft Windows Server

        コマンドプロンプトで以下のコマンドを管理権限で実行します。
        C:\> net stop httpd
        C:\> net start httpd
        Copy to Clipboard Toggle word wrap

結果

Apache HTTP Server がロードバランサーとして設定され、JBoss EAP 6 を実行している mod_cluster サブシステムを使用できるようになりました。JBoss EAP 6 が mod_cluster を認識するよう設定するには、「mod_cluster ワーカーノードの設定」 を参照してください。

前提条件

  • このタスクを実行するには、Red Hat Enterprise Linux 6 または JBoss Enterprise Web Server にインストールされた Apache HTTP Server を使用するか、JBoss EAP 6 のダウンロード可能な個別コンポーネントとして含まれるスタンドアロン Apache HTTP Server を使用する必要があります。
  • Red Hat Enterprise Linux 6 に Apache HTTP Server をインストールする必要がある場合は、『 『Red Hat Enterprise Linux 6 デプロイメントガイド』』 に記載された手順を実行します。
  • JBoss EAP 6 の個別のダウンロード可能なコンポーネントとして含まれるスタンドアロンの Apache HTTP Server をインストールする必要がある場合は、「Red Hat Enterprise Linux 5、6、7 への Apache HTTP Server のインストール(Zip)」 を参照してください。
  • JBoss Enterprise Web Server をインストールする必要がある場合は、『JBoss Enterprise Web Server インストールガイド』 に記載された手順を実行します。
  • 管理 (root) 権限を使用してログインする必要があります。
  • jbappplatform-6-ARCH-server-VERS-rpm RHN チャンネルへのアクティブなサブスクリプションが必要です。
Red Hat Enterprise Linux 6 での RPM のインストール方法は、Red Hat Enterprise Linux 5 の場合とほぼ同様で、Red Hat Enterprise Linux 6 に Apache HTTP Server 2.2.15 がインストールされている場合は多少の変更のみが必要となります。
  1. YUM を使用して mod_cluster-native パッケージをインストールします。
    yum install mod_cluster-native
    
    Copy to Clipboard Toggle word wrap
  2. Apache HTTP Server:
    • Apache HTTP Server 2.2.15 の使用を継続する場合は、httpd.conf ファイルの LoadModule proxy_balancer_module 行をデフォルトで読み込む mod_proxy_balancer モジュールを無効にする必要があります。
      ファイルを手作業で編集するか、以下のコマンドを使用します。
      sed -i 's/^LoadModule proxy_balancer_module/#LoadModule proxy_balancer_module/;s/$//' /etc/httpd/conf/httpd.conf
      
      Copy to Clipboard Toggle word wrap
    • Apache HTTP Server 2.2.26 へアップグレードする場合は、以下のコマンドを使用して最新バージョンをインストールします。
      yum install httpd
      Copy to Clipboard Toggle word wrap
  3. ブート時に Apache HTTP Server サービスが起動するようにするには、以下のコマンドを実行します。
    • Red Hat Enterprise Linux 5 および 6 の場合:
      service httpd add
      Copy to Clipboard Toggle word wrap
    • Red Hat Enterprise Linux 7 の場合:
      systemctl enable httpd22.service
      Copy to Clipboard Toggle word wrap
  4. 以下のコマンドを使用して、mod_cluster バランサーを起動します。
    • Red Hat Enterprise Linux 5 および 6 の場合:
      service httpd start
      Copy to Clipboard Toggle word wrap
    • Red Hat Enterprise Linux 7 の場合:
      systemctl start httpd22.service
      Copy to Clipboard Toggle word wrap

概要

mod_cluster ロードバランサーと対話するように Web サーバーを設定する手順は、「Apache HTTP Server または JBoss Enterprise Web Server への mod_cluster モジュールのインストール (Zip)」 を参照してください。より詳細な説明が必要な設定の 1 つは、サーバーアドバタイズメント です。

サーバーのアドバタイズがアクティブになると、Web サーバーは mod_cluster 仮想ホストに指定された IP アドレスとポート番号を含むメッセージをブロードキャストします。これらの値を設定するには、「Apache HTTP Server または JBoss Enterprise Web Server への mod_cluster モジュールのインストール (Zip)」 を参照してください。UDP マルチキャストがネットワークで利用できない場合や、プロキシーサーバーの静的リストでワーカーを設定する場合は、サーバーのアドバタイズメントを無効にし、ワーカーノードを手動で設定することができます。ワーカーの設定に関する詳細は、「mod_cluster ワーカーノードの設定」 を参照してください。
この手順の変更は、Apache HTTP Server インスタンスに関連付けられた httpd.conf に追加する必要があります。多くの場合、Red Hat Enterprise Linux では /etc/httpd/conf/httpd.conf になります。または、スタンドアロンの Apache HTTP Server インスタンスの etc/ ディレクトリーにある場合があります。

手順17.13 httpd.conf ファイルを編集し、変更を実装する

  1. AdvertiseFrequency パラメーターを無効にします(存在する場合)。

    < VirtualHost > ステートメントに以下のような行がある場合は、最初の文字の前に # (ハッシュ)文字を置くことでコメントアウトします。値は 5 とは異なる場合があります。
    AdvertiseFrequency 5
    Copy to Clipboard Toggle word wrap
  2. サーバーアドバタイズメントを無効にするディレクティブを追加します。

    < VirtualHost> ステートメント内に以下のディレクティブを追加し て、サーバーのアドバタイズを無効にします。
    ServerAdvertise Off
    Copy to Clipboard Toggle word wrap
  3. MCPM メッセージの受信機能を有効にします。

    次のディレクティブを追加して、web サーバーがワーカーノードから MCPM メッセージを取得できるようにします。
    EnableMCPMReceive
    Copy to Clipboard Toggle word wrap
  4. Web サーバーを再起動します。

    以下のいずれかを実行して Web サーバーを再起動します。実行するコマンドは、Red Hat Enterprise Linux または Microsoft Windows Server を使用しているかによって異なります。
    • Red Hat Enterprise Linux

      [root@host ]# service httpd restart
      Copy to Clipboard Toggle word wrap
    • Microsoft Windows Server

      net stop Apache2.2
      net start Apache2.2
      
      Copy to Clipboard Toggle word wrap

結果

Web サーバーは mod_cluster プロキシーの IP アドレスとポートをアドバタイズしなくなりました。繰り返すには、ワーカーノードが静的アドレスおよびポートを使用してプロキシーと通信するように設定する必要があります。詳細は、「mod_cluster ワーカーノードの設定」 を参照してください。

17.6.6. mod_cluster ワーカーノードの設定

概要

mod_cluster ワーカーノードは、JBoss EAP 6 サーバーで構成されます。このサーバーは、管理対象ドメインまたはスタンドアロンサーバーのサーバーグループの一部にすることができます。個別のプロセスは JBoss EAP 6 内で実行され、クラスターのワーカーノードをすべて管理します。これはマスターと呼ばれます。ノードの概念の詳細については、「ノードのタイプ」 を参照してください。Web サーバーの負荷分散の概要は、「HTTP コネクターの概要」 を参照してください。

管理対象ドメインのワーカーノードは、サーバーグループ全体で同じ設定を共有します。スタンドアロンサーバーとして実行しているワーカーノードは個別に設定されます。設定手順は同じです。

ワーカーノード設定

  • スタンドアロンサーバーは standalone-ha または standalone-full-ha プロファイルで起動する必要があります。
  • 管理対象ドメインのサーバーグループは、ha または full-ha プロファイルを使用し、ha-sockets または full-ha-sockets ソケットバインディンググループを使用する必要があります。JBoss EAP 6 には、これらの要件を満たす other-server-group という名前のクラスター対応サーバーグループが同梱されます。
注記
管理 CLI コマンドを指定すると、管理対象ドメインが使用されることを前提としています。スタンドアロンサーバーを使用する場合は、コマンドの /profile=full-ha の部分を削除します。

手順17.14 ワーカーノードの設定

  1. ネットワークインターフェースの設定

    デフォルトでは、ネットワークインターフェースがすべて 127.0.0.1 に設定されます。スタンドアロンサーバーまたはサーバーグループ内の 1 つまたは複数のサーバーをホストする各物理ホストでは、インターフェースが他のサーバーが見つけることができるパブリック IP アドレスを使用するよう設定する必要があります。
    JBoss EAP 6 ホストの IP アドレスを変更するには、ホストをシャットダウンし、設定ファイルを直接編集する必要があります。これは、管理コンソールと管理 CLI を駆動する管理 API が安定した管理アドレスに依存するためです。
    クラスター内の各サーバーの IP アドレスをマスターのパブリック IP アドレスに変更するには、次の手順を実行します。
    1. 本トピックでこれまでに説明したプロファイルを使用して JBoss EAP サーバーを起動します。
    2. Linux の EAP_HOME/bin/jboss-cli.sh コマンド、Microsoft Windows Server では EAP_HOME\bin\jboss-cli.bat コマンドを使用して、管理 CLI を起動します。localhost 上のドメインコントローラーに 接続 するか、 IP_ADDRESSに接続 してリモートサーバーのドメインコントローラーに接続する場合は connect と入力します。
    3. 以下のコマンドを入力して、管理パブリック、および セキュアでない インターフェースの外部 IP アドレスを変更します。コマンドの EXTERNAL_IP_ADDRESS はホストの実際の外部 IP アドレスに置き換えてください。
      /interface=management:write-attribute(name=inet-address,value="${jboss.bind.address.management:EXTERNAL_IP_ADDRESS}"
      /interface=public:write-attribute(name=inet-address,value="${jboss.bind.address.public:EXTERNAL_IP_ADDRESS}"
      /interface=unsecure:write-attribute(name=inet-address,value="${jboss.bind.address.unsecure:EXTERNAL_IP_ADDRESS}"
      reload
      Copy to Clipboard Toggle word wrap
      各コマンドに対して以下のような結果が表示されるはずです。
       "outcome" => "success"
      Copy to Clipboard Toggle word wrap
    4. 管理対象ドメインに参加し、マスターではないホストの場合、ホスト名を master から一意の名前に変更する必要があります。この名前はスレーブ全体で一意になる必要があり、スレーブがクラスターを識別するために使用されるため、使用する名前を覚えておくようにしてください。
      1. 以下の構文を使用して、JBoss EAP スレーブホストを起動します。
        bin/domain.sh --host-config=HOST_SLAVE_XML_FILE_NAME
        Copy to Clipboard Toggle word wrap
        以下に例を示します。
        bin/domain.sh --host-config=host-slave01.xml
        Copy to Clipboard Toggle word wrap
      2. 管理 CLI を起動します。
      3. 以下の構文を使用してホスト名を置き換えます。
        /host=master:write-attribute(name="name",value=UNIQUE_HOST_SLAVE_NAME)
        Copy to Clipboard Toggle word wrap
        以下に例を示します。
        /host=master:write-attribute(name="name",value="host-slave01")
        Copy to Clipboard Toggle word wrap
        以下の結果が表示されるはずです。
         "outcome" => "success"
        Copy to Clipboard Toggle word wrap
        これにより、host-slave01.xml ファイルの XML が以下のように変更されます。
        <host name="host-slave01" xmlns="urn:jboss:domain:1.6">
        Copy to Clipboard Toggle word wrap
    5. 新たに設定されたホストが管理対象ドメインに参加する必要がある場合は、local 要素を削除し、ドメインコントローラーを示す remote 要素 host 属性を追加する必要があります。このステップはスタンドアロンサーバーには適用されません。
      1. 以下の構文を使用して、JBoss EAP スレーブホストを起動します。
        bin/domain.sh --host-config=HOST_SLAVE_XML_FILE_NAME
        Copy to Clipboard Toggle word wrap
        以下に例を示します。
        bin/domain.sh --host-config=host-slave01.xml
        Copy to Clipboard Toggle word wrap
      2. 管理 CLI を起動します。
      3. 次の構文を使用してドメインコントローラーを指定します。
        /host=UNIQUE_HOST_SLAVE_NAME/:write-remote-domain-controller(host=DOMAIN_CONTROLLER_IP_ADDRESS,port=${jboss.domain.master.port:9999},security-realm="ManagementRealm") 
        Copy to Clipboard Toggle word wrap
        以下に例を示します。
        /host=host-slave01/:write-remote-domain-controller(host="192.168.1.200",port=${jboss.domain.master.port:9999},security-realm="ManagementRealm") 
        Copy to Clipboard Toggle word wrap
        以下の結果が表示されるはずです。
         "outcome" => "success"
        Copy to Clipboard Toggle word wrap
        これにより、host-slave01.xml ファイルの XML が以下のように変更されます。
        <domain-controller>
            <remote host="192.168.1.200" port="${jboss.domain.master.port:9999}" security-realm="ManagementRealm"/>
        </domain-controller>
        Copy to Clipboard Toggle word wrap
  2. 各スレーブサーバーの認証を設定します。

    各スレーブサーバーには、ドメインコントローラーまたはスタンドアロンマスターの ManagementRealm で作成されたユーザー名とパスワードが必要です。ドメインコントローラーまたはスタンドアロンマスターで、EAP_HOME/bin/add-user.sh コマンドを実行します。スレーブと同じユーザー名を持つユーザーを ManagementRealm に追加します。このユーザーが外部 JBoss EAP 6 インスタンスに対して認証する必要があるかどうかを尋ねられたら、yes と回答します。以下は、slave1 と呼ばれるスレーブの password changeme と出力の例です。
    user:bin user$ ./add-user.sh
    
    What type of user do you wish to add? 
     a) Management User (mgmt-users.properties) 
     b) Application User (application-users.properties)
    (a): a
    
    Enter the details of the new user to add.
    Realm (ManagementRealm) : 
    Username : slave1
    Password : changeme
    Re-enter Password : changeme
    About to add user 'slave1' for realm 'ManagementRealm'
    Is this correct yes/no? yes
    Added user 'slave1' to file '/home/user/jboss-eap-6.0/standalone/configuration/mgmt-users.properties'
    Added user 'slave1' to file '/home/user/jboss-eap-6.0/domain/configuration/mgmt-users.properties'
    Is this new user going to be used for one AS process to connect to another AS process e.g. slave domain controller?
    yes/no? yes
    To represent the user add the following to the server-identities definition <secret value="Y2hhbmdlbWU=" />
    
    Copy to Clipboard Toggle word wrap
  3. <secret> 出力から Base64 でエンコードされた add-user.sh 要素をコピーします。

    認証に Base64 でエンコードされたパスワード値を指定する予定がある場合は、以下の手順で必要なように、<secret> 出力の最後の行から add-user.sh 要素の値をコピーします。
  4. 新しい認証を使用するようスレーブホストのセキュリティーレルムを変更します。

    以下の方法の 1 つを用いて秘密の値を指定できます。
    • 管理 CLI を使用して、サーバー設定ファイルに Base64 でエンコードされたパスワード値を指定します。

      1. Linux の EAP_HOME/bin/jboss-cli.sh コマンド、Microsoft Windows Server では EAP_HOME\bin\jboss-cli.bat コマンドを使用して、管理 CLI を起動します。localhost 上のドメインコントローラーに 接続 するか、 IP_ADDRESSに接続 してリモートサーバーのドメインコントローラーに接続する場合は connect と入力します。
      2. 以下のコマンドを入力して秘密の値を指定します。SECRET_VALUE は、直前の手順の add-user 出力から返された秘密の値に置き換えてください。
        /host=master/core-service=management/security-realm=ManagementRealm/server-identity=secret:add(value="SECRET_VALUE") 
        reload --host=master
        Copy to Clipboard Toggle word wrap
        各コマンドに対して以下のような結果が表示されるはずです。
         "outcome" => "success"
        Copy to Clipboard Toggle word wrap
    • ホストを設定し、vault よりパスワードを取得します。

      1. vault.sh スクリプトを使用してマスクされたパスワードを生成します。VAULT::secret::password::ODVmYmJjNGMtZDU2ZC00YmNlLWE4ODMtZjQ1NWNmNDU4ZDc1TElORV9CUkVBS3ZhdWx0 のような文字列が生成されます。
        パスワード vault の詳細は、セキュリティー 『アーキテクチャー』 およびその他の JBoss EAP セキュリティードキュメントを参照してください。
      2. Linux の EAP_HOME/bin/jboss-cli.sh コマンド、Microsoft Windows Server では EAP_HOME\bin\jboss-cli.bat コマンドを使用して、管理 CLI を起動します。localhost 上のドメインコントローラーに 接続 するか、 IP_ADDRESSに接続 してリモートサーバーのドメインコントローラーに接続する場合は connect と入力します。
      3. 以下のコマンドを入力して秘密の値を指定します。SECRET_VALUE は、必ず前のステップで生成したマスクされたパスワードに置き換えてください。
        /host=master/core-service=management/security-realm=ManagementRealm/server-identity=secret:add(value="${VAULT::secret::password::SECRET_VALUE}") 
        reload --host=master
        Copy to Clipboard Toggle word wrap
        各コマンドに対して以下のような結果が表示されるはずです。
         "outcome" => "success"
        Copy to Clipboard Toggle word wrap
        注記
        vault でパスワードを作成する場合、Base64 エンコードではなくプレーンテキストで指定する必要があります。
    • システムプロパティーとしてパスワードを指定します。

      次の例は、server.identity.password をパスワードのシステムプロパティー名として使用します。
      1. 管理 CLI を使用してサーバー設定ファイルにパスワードのシステムプロパティーを指定します。
        1. Linux の EAP_HOME/bin/jboss-cli.sh コマンド、Microsoft Windows Server では EAP_HOME\bin\jboss-cli.bat コマンドを使用して、管理 CLI を起動します。localhost 上のドメインコントローラーに 接続 するか、 IP_ADDRESSに接続 してリモートサーバーのドメインコントローラーに接続する場合は connect と入力します。
        2. 以下のコマンドを入力し、システムプロパティーを使用する秘密のアイデンティティーを設定します。
          /host=master/core-service=management/security-realm=ManagementRealm/server-identity=secret:add(value="${server.identity.password}") 
          reload --host=master
          Copy to Clipboard Toggle word wrap
          各コマンドに対して以下のような結果が表示されます。
           "outcome" => "success"
          Copy to Clipboard Toggle word wrap
      2. システムプロパティーとしてパスワードを指定する場合、次の方法のいずれかを用いてホストを設定できます。
        • 次の例のように、プレーンテキストのパスワードをコマンドライン引数として入力し、サーバーを起動します。
          -Dserver.identity.password=changeme
          Copy to Clipboard Toggle word wrap
          注記
          パスワードはプレーンテキストで入力する必要があります。ps -ef コマンドを実行すると、パスワードを確認できます。
        • パスワードをプロパティーファイルに格納し、プロパティーファイルの URL をコマンドライン引数として渡します。
          1. キーと値のペアをプロパティーファイルに追加します。以下に例を示します。
            server.identity.password=changeme
            Copy to Clipboard Toggle word wrap
          2. コマンドライン引数を用いてサーバーを起動します。
            --properties=URL_TO_PROPERTIES_FILE
            Copy to Clipboard Toggle word wrap
            .
  5. サーバーを再起動します。

    ホスト名をユーザー名として使用し、暗号化された文字列をパスワードとして使用してスレーブがマスターに対して認証されます。

結果

スタンドアロンサーバーまたは管理対象ドメインのサーバーグループ内のサーバーが mod_cluster ワーカーノードとして設定されます。クラスター化されたアプリケーションをデプロイする場合、セッションはフェイルオーバーのためにすべてのクラスターノードに複製され、外部 Web サーバーまたはロードバランサーからのリクエストを許可できます。クラスターの各ノードは、デフォルトで自動検出を使用して他のノードを検出します。自動検出や mod_cluster サブシステムのその他の固有の設定を設定するには、mod_cluster サブシステムの設定」 を参照してください。Apache HTTP Server を設定するには、「外部 Web サーバーを JBoss EAP 6 アプリケーションの Web フロントエンドとして使用」 を参照してください。

17.6.7. クラスター間のトラフィックの移行

概要

JBoss EAP 6 を使用して新しいクラスターを作成した後、アップグレードプロセスの一部として以前のクラスターから新しいクラスターへトラフィックを移行できます。ここでは、停止時間やダウンライムを最小限に抑えてトラフィックを移行する方法について説明します。

前提条件

  • 新しいクラスターの設定: mod_cluster サブシステムの設定」 (このクラスター ClusterNEW)を呼び出します。
  • 不要となった古いクラスターの設定(ここでは ClusterOLD と呼びます)。

手順17.15 クラスターのアップグレードプロセス - ロードバランシンググループ

  1. 前提条件に従って、新しいクラスターを設定します。
  2. ClusterNEW および ClusterOLD の両方で、設定オプション sticky-sessiontrue に設定するようにしてください(このオプションはデフォルトで true に設定されます)。このオプションを有効にすると、クラスターのクラスターノードへの新しいリクエストはすべてそのクラスターノードに送信されます。
    /profile=full-ha/subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=sticky-session,value=true)
    
    Copy to Clipboard Toggle word wrap
  3. ClusterOLD のすべてのクラスターノードが ClusterOLD ロードバランシンググループのメンバーであることを仮定します。この設定は、CLI または xml 設定(ドメインモードでは ha または full-ha プロファイル、スタンドアロンモードの場合は standalone-ha または standalone-full-ha のいずれか)で設定できます。
    /profile=full-ha/subsystem=modcluster/mod-cluster-config=configuration/:write-attribute(name=load-balancing-group,value=ClusterOLD)
    Copy to Clipboard Toggle word wrap
    				
    				<subsystem xmlns="urn:jboss:domain:modcluster:1.2">
    					<mod-cluster-config load-balancing-group="ClusterOLD" advertise-socket="modcluster" connector="ajp">
    						<dynamic-load-provider>
    							<load-metric type="busyness"/>
    						</dynamic-load-provider>
           		</mod-cluster-config>
        		</subsystem>
    
    Copy to Clipboard Toggle word wrap
  4. 「mod_cluster ワーカーノードの設定」 のプロセスを使用して、ClusterNEW のノードを個別に mod_cluster 設定に追加します。さらに、この手順を使用してロードバランシンググループを ClusterNEW に設定します。
    この時点で、mod_cluster-manager コンソールに、以下に短い例のような出力が表示されます。
    				
    				mod_cluster/<version>
    				
        LBGroup ClusterOLD: [Enable Nodes]   [Disable Nodes]   [Stop Nodes]
            Node node-1-jvmroute (ajp://node1.oldcluster.example:8009):
                [Enable Contexts]   [Disable Contexts]   [Stop Contexts]
                Balancer: qacluster, LBGroup: ClusterOLD, Flushpackets: Off, ..., Load: 100
                Virtual Host 1:
                    Contexts:
                        /my-deployed-application-context, Status: ENABLED Request: 0 [Disable]   [Stop]
            
            Node node-2-jvmroute (ajp://node2.oldcluster.example:8009):
                [Enable Contexts]   [Disable Contexts]   [Stop Contexts]
                Balancer: qacluster, LBGroup: ClusterOLD, Flushpackets: Off, ..., Load: 100
                Virtual Host 1:
                    Contexts:
                        /my-deployed-application-context, Status: ENABLED Request: 0 [Disable]   [Stop]
            
            
        LBGroup ClusterNEW: [Enable Nodes]   [Disable Nodes]   [Stop Nodes]
            Node node-3-jvmroute (ajp://node3.newcluster.example:8009):
                [Enable Contexts]   [Disable Contexts]   [Stop Contexts]
                Balancer: qacluster, LBGroup: ClusterNEW, Flushpackets: Off, ..., Load: 100
                Virtual Host 1:
                    Contexts:
                        /my-deployed-application-context, Status: ENABLED Request: 0 [Disable]   [Stop]
            
            Node node-4-jvmroute (ajp://node4.newcluster.example:8009):
                [Enable Contexts]   [Disable Contexts]   [Stop Contexts]
                Balancer: qacluster, LBGroup: ClusterNEW, Flushpackets: Off, ..., Load: 100
                Virtual Host 1:
                    Contexts:
                        /my-deployed-application-context, Status: ENABLED Request: 0 [Disable]   [Stop]
    
    Copy to Clipboard Toggle word wrap
  5. ClusterOLD グループ内に古いアクティブなセッションがあり、新しいセッションは ClusterOLD または CLusterNEW グループ内に作成されます。次に、現在アクティブなクライアントのセッションにエラーが発生しないようにクラスターノードの電源を切ることで、ClusterOLD グループ全体を無効にします。
    mod_cluster-manager Web コンソールの LBGroup ClusterOLD の [Disable Nodes] リンクをクリックします。
    この時点で、すでに確立されたセッションに属するリクエストのみが ClusterOLD ロードバランシンググループのメンバーにルーティングされます。新しいクライアントのセッションは ClusterNEW グループのみに作成されます。ClusterOLD グループ内にアクティブなセッションがなくなったら、そのメンバーを安全に削除できます。
    注記
    [Stop Nodes] を使用すると、即座にこのドメインへの要求のルーティングを停止するようロードバランサーコマンドが実行されます。これにより、別の負荷分散グループにフェイルオーバーが強制され、ClusterNEW と ClusterOLD の間にセッションレプリケーションがない場合は、クライアントへのセッションデータの損失が発生します。

デフォルトの負荷分散グループ

現在の ClusterOLD 設定に負荷分散グループ設定が含まれていない場合には(mod_cluster-manager コンソールで LBGroup: を参照できる)、ClusterOLD ノードの無効化を利用できます。この場合、各 Cluster OLD ノードの [Disable Contexts] をクリックします。これらのノードのコンテンツは無効になり、アクティブなセッションがないと、削除の準備が整います。新しいクライアントのセッションは、有効なコンテキストを持つノードにのみ作成されます(この例では Cluster NEW メンバー)。

JBoss EAP CLI の使用

mod_cluster-manager Web コンソールを使用できる可能性に加え、特定のコンテキストを無効にするには CLI を使用できます。前述の操作は stop-context と呼ばれますが、クラスターノードは DISABLE-APP コマンドをロードバランサーに送信し、mod_cluster-manager コンソールの特定のコンテキストの横にある [Disable] リンクをクリックするのと全く同じ効果を持つことができます(例: default-host が前述の mod_cluster-manager コンソール出力例から削除されていることに注意してください)。

/profile=full-ha/subsystem=modcluster/:stop-context(context=/my-deployed-application-context, virtualhost=default-host, waittime=50)
Copy to Clipboard Toggle word wrap

まとめ

特定のコンテキストを停止する場合、クラスターノードまたは負荷分散グループ全体を停止するには、バランサーがすぐにリクエストのルーティングを停止するため、別の利用可能なコンテキストにフェイルオーバーを強制的に実行します。特定のコンテキストを無効にするには、クラスターノードまたは負荷分散グループ全体に対して、この特定のコンテキスト/ノード/負荷分散グループで新規セッションを遮断しないように指示します。

結果

JBoss EAP 6 のクラスターが正常にアップグレードされます。

17.6.8. mod_cluster の fail_on_status パラメーターの設定

fail_on_status パラメーターは、クラスターのワーカーノードによって返されるとそのノードが失敗したことを示す HTTP ステータスコードを一覧表示します。ロードバランサーはその後のリクエストをクラスターの別のワーカーノードに送信します。失敗したワーカーノードは、ロードバランサーを NOTOK メッセージを送信するまで STATUS 状態のままになります。
注記
fail_on_status パラメーターは、この機能をサポートしないため、Hewlett-Packard の HP-UX v11.3 hpws httpd B.2.2.15.15 と使用できません。
fail_on_status パラメーターは、ロードバランサーの httpd 設定ファイルで設定する必要があります。fail_on_status の複数の HTTP ステータスコードは、コンマ区切りのリストとして指定できます。以下の例では、203 に HTTP ステータスコード 204 および fail_on_status を指定します。

例17.6 fail_on_status Configuration(設定)

ProxyPass / balancer://MyBalancer stickysession=JSESSIONID|jsessionid nofailover=on failonstatus=203,204
ProxyPassReverse / balancer://MyBalancer
ProxyPreserveHost on
Copy to Clipboard Toggle word wrap

17.7. Apache mod_jk

17.7.1. Apache mod_jk HTTP コネクター

Apache mod_jk は、互換性を確保するために必要なお客様に提供される HTTP コネクターです。これは負荷分散機能を提供し、Red Hat JBoss Enterprise Application Platform 6 のネイティブパッケージの一部です。X.0 Webserver Connector Natives (zip のインストール)は、Red Hat カスタマーポータル( https://access.redhat.com )から入手できます。mod_jk RPM からインストールできます。RPM からのインストールの詳細は、「Apache HTTP Server への mod_jk モジュールのインストール(RPM)」 を参照してください。サポートされるプラットフォームについては、を参照してください https://access.redhat.com/articles/111663mod_jk コネクターは Apache によって維持され、そのドキュメントは にあり http://tomcat.apache.org/connectors-doc/ ます。
JBoss EAP 6 は Apache HTTP プロキシーサーバーからのワークロードを許可します。プロキシーサーバーは Web フロントエンドからのクライアントリクエストを受け入れ、ワークを参加する JBoss EAP 6 サーバーに渡します。スティッキーセッションが有効な場合、同じクライアントリクエストは常に同じ JBoss EAP 6 サーバーに送信されます(サーバーが使用できない場合を除く)。
JBoss mod_cluster HTTP コネクターとは異なり、Apache mod_jk HTTP コネクターはサーバーまたはサーバーグループのデプロイメントの状態を認識せず、ワークの送信先に順応できません。
mod_jk AJP 1.3 プロトコルを介して通信します。mod_cluster 他のプロトコルをサポートします。詳細は、「HTTP コネクターの概要」 の 表 HTTP コネクター機能および制約 を参照してください。
注記
mod_cluster mod_jk よりも高度なロードバランサーです。mod_cluster mod_jk および追加機能のすべて機能を提供します。mod_cluster の詳細は、mod_cluster HTTP コネクター」 を参照してください。

次の手順: JBoss EAP 6 インスタンスを設定し mod_jk ロードバランシンググループに参加します。

17.7.2. JBoss EAP 6 が Apache mod_jk と通信するよう設定

概要

mod_jk HTTP コネクターには、Web サーバーによってロードされる mod_jk.so モジュールの単一のコンポーネントがあります。このモジュールはクライアント要求を受け取り、コンテナー(この場合は JBoss EAP 6)に転送します。これらのリクエストを許可し、応答を Web サーバーに送信するよう JBoss EAP 6 を設定する必要があります。

Apache HTTP サーバーの設定については、「Apache HTTP Server への mod_jk モジュールのインストール (ZIP)」 を参照してください。
JBoss EAP 6 が Apache HTTP サーバーと通信できるようにするには、AJP/1.3 コネクターを有効にする必要があります。このコネクターはデフォルトで以下の設定に存在します。
  • 管理対象ドメインでは、ha および full-ha プロファイルを使用するサーバーグループおよび ha または full-ha ソケットバインディンググループを使用するサーバーグループ。other-server-group サーバーグループがデフォルトのインストールで正しく設定されている。
  • スタンドアロンサーバーでは、standalone-ha プロファイルおよび standalone-full-ha プロファイルは、クラスター化の設定に対して設定されます。これらのプロファイルの 1 つでスタンドアロンサーバーを起動するには、EAP_HOME/ ディレクトリーから以下のコマンドを実行します。適切なプロファイル名を置き換えます。
    EAP_HOME/bin/standalone.sh --server-config=standalone-ha.xml
    Copy to Clipboard Toggle word wrap
    Windows の場合は、以下のコマンドを入力します。
    EAP_HOME\bin\standalone.bat --server-config=standalone-ha.xml
    Copy to Clipboard Toggle word wrap

17.7.3. Apache HTTP Server への mod_jk モジュールのインストール (ZIP)

前提条件

  • このタスクを実行するには、サポートされる環境にインストールされた Apache HTTP Server を使用するか、JBoss Enterprise Web Server からインストールした Apache HTTP Server を使用する必要があります。JBoss Enterprise Web Server は JBoss EAP 6 ディストリビューションの一部であることに注意してください。
  • Red Hat Enterprise Linux ネイティブ Apache HTTP Server をインストールする必要がある場合は、『 『Red Hat Enterprise Linux デプロイメントガイド』』 の説明を使用します。
  • HP-UX ネイティブ Apache HTTP Server をインストールする必要がある https://h20392.www2.hp.com/portal/swdepot/displayInstallInfo.do?productNumber=HPUXWSATW232 場合は、にある 『HP-UX Web Server Suite Installation Guide』 の手順を使用します。
  • JBoss Enterprise Web Server をインストールする必要がある場合は、『JBoss Enterprise Web Server『インストールガイド』を参照してください』。
  • Apache HTTP Server を使用している場合は、ご使用のプラットフォーム用の JBoss EAP 6 ネイティブコンポーネントパッケージを Red Hat カスタマーポータルから https://access.redhat.com からダウンロードします。このパッケージには、mod_jk および mod_cluster 事前にコンパイルされたバイナリーの両方が含まれます。JBoss Enterprise Web Server を使用している場合は、すでに mod_jk のバイナリーが含まれています。
  • Red Hat Enterprise Linux (RHEL) 5 と Apache HTTP サーバー (httpd 2.2.3) を使用している場合は、mod_jk モジュールをロードする前に mod_perl モジュールをロードしてください。
  • 管理 (root) 権限を使用してログインする必要があります。
  • HTTPD 変数規則を表示するには、を参照してください。 「HTTPD 変数規則」

手順17.16 mod_jk モジュールのインストール

  1. mod_jk モジュールを設定します。

    1. HTTPD_HOME/conf.d/mod-jk.conf という新しいファイルを作成し、以下を追加します。
      JkMount ディレクティブ
      JkMount ディレクティブは、Apache HTTP Server が mod_jk モジュールに転送する必要がある URL を指定します。ディレクティブの設定に基づいて、mod_jk は受信した URL を正しいワーカーに送信します。
      静的コンテンツを直接提供し、Java アプリケーションのロードバランサーのみを使用するには、URL パスは /application/* である必要があります。mod_jk をロードバランサーとして使用するには、値 /* を使用してすべての URL を mod_jk に転送します。
      # Load mod_jk module
      # Specify the filename of the mod_jk lib
      LoadModule jk_module modules/mod_jk.so
      
      # Where to find workers.properties
      JkWorkersFile conf/workers.properties
      
      # Where to put jk logs
      JkLogFile logs/mod_jk.log
      
      # Set the jk log level [debug/error/info]
      JkLogLevel info 
      
      # Select the log format
      JkLogStampFormat  "[%a %b %d %H:%M:%S %Y]"
      
      # JkOptions indicates to send SSK KEY SIZE
      JkOptions +ForwardKeySize -ForwardDirectories
      
      # JkRequestLogFormat
      JkRequestLogFormat "%w %V %T"
      
      # Mount your applications
      # The default setting only sends Java application data to mod_jk.
      # Use the commented-out line to send all URLs through mod_jk.
      # JkMount /* loadbalancer
      JkMount /application/* loadbalancer
      
      # Add shared memory.
      # This directive is present with 1.2.10 and
      # later versions of mod_jk, and is needed for
      # for load balancing to work properly
      JkShmFile logs/jk.shm 
      
      # Add jkstatus for managing runtime data
      <Location /jkstatus/>
      JkMount status
      Order deny,allow
      Deny from all
      Allow from 127.0.0.1
      </Location>
      
      Copy to Clipboard Toggle word wrap
      値を確認し、セットアップに適切であることを確認します。問題がなければ、ファイルを保存します。
    2. JKMountFile ディレクティブの指定

      mod-jk.conf の JKMount ディレクティブの他に、mod_jk に転送される複数の URL パターンを含むファイルを指定できます。
      1. 以下を HTTPD_HOME/conf/mod-jk.conf ファイルに追加します。
        # You can use external file for mount points.
        # It will be checked for updates each 60 seconds.
        # The format of the file is: /url=worker
        # /examples/*=loadbalancer
        JkMountFile conf/uriworkermap.properties
        
        Copy to Clipboard Toggle word wrap
      2. 各 URL パターンが一致する行を指定して HTTPD_CONF/uriworkermap.properties という名前の新しいファイルを作成します。以下の例は、ファイルの構文例を示しています。
        # Simple worker configuration file
        /*=loadbalancer
        
        Copy to Clipboard Toggle word wrap
    3. httpd のモジュールディレクトリーへの mod_jk.so ファイルのコピー

      注記
      これは、Apache HTTP サーバーに modules/ ディレクトリーに mod_jk.so がない場合にのみ必要です。JBoss EAP 6 のダウンロードとして含まれている Apache HTTP サーバーを使用している場合は、この手順を省略できます。
      Native Web Server Connectors Zip パッケージを展開します。オペレーティングシステムが 32 ビットまたは 64 ビットであるかによって、EAP_HOME/modules/ system/layers/base/native/lib/httpd/modules/ ディレクトリーまたはEAP_HOME/modules/layers/base/native/lib64/httpd/modules/ ディレクトリーのいずれかで mod_jk.so ファイルを見つけます。
      ファイルを HTTPD_MODULES/ ディレクトリーにコピーします。
  2. mod_jk ワーカーノードを設定します。

    1. HTTPD_CONF/workers.properties という新しいファイルを作成します。以下の例を開始点として使用し、必要に応じてファイルを変更します。
      # Define list of workers that will be used
      # for mapping requests
      worker.list=loadbalancer,status
      
      # Define Node1
      # modify the host as your host IP or DNS name.
      worker.node1.port=8009
      worker.node1.host=node1.mydomain.com
      worker.node1.type=ajp13
      worker.node1.ping_mode=A
      worker.node1.lbfactor=1 
      
      # Define Node2
      # modify the host as your host IP or DNS name.
      worker.node2.port=8009
      worker.node2.host=node2.mydomain.com
      worker.node2.type=ajp13
      worker.node2.ping_mode=A
      worker.node2.lbfactor=1
      
      # Load-balancing behavior
      worker.loadbalancer.type=lb
      worker.loadbalancer.balance_workers=node1,node2
      worker.loadbalancer.sticky_session=1
      
      # Status worker for managing load balancer
      worker.status.type=status
      
      Copy to Clipboard Toggle word wrap
      workers.properties ファイルの構文および高度な設定オプションの詳細は、「Apache mod_jk ワーカーの設定リファレンス」 を参照してください。
  3. Web サーバーを再起動します。

    Web サーバーの再起動方法は、Red Hat Enterprise Linux の Apache HTTP サーバーを使用するか、JBoss Enterprise Web Server に含まれる Apache HTTP Server を使用しているかによって異なります。以下の方法のいずれかを選択します。
    • Red Hat Enterprise Linux の Apache HTTP Server

      以下のコマンドを実行します。
      [root@host]# service httpd restart
      Copy to Clipboard Toggle word wrap
    • JBoss Enterprise Web Server の Apache HTTP Server

      JBoss Enterprise Web Server は、Red Hat Enterprise Linux と Microsoft Windows Server の両方で実行されます。Web サーバーの再起動方法はそれぞれ異なります。
      • RPM からインストールされた Red Hat Enterprise Linux

        Red Hat Enterprise Linux では、JBoss Enterprise Web Server は Web サーバーをサービスとしてインストールします。Web サーバーを再起動するには、以下の 2 つのコマンドを実行します。
        [root@host ~]# service httpd stop
        [root@host ~]# service httpd start
        
        Copy to Clipboard Toggle word wrap
      • Zip からインストールされた Red Hat Enterprise Linux

        Zip アーカイブから JBoss Enterprise Web Server Apache HTTP Server をインストールしている場合は、apachectl コマンドを使用して Web サーバーを再起動します。mingw _HOME を、JBoss Enterprise Web Server Apache HTTP Server を展開したディレクトリーに置き換えます。
        [root@host ~]# EWS_HOME/httpd/sbin/apachectl restart
        
        Copy to Clipboard Toggle word wrap
      • Microsoft Windows Server

        コマンドプロンプトで以下のコマンドを管理権限で実行します。
        net stop Apache2.2
        net start Apache2.2
        
        Copy to Clipboard Toggle word wrap
      • Solaris

        コマンドプロンプトで以下のコマンドを管理権限で実行します。mingw _HOME を、JBoss Enterprise Web Server Apache HTTP Server を展開したディレクトリーに置き換えます。
        [root@host ~] EWS_HOME/httpd/sbin/apachectl restart
        
        Copy to Clipboard Toggle word wrap

結果

Apache HTTP サーバーが mod_jk ロードバランサーを使用するよう設定されました。JBoss EAP 6 が mod_jk を認識するよう設定するには、「外部 Web サーバーからの要求を許可するよう JBoss EAP 6 を設定」 を参照してください。

17.7.4. Apache HTTP Server への mod_jk モジュールのインストール(RPM)

前提条件

  • このタスクを実行するには、Red Hat Enterprise Linux 6 または JBoss Enterprise Web Server にインストールされた Apache HTTP Server を使用するか、JBoss EAP 6 のダウンロード可能な個別コンポーネントとして含まれるスタンドアロン Apache HTTP Server を使用する必要があります。
  • jbappplatform-6-ARCHITECTURE-server-RHEL_VERSION-rpm チャンネルへのアクティブなサブスクリプションが必要です。
  • Red Hat Enterprise Linux 6 に Apache HTTP Server をインストールする必要がある場合は、『 『Red Hat Enterprise Linux 6 デプロイメントガイド』』 に記載された手順を実行します。
  • JBoss EAP 6 の個別のダウンロード可能なコンポーネントとして含まれるスタンドアロンの Apache HTTP Server をインストールする必要がある場合は、「Red Hat Enterprise Linux 5、6、7 への Apache HTTP Server のインストール(Zip)」 を参照してください。
  • JBoss Enterprise Web Server をインストールする必要がある場合は、『JBoss Enterprise Web Server インストールガイド』 に記載された手順を実行します。
  • 管理 (root) 権限を使用してログインする必要があります。

手順17.17 Red Hat Enterprise Linux 5: mod_jk と Apache HTTP Server 2.2.3

  1. mod_jk-ap22 1.2.37 と、jbappplatform-6-ARCHITECTURE-server-5-rpm チャンネルから依存関係 mod_perl をインストールします。
    yum install mod_jk
    
    Copy to Clipboard Toggle word wrap
  2. 必要に 応じ て、使用する設定ファイルのサンプルをコピーします。
    cp /usr/share/doc/mod_jk-ap22-1.2.37/mod_jk.conf.sample /etc/httpd/conf.d/mod_jk.conf
    
    Copy to Clipboard Toggle word wrap
    cp /usr/share/doc/mod_jk-ap22-1.2.37/workers.properties.sample /etc/httpd/conf/workers.properties
    
    Copy to Clipboard Toggle word wrap
    これらのファイルは、必要に応じて編集する必要があります。
  3. サーバーを起動します。
    service httpd start
    
    Copy to Clipboard Toggle word wrap
注記
以下のエラーメッセージは、mod_perl が存在する前に mod_jk モジュールがロードされたことを意味しています。
Cannot load /etc/httpd/modules/mod_jk.so into server: /etc/httpd/modules/mod_jk.so: undefined symbol: ap_get_server_description
Copy to Clipboard Toggle word wrap
mod_perl モジュールが mod_jk モジュールよりも先に読み込まれるようにするには、以下を /etc/httpd/conf.d/mod_jk.conf に追加します。
 <IfModule !perl_module>
        LoadModule perl_module modules/mod_perl.so
</IfModule>
LoadModule jk_module modules/mod_jk.so
Copy to Clipboard Toggle word wrap

手順17.18 Red Hat Enterprise Linux 5: mod_jk と JBoss EAP Apache HTTP Server 2.2.26

  1. 以下のコマンドを使用して、jbappplatform-6-ARCHITECTURE-server-5-rpm チャンネルで提供される mod_jk と最新の Apache HTTP Server 2.2.26 をインストールします。
    yum install mod_jk httpd
    
    Copy to Clipboard Toggle word wrap
  2. 必要に 応じ て、使用する設定ファイルのサンプルをコピーします。
    cp /usr/share/doc/mod_jk-ap22-1.2.37/mod_jk.conf.sample /etc/httpd/conf.d/mod_jk.conf
    
    Copy to Clipboard Toggle word wrap
    cp /usr/share/doc/mod_jk-ap22-1.2.37/workers.properties.sample /etc/httpd/conf/workers.properties
    
    Copy to Clipboard Toggle word wrap
    これらのファイルは、必要に応じて編集する必要があります。
  3. サーバーを起動します。
    service httpd start
    
    Copy to Clipboard Toggle word wrap

手順17.19 Red Hat Enterprise Linux 6: mod_jk と JBoss EAP Apache HTTP Server 2.2.26

  1. jbappplatform-6-ARCHITECTURE-server-6-rpm チャンネルから mod_jk-ap22 1.2.37 および Apache HTTP Server 2.2.26 httpd パッケージをインストールします(既存のバージョンはすべて更新されます)。
    yum install mod_jk httpd
    
    Copy to Clipboard Toggle word wrap
  2. 必要に 応じ て、使用する設定ファイルのサンプルをコピーします。
    cp /usr/share/doc/mod_jk-ap22-1.2.37/mod_jk.conf.sample /etc/httpd/conf.d/mod_jk.conf
    
    Copy to Clipboard Toggle word wrap
    cp /usr/share/doc/mod_jk-ap22-1.2.37/workers.properties.sample /etc/httpd/conf/workers.properties
    
    Copy to Clipboard Toggle word wrap
    これらのファイルは、必要に応じて編集する必要があります。
  3. サーバーを起動します。
    service httpd start
    
    Copy to Clipboard Toggle word wrap

手順17.20 Red Hat Enterprise Linux 6: mod_jk と Apache HTTP Server 2.2.15

  1. 以下のコマンドを実行して、mod_jk と Apache HTTP Server 2.2.15 をインストールします。
    yum install mod_jk
    
    Copy to Clipboard Toggle word wrap
  2. 必要に 応じ て、使用する設定ファイルのサンプルをコピーします。
    cp /usr/share/doc/mod_jk-ap22-1.2.37/mod_jk.conf.sample /etc/httpd/conf.d/mod_jk.conf
    
    Copy to Clipboard Toggle word wrap
    cp /usr/share/doc/mod_jk-ap22-1.2.37/workers.properties.sample /etc/httpd/conf/workers.properties
    
    Copy to Clipboard Toggle word wrap
    これらのファイルは、必要に応じて編集する必要があります。
  3. サーバーを起動します。
    service httpd start
    
    Copy to Clipboard Toggle word wrap

手順17.21 Red Hat Enterprise Linux 7: mod_jk と JBoss EAP Apache HTTP Server 2.2.26

  1. jbappplatform-6-ARCHITECTURE-server-6-rpm チャンネルから mod_jk-ap22 1.2.37 および Apache HTTP Server 2.2.26 httpd22 パッケージをインストールします(既存のバージョンはすべて更新されます)。
    yum install mod_jk
    
    Copy to Clipboard Toggle word wrap
  2. 必要に 応じ て、使用する設定ファイルのサンプルをコピーします。
    cp /usr/share/doc/mod_jk-ap22-1.2.37/mod_jk.conf.sample /etc/httpd22/conf.d/mod_jk.conf
    
    Copy to Clipboard Toggle word wrap
    cp /usr/share/doc/mod_jk-ap22-1.2.37/workers.properties.sample /etc/httpd22/conf/workers.properties
    
    Copy to Clipboard Toggle word wrap
    これらのファイルは、必要に応じて編集する必要があります。
  3. サーバーを起動します。
    systemctl start httpd22.service
    
    Copy to Clipboard Toggle word wrap

17.7.5. Apache mod_jk ワーカーの設定リファレンス

workers.properties ファイルは mod_jk がクライアント要求を渡すワーカーの動作を定義します。Red Hat Enterprise Linux では、ファイルは /etc/httpd/conf/workers.properties にあります。workers.properties ファイルは、異なるアプリケーションサーバーの場所と、負荷をまたがって分散する方法を定義します。
この設定は、3 つのセクションに分かれます。最初のセクションでは、すべてのワーカーに適用されるグローバルプロパティーを処理します。2 番目のセクションには、特定のロードバランサーに適用される設定が含まれます。3 つ目のセクションには、ロードバランサーによって分散される特定のワーカーノードに適用される設定が含まれます。
プロパティーの一般的な構造は worker です。WORKER_NAMEDIRECTIVEです。 WORKER_NAME はワーカーの一意の名前で、DIRECTIVE はワーカーに適用される設定です。

Apache mod_jk ロードバランサーの設定リファレンス

テンプレートは、ロードバランサーごとにデフォルトの設定を指定します。ロードバランサーの設定内でテンプレートを上書きできます。ロードバランサーテンプレートの例は、例17.7「workers.properties ファイルの例」 で確認できます。

Expand
表17.15 グローバルプロパティー
プロパティー 説明
worker.list mod_jk によって使用されるロードバランサー名の一覧。これらのロードバランサーは要求を受信するために使用できます。
Expand
表17.16 必須ディレクティブ
プロパティー 説明
type
ロードバランサーのタイプ。デフォルトのタイプは ajp13 です。他の可能な値は ajp14lbstatus です。
これらのディレクティブの詳細については、の『Apache Tomcat Connector AJP Protocol Reference』を参照 http://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html してください。
Expand
表17.17 負荷分散ディレクティブ
プロパティー 説明
balance_workers
ロードバランサーが管理する必要があるワーカーノードを指定します。同じロードバランサーにディレクティブを複数回使用できます。カンマ区切りのワーカーノード名のリストで構成されます。これはワーカーノードごとにではなく、ロードバランサーごとに設定されます。
sticky_session
同じセッションからのリクエストを常に同じワーカーにルーティングするかどうかを指定します。デフォルトは 1 で、スティッキーセッションが有効になります。スティッキーセッションを無効にするには 0. を設定します。すべてのリクエストが実際にステートレスである場合を除き、スティッキーセッションは通常有効にする必要があります。これはワーカーノードごとにではなく、ロードバランサーごとに設定されます。
Expand
表17.18 接続ディレクティブ
プロパティー 説明
host
ロードバランサーのホスト名または IP アドレス。ロードバランサーは ajp プロトコルスタックをサポートする必要があります。デフォルト値は localhost です。
port
定義されたプロトコル要求をリッスンしているリモートサーバーインスタンスのポート番号。デフォルト値は 8009 です。これは AJP13 ロードバランサーのデフォルトリッスンポートです。AJP14 ロードバランサーのデフォルト値は 8011 です。
ping_mode
ネットワークの状態に対して接続がプローブされる条件。プローブは CPing に空の AJP13 パケットを使用し、応答で CPong を想定します。ディレクティブフラグの組み合わせを使用して条件を指定します。フラグはコンマまたはスペースで区切られません。ping_mode には、CPI、および A の任意の組み合わせを使用できます。
  • C - Connect(接続)。サーバーへの接続後に 1 回接続をプローブします。connect_timeout の値を使用してタイムアウトを指定します。それ以外の場合は、ping_timeout の値が使用されます。
  • P - Prepost(プレポスト)。各リクエストをサーバーに送信する前に接続をプローブします。prepost_timeout ディレクティブを使用してタイムアウトを指定します。それ以外の場合は、ping_timeout の値が使用されます。
  • I - Interval(間隔)。connection_ping_interval で指定された間隔で接続をプローブします(ある場合)。それ以外の場合は、ping_timeout の値が使用されます。
  • A - All(すべて)。すべての接続プローブを使用することを指定する CPI のショートカットです。
ping_timeout、connect_timeout、prepost_timeout、connection_ping_interval
上記の接続プローブ設定のタイムアウト値。値はミリ秒単位で指定され、ping_timeout のデフォルト値は 10000 です。
lbfactor
個々のロードバランサーの負荷分散係数を指定し、ロードバランサーのメンバーワーカーノードにのみ適用されます。より強力なサーバーにより多くの作業負荷を割り当てる場合に便利です。ワーカーにデフォルトの 3 倍の負荷を割り当てるには、worker.my_worker.lbfactor=3 のように 3 を設定します。

例17.7 workers.properties ファイルの例

worker.balancer1.type=lb
worker.balancer2.type=lb

worker.balancer1.sticky_sessions=1
worker.balancer1.balance_workers=node1
worker.balancer2.sticky_session=1
worker.balancer2.balance_workers=node2,node3

worker.nodetemplate.type=ajp13
worker.nodetemplate.port=8009

worker.node1.template=nodetemplate
worker.node1.host=localhost
worker.node1.ping_mode=CI
worker.node1.connection_ping_interval=9000
worker.node1.lbfactor=1

worker.node2.template=nodetemplate
worker.node2.host=192.168.1.1
worker.node2.ping_mode=A

worker.node3.template=nodetemplate
worker.node3.host=192.168.1.2
Copy to Clipboard Toggle word wrap
上記の例では、複数のロードバランサーを使用して Web サーバーの代わりにコンテンツを提供できます。このような設定の理由は以下のとおりです。
  • 異なるロードバランサーで異なるコンテキストを提供するには、すべての開発者が同じ Web サーバーを共有し、独自のロードバランサーを所有する開発環境を提供します。
  • 異なるプロセスが提供する仮想ホストが異なる場合に、異なる企業に属するサイト間で明確に分離できます。
  • 負荷分散を提供するには、独自のマシンで複数のロードバランサーを実行し、それらの間で要求を分割します。
Apache mod_jk の設定の詳細は、本書の範囲外です。詳細は Apache ドキュメントを参照 http://tomcat.apache.org/connectors-doc/ してください。

17.8. Apache mod_proxy

17.8.1. Apache mod_proxy HTTP コネクター

Apache は、httpd に 2 つの異なるプロキシーおよび負荷分散モジュール( mod_proxymod_jk )を提供します。mod_jk の詳細は、「Apache mod_jk HTTP コネクター 」 を参照してください。JBoss EAP 6 はこれらのいずれかの HTTP コネクターをサポートしますが、JBoss HTTP コネクターである mod_cluster は JBoss EAP 6 と外部 httpd と密接に連携し、推奨される HTTP コネクターです。サポートされているすべての HTTP コネクターの概要は、「HTTP コネクターの概要」 を参照してください。これには長所や短所が含まれます。
mod_jk とは異なり、mod_proxy は HTTP および HTTPS プロトコルを介した接続をサポートします。それぞれが AJP プロトコルもサポートします。
mod_proxy は、スタンドアロンまたは負荷分散設定で設定でき、スティッキーセッションをサポートします。
mod_proxy モジュールでは、JBoss EAP 6 に HTTP、HTTPS、または AJP Web コネクターが設定されている必要があります。これは Web サブシステムの一部です。Web サブシステムの設定に関する詳細は、「Web サブシステムの設定」 を参照してください。
注記
mod_cluster mod_proxy よりも高度なロードバランサーです。mod_cluster mod_proxy および追加機能のすべて機能を提供します。mod_cluster の詳細は、mod_cluster HTTP コネクター」 を参照してください。

17.8.2. Apache HTTP Server への mod_proxy HTTP コネクターのインストール

概要

mod_proxy は、Apache が提供する負荷分散モジュールです。このタスクは基本的な設定を示します。詳細設定、または詳細については、Apache の mod_proxy ドキュメント https://httpd.apache.org/docs/2.2/mod/mod_proxy.html を参照してください。JBoss EAP 6 の観点からした mod_proxy の詳細は、「Apache mod_proxy HTTP コネクター 」 および 「HTTP コネクターの概要」 を参照してください。

前提条件

  • JBoss Enterprise Web Server から、またはオペレーティングシステムが提供する Apache HTTP サーバーをインストールする必要があります。スタンドアロン Apache HTTP Server は、Red Hat カスタマーポータル(JBoss EAP 6 のダウンロードエリア)の個別ダウンロードとして提供されます。この Apache HTTP サーバーを使用する場合は、「Red Hat Enterprise Linux 5、6、7 への Apache HTTP Server のインストール(Zip)」 を参照してください。
  • mod_proxy モジュールをインストールする必要があります。Apache HTTP サーバーには通常、すでに含まれている mod_proxy モジュールが同梱されています。これは、Red Hat Enterprise Linux と、JBoss Enterprise Web Server に同梱される Apache HTTP Server の場合です。
  • Apache HTTP Server 設定を変更するには、root または管理者権限が必要です。
  • この例では、JBoss EAP 6 が HTTP または HTTPS Web コネクターで設定されていることを前提としています。これは Web サブシステム設定の一部です。Web サブシステムの設定に関する詳細は、「Web サブシステムの設定」 を参照してください。
  1. httpd で mod_proxy モジュールを有効にします。

    HTTPD_CONF/httpd.conf ファイルで以下の行を見つけます。存在しない場合は、下部に追加します。行が存在していても、コメント(#)文字で始まる場合は、文字を削除します。その後ファイルを保存します。通常、モジュールはすでに存在し、有効になっています。
    LoadModule proxy_module modules/mod_proxy.so
    LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
    LoadModule proxy_http_module modules/mod_proxy_http.so
    # Uncomment these to proxy FTP or HTTPS
    #LoadModule proxy_ftp_module modules/mod_proxy_ftp.so
    #LoadModule proxy_connect_module modules/mod_proxy_connect.so
    
    Copy to Clipboard Toggle word wrap
  2. 非負荷分散プロキシーを追加します。

    以下の設定を、その他の < VirtualHost > ディレクティブのすぐ下にある HTTPD_CONF/httpd.conf ファイルに追加します。値を設定に適切な値に置き換えます。
    この例では、仮想ホストを使用します。デフォルトの httpd 設定を使用するには、次の手順を参照してください。
    <VirtualHost *:80>
    # Your domain name
    ServerName Domain_NAME_HERE
    
    ProxyPreserveHost On
    
    # The IP and port of JBoss EAP 6
    # These represent the default values, if your httpd is on the same host
    # as your JBoss EAP 6 managed domain or server
    
    ProxyPass / http://localhost:8080/
    ProxyPassReverse / http://localhost:8080/
    
    # The location of the HTML files, and access control information
    DocumentRoot /var/www
    <Directory /var/www>
    Options -Indexes
    Order allow,deny
    Allow from all
    </Directory>
    </VirtualHost>
    Copy to Clipboard Toggle word wrap
    変更後に、ファイルを保存します。
  3. 負荷分散プロキシーを追加します。

    mod_proxy をロードバランサーとして使用し、ワークを複数の JBoss EAP 6 インスタンスに送信するには、以下の設定を HTTPD_CONF/httpd.conf ファイルに追加します。IP アドレスの例は以下のようになります。ご使用の環境に適切な値に置き換えてください。
    <Proxy balancer://mycluster>
    
    Order deny,allow
    Allow from all
    
    # Add each JBoss Enterprise Application Server by IP address and port.
    # If the route values are unique like this, one node will not fail over to the other.
    BalancerMember http://192.168.1.1:8080 route=node1
    BalancerMember http://192.168.1.2:8180 route=node2
    </Proxy>
    
    <VirtualHost *:80>
     # Your domain name
     ServerName YOUR_DOMAIN_NAME
    
     ProxyPreserveHost On
     ProxyPass / balancer://mycluster/
    
     # The location of the HTML files, and access control information DocumentRoot /var/www
     <Directory /var/www>
      Options -Indexes
      Order allow,deny
      Allow from all
     </Directory>
    
    </VirtualHost>
    
    Copy to Clipboard Toggle word wrap
    上記の例はすべて HTTP プロトコルを使用して通信します。適切な mod_proxy モジュールを読み込む場合は、AJP または HTTPS プロトコルを使用できます。詳細は Apache の mod_proxy ドキュメント http://httpd.apache.org/docs/2.2/mod/mod_proxy.html を参照してください。
  4. スティッキーセッションを有効にします。

    スティッキーセッション は、クライアントリクエストが特定の JBoss EAP 6 ワーカーに送信されると、利用できない場合を除き、今後のすべてのリクエストが同じワーカーに送信されます。これはほとんどの場合正しい動作です。
    mod_proxy のスティッキーセッションを有効にするには、stickysession パラメーターを ProxyPass ステートメントに追加します。この例では、使用できるその他のパラメーターも示します。詳細は、Apache の mod_proxy ドキュメント( http://httpd.apache.org/docs/2.2/mod/mod_proxy.html )を参照してください。
    ProxyPass /MyApp balancer://mycluster stickysession=JSESSIONID lbmethod=bytraffic nofailover=Off
    Copy to Clipboard Toggle word wrap
  5. Web サーバーを再起動します。

    Web サーバーを再起動して変更を有効にします。

結果

標準または負荷分散設定のいずれかで、mod_proxy を使用してクライアントリクエストを JBoss EAP 6 インスタンスに送信するよう Apache HTTP サーバーが設定されます。JBoss EAP 6 がこれらのリクエストに応答するように設定するには、「外部 Web サーバーからの要求を許可するよう JBoss EAP 6 を設定」 を参照してください。

17.9. Microsoft ISAPI コネクター

17.9.1. インターネットサーバー API(ISAPI)について

Internet Server API(ISAPI) は、Microsoft のインターネット情報サービス(IIS)などの Web サーバー用の OLE サーバー拡張機能やフィルターを書き込むために使用される API のセットです。ISAPI _redirect.dll は IIS 向けに調整された mod_jk の拡張機能です。isapi_redirect.dll を使用すると、JBoss EAP 6 インスタンスをワーカーノードとしてロードバランサーとして設定できます。

17.9.2. Microsoft IIS の Web サーバーコネクターネイティブのダウンロードおよび展開

  1. Web ブラウザーで、Red Hat カスタマーポータル https://access.redhat.com ()に移動します。
  2. Downloads に移動し、Red Hat JBoss Middleware Download Software を選択してから、Product ドロップダウンリストから Enterprise Application Platform を選択します。
  3. Version ドロップダウンリストから適切なバージョンを選択します。
  4. サーバーのアーキテクチャーに応じて、Red Hat JBoss Enterprise Application Platform < VERSION > Webserver Connector Natives for Windows Server 2008 x86_64 または Red Hat JBoss Enterprise Application Platform < VERSION > Webserver Connector Natives for Windows Server 2008 i686 のいずれかの Download オプションを選択します。
  5. Zip ファイルを開き、jboss-eap- <VERSION> /modules/system/layers/base/native/sbin ディレクトリーの内容をサーバーの場所にコピーします。ここでは、内容が C:\connectors\ にコピーされたことを前提とします。

17.9.3. Microsoft IIS が ISAPI コネクターを使用するよう設定

注記
Microsoft Windows Server および IIS のサポートされる設定の一覧は、を参照 https://access.redhat.com/articles/111663 してください。

手順17.22 IIS マネージャー (IIS 7) を使用した IIS リダイレクターの設定

  1. StartRun クリックして IIS マネージャーを開き、inetmgr と入力します。
  2. 左側のツリービューペインで IIS 7 を展開します。
  3. ISAPI and CGI Registrations をダブルクリックして新しいウィンドウで開きます。
  4. Actions ペインで Add をクリックします。Add ISAPI or CGI Restriction ウインドウが開きます。
  5. 以下の値を指定します。
    • ISAPI or CGI Path:c:\connectors\isapi_redirect.dll
    • Description:jboss
    • Allow extension path to execute: チェックボックスを選択します。
  6. OK をクリックして Add ISAPI or CGI Restriction ウィンドウを閉じます。
  7. JBoss ネイティブ仮想ディレクトリーの定義

    1. Default Web Site を右クリックし、Add Virtual Directory をクリックします。Add Virtual Directory ウィンドウが開きます。
    2. 以下の値を指定して仮想ディレクトリーを追加します。
      • エイリアス:jboss
      • Physical Path:C:\connectors\
    3. OK をクリックして値を保存し、Add Virtual Directory ウィンドウを閉じます。
  8. JBoss ネイティブ ISAPI リダイレクトフィルターの定義

    1. ツリービューペインで SitesDefault Web Site を展開します。
    2. ISAPI Filters をダブルクリックします。ISAPI Filters Features ビューが表示されます。
    3. Actions ペインで Add をクリックします。Add ISAPI Filter ウインドウが表示されます。
    4. Add ISAPI Filter ウィンドウで、以下の値を指定します。
      • Filter name:jboss
      • Executable:C:\connectors\isapi_redirect.dll
    5. OK をクリックして値を保存し、Add ISAPI Filters ウィンドウを閉じます。
  9. ISAPI-dll ハンドラーの有効化

    1. ツリービューペインの IIS 7 をダブルクリックします。IIS 7 Home Features View が開きます。
    2. Handler Mappings をダブルクリックします。Handler Mappings Features View が表示されます。
    3. Group by コンボボックスで State を選択します。Handler MappingsEnabled and Disabled Groups に表示されます。
    4. ISAPI-dll を検索します。Disabled グループにある場合は右クリックし、Edit Feature Permissions を選択します。
    5. 以下のパーミッションを有効にします。
      • Read
      • Script
      • Execute
    6. OK をクリックして値を保存し、Edit Feature Permissions ウインドウを閉じます。

17.9.4. ISAPI コネクターがクライアントリクエストを JBoss EAP 6 に送信するよう設定

概要

このタスクでは、JBoss EAP 6 サーバーのグループが ISAPI コネクターからのリクエストを受け入れるように設定します。ロードバランシングまたは高可用性フェイルオーバーの設定は含まれません。これらの機能が必要な場合は、「ISAPI コネクターがクライアントリクエストを複数の JBoss EAP 6 サーバーで分散するよう設定」 を参照してください。

この設定は IIS サーバーで行われ、JBoss EAP 6 はすでに 「外部 Web サーバーからの要求を許可するよう JBoss EAP 6 を設定」 に従って設定されていることを前提とします。

手順17.23 プロパティーファイルの編集およびリダイレクトの設定

  1. ログ、プロパティーファイル、およびロックファイルを格納するディレクトリーを作成します。

    この手順では、ディレクトリー C:\connectors\ の使用を前提としています。異なるディレクトリーを使用する場合は、適切に手順を変更してください。
  2. isapi_redirect.properties ファイルを作成します。

    C:\connectors\isapi_redirect.properties という新しいファイルを作成します。このファイルに次の内容をコピーします。
    # Configuration file for the ISAPI Connector
    # Extension uri definition
    extension_uri=/jboss/isapi_redirect.dll
    
    # Full path to the log file for the ISAPI Connector
    log_file=c:\connectors\isapi_redirect.log
    
    # Log level (debug, info, warn, error or trace)
    log_level=info
    
    # Full path to the workers.properties file
    worker_file=c:\connectors\workers.properties
    
    # Full path to the uriworkermap.properties file
    worker_mount_file=c:\connectors\uriworkermap.properties
    
    #Full path to the rewrite.properties file 
    rewrite_rule_file=c:\connectors\rewrite.properties
    
    Copy to Clipboard Toggle word wrap
    rewrite.properties ファイルを使用しない場合は、行の先頭に # 文字を記入して最後の行をコメントアウトします。詳細は、ステップ 5 を参照してください。
  3. uriworkermap.properties ファイルを作成します。

    uriworkermap.properties ファイルには、デプロイされたアプリケーション URL と、それらへの要求を処理するワーカー間のマッピングが含まれます。以下のサンプルファイルはファイルの構文を示しています。uriworkermap.properties ファイルを C:\connectors\ に配置します。
    # images and css files for path /status are provided by worker01
    /status=worker01
    /images/*=worker01
    /css/*=worker01
    
    # Path /web-console is provided by worker02
    # IIS (customized) error page is used for http errors with number greater or equal to 400
    # css files are provided by worker01
    /web-console/*=worker02;use_server_errors=400
    /web-console/css/*=worker01
    
    # Example of exclusion from mapping, logo.gif won't be displayed  
    # /web-console/images/logo.gif=*
    
    # Requests to /app-01 or /app-01/something will be routed to worker01
    /app-01|/*=worker01
    
    # Requests to /app-02 or /app-02/something will be routed to worker02
    /app-02|/*=worker02
    
    Copy to Clipboard Toggle word wrap
  4. workers.properties ファイルを作成します。

    workers.properties ファイルには、ワーカーラベルとサーバーインスタンス間のマッピング定義が含まれます。以下のサンプルファイルはファイルの構文を示しています。このファイルを C:\connectors\ ディレクトリーに置きます。
    # An entry that lists all the workers defined
    worker.list=worker01, worker02
    
    # Entries that define the host and port associated with these workers
    
    # First JBoss EAP 6 server definition, port 8009 is standard port for AJP in EAP 
    worker.worker01.host=127.0.0.1
    worker.worker01.port=8009
    worker.worker01.type=ajp13
    
    # Second JBoss EAP 6 server definition
    worker.worker02.host=127.0.0.100
    worker.worker02.port=8009
    worker.worker02.type=ajp13
    
    Copy to Clipboard Toggle word wrap
  5. rewrite.properties ファイルを作成します。

    rewrite.properties ファイルには、特定のアプリケーションの単純な URL 書き換えルールが含まれます。以下の例で示されているように、書き換えられたパスは名前と値のペアを使用して指定されます。このファイルを C:\connectors\ ディレクトリーに置きます。
    #Simple example
    # Images are accessible under abc path
    /app-01/abc/=/app-01/images/
    
    Copy to Clipboard Toggle word wrap
  6. IIS サーバーを再起動します。

    net stop コマンドおよび net start コマンドを使用して IIS サーバーを再起動します。
    C:\> net stop was /Y
    C:\> net start w3svc
    
    Copy to Clipboard Toggle word wrap

結果

アプリケーションごとに、設定した特定の JBoss EAP 6 サーバーにクライアント要求を送信するよう IIS サーバーが設定されます。

概要

この設定は、指定する JBoss EAP 6 サーバー全体でクライアントリクエストを分散します。デプロイメントごとに特定の JBoss EAP 6 サーバーにクライアントリクエストを送信する場合は、代わりに 「ISAPI コネクターがクライアントリクエストを JBoss EAP 6 に送信するよう設定」 を参照してください。

この設定は IIS サーバーで行われ、JBoss EAP 6 はすでに 「外部 Web サーバーからの要求を許可するよう JBoss EAP 6 を設定」 に従って設定されていることを前提とします。

手順17.24 複数のサーバー間でのクライアント要求の分散

  1. ログ、プロパティーファイル、およびロックファイルを格納するディレクトリーを作成します。

    この手順では、ディレクトリー C:\connectors\ の使用を前提としています。異なるディレクトリーを使用する場合は、適切に手順を変更してください。
  2. isapi_redirect.properties ファイルを作成します。

    C:\connectors\isapi_redirect.properties という新しいファイルを作成します。このファイルに次の内容をコピーします。
    # Configuration file for the ISAPI Connector
    # Extension uri definition
    extension_uri=/jboss/isapi_redirect.dll
    
    # Full path to the log file for the ISAPI Connector
    log_file=c:\connectors\isapi_redirect.log
    
    # Log level (debug, info, warn, error or trace)
    log_level=info
    
    # Full path to the workers.properties file
    worker_file=c:\connectors\workers.properties
    
    # Full path to the uriworkermap.properties file
    worker_mount_file=c:\connectors\uriworkermap.properties
    
    #OPTIONAL: Full path to the rewrite.properties file 
    rewrite_rule_file=c:\connectors\rewrite.properties
    
    Copy to Clipboard Toggle word wrap
    rewrite.properties ファイルを使用しない場合は、行の先頭に # 文字を記入して最後の行をコメントアウトします。詳細は、ステップ 5 を参照してください。
  3. uriworkermap.properties ファイルを作成します。

    uriworkermap.properties ファイルには、デプロイされたアプリケーション URL と、それらへの要求を処理するワーカー間のマッピングが含まれます。以下のサンプルファイルは負荷分散が設定されたファイルの構文を示しています。ワイルドカード(*)文字は、さまざまな URL サブディレクトリーのすべてのリクエストを router というロードバランサーに送信します。ロードバランサーの設定は、ステップ 4 で説明されています。
    uriworkermap.properties ファイルを C:\connectors\ に配置します。
    # images, css files, path /status and /web-console will be
    # provided by nodes defined in the load-balancer called "router"
    /css/*=router
    /images/*=router
    /status=router
    /web-console|/*=router
    
    # Example of exclusion from mapping, logo.gif won't be displayed  
    # /web-console/images/logo.gif=*
    
    # Requests to /app-01 and /app-02 will be routed to nodes defined
    # in the load-balancer called "router"
    /app-01|/*=router
    /app-02|/*=router
    
    # mapping for management console, nodes in cluster can be enabled or disabled here
    /jkmanager|/*=status
    
    Copy to Clipboard Toggle word wrap
  4. workers.properties ファイルを作成します。

    workers.properties ファイルには、ワーカーラベルとサーバーインスタンス間のマッピング定義が含まれます。以下のサンプルファイルはファイルの構文を示しています。ロードバランサーはファイルの末尾付近に設定され、ワーカー worker01 および worker02 で構成されます。workers.properties ファイルは、Apache mod_jk 設定に使用される同じファイルの構文に従います。workers.properties ファイルの構文に関する詳細は、「Apache mod_jk ワーカーの設定リファレンス」 を参照してください。
    このファイルを C:\connectors\ ディレクトリーに置きます。
    # The advanced router LB worker
    worker.list=router,status
    
    # First EAP server definition, port 8009 is standard port for AJP in EAP
    #
    # lbfactor defines how much the worker will be used. 
    # The higher the number, the more requests are served
    # lbfactor is useful when one machine is more powerful 
    # ping_mode=A – all possible probes will be used to determine that
    # connections are still working
    
    worker.worker01.port=8009
    worker.worker01.host=127.0.0.1
    worker.worker01.type=ajp13
    worker.worker01.ping_mode=A
    worker.worker01.socket_timeout=10
    worker.worker01.lbfactor=3
    
    # Second EAP server definition
    worker.worker02.port=8009
    worker.worker02.host=127.0.0.100
    worker.worker02.type=ajp13
    worker.worker02.ping_mode=A
    worker.worker02.socket_timeout=10
    worker.worker02.lbfactor=1
    
    # Define the LB worker
    worker.router.type=lb
    worker.router.balance_workers=worker01,worker02
    
    # Define the status worker for jkmanager
    worker.status.type=status
    
    Copy to Clipboard Toggle word wrap
  5. rewrite.properties ファイルを作成します。

    rewrite.properties ファイルには、特定のアプリケーションの単純な URL 書き換えルールが含まれます。以下の例で示されているように、書き換えられたパスは名前と値のペアを使用して指定されます。このファイルを C:\connectors\ ディレクトリーに置きます。
    #Simple example
    # Images are accessible under abc path
    /app-01/abc/=/app-01/images/
    
    Copy to Clipboard Toggle word wrap
  6. IIS サーバーを再起動します。

    net stop コマンドおよび net start コマンドを使用して IIS サーバーを再起動します。
    C:\> net stop was /Y
    C:\> net start w3svc
    
    Copy to Clipboard Toggle word wrap

結果

IIS サーバーは、workers.properties ファイルで参照されている JBoss EAP 6 サーバーにクライアントリクエストを送信し、サーバー間で負荷を 1:3 の比率で分散するよう設定されます。この比率は、各サーバーに割り当てられた負荷分散係数(lbfactor)から派生します。

17.10. Oracle NSAPI コネクター

17.10.1. Netscape Server API(NSAPI)

Netscape Server API(NSAPI) は、拡張機能をサーバーに実装するために Oracle iPlanet Web Server(旧名 Netscape Web Server)によって提供される API です。これらの拡張機能はサーバープラグインと呼ばれます。この API は、ネイティブユーティリティーパッケージで JBoss EAP 6 が提供する nsapi_redirector.so で使用さ れます。このコネクターを設定するには、「NSAPI コネクターがクライアントリクエストを複数の JBoss EAP 6 サーバーで分散するよう設定」 を参照してください。

17.10.2. Oracle Solaris での NSAPI コネクターの設定

概要

NSAPI コネクターは、Oracle iPlanet Web Server 内で実行されるモジュールです。

前提条件

  • サーバーが、Intel 32 ビット、Intel 64 ビット、または SPARC64 アーキテクチャーで Oracle Solaris 10 以上を実行している必要があります。
  • Intel アーキテクチャー用の Oracle iPlanet Web Server 7.0.15 以降、SPARC アーキテクチャーでは 7.0.14 以上が、NSAPI コネクターとは別にインストールされ、設定されます。
  • ワーカーとして動作する各サーバーに JBoss EAP 6 がインストールされ、設定されます。「外部 Web サーバーからの要求を許可するよう JBoss EAP 6 を設定」 を参照してください。
  • JBoss ネイティブコンポーネントの ZIP パッケージは、Customer Service Portal(Customer Service Portal)からダウンロードされ https://access.redhat.com ます。

手順17.25 NSAPI コネクターの抽出および設定

  1. JBoss ネイティブコンポーネントパッケージを抽出します。

    この手順では、ネイティブコンポーネントパッケージが EAP_HOME ディレクトリーに展開されることを前提としています。この手順の残りの部分では、/opt/oracle/webserver7/config/ ディレクトリーは IPLANET_CONFIG と呼ばれます。Oracle iPlanet 設定ディレクトリーが異なる場合は、適切に手順を変更してください。
  2. サーブレットマッピングを無効にします。

    IPLANET_CONFIG/default.web.xml ファイルを開き、Built In Server Mappings という見出しのセクションを見つけます。次の 3 つのサーブレットを XML コメント文字 (<!-- および -->) で囲み、これらのサーブレットへのマッピングを無効にします。
    • default
    • invoker
    • jsp
    以下の設定例は、無効にされたマッピングを示しています。
    <!-- ============== Built In Servlet Mappings =============== -->
    <!-- The servlet mappings for the built in servlets defined above. -->
    <!-- The mapping for the default servlet -->
    <!--servlet-mapping>
     <servlet-name>default</servlet-name>
     <url-pattern>/</url-pattern>
    </servlet-mapping-->
    <!-- The mapping for the invoker servlet -->
    <!--servlet-mapping>
     <servlet-name>invoker</servlet-name>
     <url-pattern>/servlet/*</url-pattern>
    </servlet-mapping-->
    <!-- The mapping for the JSP servlet -->
    <!--servlet-mapping>
     <servlet-name>jsp</servlet-name>
     <url-pattern>*.jsp</url-pattern>
    </servlet-mapping-->
    Copy to Clipboard Toggle word wrap
    ファイルを保存し、終了します。
  3. iPlanet Web Server が NSAPI コネクターモジュールをロードするよう設定します。

    IPLANET_CONFIG/magnus.conf ファイルの最後に次の行を追加し、設定に合わせてファイルパスを変更します。これらの行は、nsapi_redirector.so モジュールと workers.properties ファイルの場所を定義し、ワーカーとそのプロパティーを一覧表示します。
    Init fn="load-modules" funcs="jk_init,jk_service" shlib="EAP_HOME/modules/system/layers/base/native/lib/nsapi_redirector.so" shlib_flags="(global|now)"
    
    Init fn="jk_init" worker_file="IPLANET_CONFIG/connectors/workers.properties" log_level="info" log_file="IPLANET_CONFIG/connectors/nsapi.log" shm_file="IPLANET_CONFIG/connectors/tmp/jk_shm"
    Copy to Clipboard Toggle word wrap
    上記の設定は 32 ビットアーキテクチャー向けです。64 ビット Solaris を使用している場合は、文字列 lib/nsapi_redirector.solib64/nsapi_redirector.so に変更します。
    ファイルを保存し、終了します。
  4. NSAPI コネクターを設定します。

    負荷分散のない基本設定または負荷分散設定向けに NSAPI コネクターを設定できます。以下のいずれかのオプションを選択します。 その後、設定が完了します。

17.10.3. NSAPI コネクターがクライアントリクエストを JBoss EAP 6 に送信するよう設定

概要

このタスクでは、NSAPI コネクターが負荷分散やフェイルオーバーなしでクライアント要求を JBoss EAP 6 サーバーにリダイレクトするよう設定します。リダイレクトは、デプロイメントごとに(つまり URL ごとに)行われます。負荷分散の設定については、代わりに 「NSAPI コネクターがクライアントリクエストを複数の JBoss EAP 6 サーバーで分散するよう設定」 を参照してください。

前提条件

手順17.26 基本的な HTTP コネクターの設定

  1. JBoss EAP 6 サーバーにリダイレクトする URL パスを定義します。

    注記
    IPLANET_CONFIG/obj.conf では、前の行から継続する行以外は、行の最初にスペースを挿入しないでください。
    IPLANET_CONFIG/obj.conf ファイルを編集します。<Object name="default"> で始まるセクションを見つけ、一致する各 URL パターンを次のサンプルファイルで示された形式で追加します。文字列 jknsapi は、次の手順で定義される HTTP コネクターを示します。例は、ワイルドカードを使用したパターン一致を示しています。
    <Object name="default">
    [...]
    NameTrans fn="assign-name" from="/status" name="jknsapi"
    NameTrans fn="assign-name" from="/images(|/*)" name="jknsapi"
    NameTrans fn="assign-name" from="/css(|/*)" name="jknsapi"
    NameTrans fn="assign-name" from="/nc(|/*)" name="jknsapi"
    NameTrans fn="assign-name" from="/jmx-console(|/*)" name="jknsapi"
    </Object>
    
    Copy to Clipboard Toggle word wrap
  2. 各パスを提供するワーカーを定義します。

    IPLANET_CONFIG/obj.conf ファイルの編集を続行します。編集したセクションの終了タグのすぐ後に、</ Object> を追加します
    <Object name="jknsapi">
    ObjectType fn=force-type type=text/plain
    Service fn="jk_service" worker="worker01" path="/status"
    Service fn="jk_service" worker="worker02" path="/nc(/*)"
    Service fn="jk_service" worker="worker01"
    </Object>
    
    Copy to Clipboard Toggle word wrap
    上記の例では、URL パス /status への要求を worker01 という名前のワーカーにリダイレクトし、/nc/ の下にあるすべての URL パスを worker02 という名前のワーカーにリダイレクトします。3 行目は、前の行で一致しない jknsapi オブジェクトに割り当てられたすべての URL が worker01 に提供されることを示しています。
    ファイルを保存し、終了します。
  3. ワーカーとその属性を定義します。

    IPLANET_CONFIG/connectors/ ディレクトリーに workers.properties というファイルを作成します。以下の内容をそのファイルに貼り付けし、お使いの環境に合わせて変更します。
    # An entry that lists all the workers defined
    worker.list=worker01, worker02
    
    # Entries that define the host and port associated with these workers
    worker.worker01.host=127.0.0.1
    worker.worker01.port=8009
    worker.worker01.type=ajp13
    
    worker.worker02.host=127.0.0.100
    worker.worker02.port=8009
    worker.worker02.type=ajp13
    
    Copy to Clipboard Toggle word wrap
    workers.properties ファイルは Apache mod_jk と同じ構文を使用します。利用可能なオプションの詳細は、「Apache mod_jk ワーカーの設定リファレンス」 を参照してください。
    ファイルを保存し、終了します。
  4. iPlanet Web Server を再起動します。

    以下のコマンドを実行し、iPlanet Web Server を再起動します。
    IPLANET_CONFIG/../bin/stopserv
    IPLANET_CONFIG/../bin/startserv
    
    Copy to Clipboard Toggle word wrap

結果

iPlanet Web Server が、設定した URL へのクライアント要求を JBoss EAP 6 のデプロイメントに送信します。

概要

このタスクは、負荷分散設定でクライアントリクエストを JBoss EAP 6 サーバーに送信するように NSAPI コネクターを設定します。NSAPI コネクターを負荷分散のない単純な HTTP コネクターとして使用する場合は、「NSAPI コネクターがクライアントリクエストを JBoss EAP 6 に送信するよう設定」 を参照してください。

手順17.27 負荷分散のためコネクターを設定する

  1. JBoss EAP 6 サーバーにリダイレクトする URL パスを定義します。

    注記
    IPLANET_CONFIG/obj.conf では、前の行から継続する行以外は、行の最初にスペースを挿入しないでください。
    IPLANET_CONFIG/obj.conf ファイルを編集します。<Object name="default"> で始まるセクションを見つけ、一致する各 URL パターンを次のサンプルファイルで示された形式で追加します。文字列 jknsapi は、次の手順で定義される HTTP コネクターを示します。例は、ワイルドカードを使用したパターン一致を示しています。
    <Object name="default">
    [...]
    NameTrans fn="assign-name" from="/status" name="jknsapi"
    NameTrans fn="assign-name" from="/images(|/*)" name="jknsapi"
    NameTrans fn="assign-name" from="/css(|/*)" name="jknsapi"
    NameTrans fn="assign-name" from="/nc(|/*)" name="jknsapi"
    NameTrans fn="assign-name" from="/jmx-console(|/*)" name="jknsapi"
    NameTrans fn="assign-name" from="/jkmanager/*" name="jknsapi"   
    </Object>
    
    Copy to Clipboard Toggle word wrap
  2. 各パスを提供するワーカーを定義します。

    IPLANET_CONFIG/obj.conf ファイルの編集を続行します。前の手順で変更したセクションの終了タグ(</Object>)に直接、以下の新しいセクションを追加し、必要に応じて変更します。
    <Object name="jknsapi">
    ObjectType fn=force-type type=text/plain
    Service fn="jk_service" worker="status" path="/jkmanager(/*)"
    Service fn="jk_service" worker="router"
    </Object>
    
    Copy to Clipboard Toggle word wrap
    この jksnapi オブジェクトは、default オブジェクトの name="jksnapi" マッピングにマップされた各パスを提供するために使用されるワーカーノードを定義します。/jkmanager/* に一致する URL 以外のすべてが、router という名前のワーカーにリダイレクトされます。
  3. ワーカーとその属性を定義します。

    workers.properties という名前のファイルを IPLANET_CONFIG/connector/ で作成します。以下の内容をそのファイルに貼り付けし、お使いの環境に合わせて変更します。
    # The advanced router LB worker
    # A list of each worker
    worker.list=router,status
    
    # First JBoss EAP server
    # (worker node) definition.
    # Port 8009 is the standard port for AJP
    #
    
    worker.worker01.port=8009
    worker.worker01.host=127.0.0.1
    worker.worker01.type=ajp13
    worker.worker01.ping_mode=A
    worker.worker01.socket_timeout=10
    worker.worker01.lbfactor=3
    
    # Second JBoss EAP server
    worker.worker02.port=8009
    worker.worker02.host=127.0.0.100
    worker.worker02.type=ajp13
    worker.worker02.ping_mode=A
    worker.worker02.socket_timeout=10
    worker.worker02.lbfactor=1
    
    # Define the load-balancer called "router"
    worker.router.type=lb
    worker.router.balance_workers=worker01,worker02
    
    # Define the status worker
    worker.status.type=status
    
    Copy to Clipboard Toggle word wrap
    workers.properties ファイルは Apache mod_jk と同じ構文を使用します。利用可能なオプションの詳細は、「Apache mod_jk ワーカーの設定リファレンス」 を参照してください。
    ファイルを保存し、終了します。
  4. iPlanet Web Server 7.0 を再起動します。

    IPLANET_CONFIG/../bin/stopserv
    IPLANET_CONFIG/../bin/startserv
    
    Copy to Clipboard Toggle word wrap

結果

iPlanet Web Server は、設定した URL パターンを負荷分散設定の JBoss EAP 6 サーバーにリダイレクトします。

第18章 Messaging

18.1. はじめに

18.1.1. HornetQ

HornetQ は、Red Hat により開発されたマルチプロトコル非同期メッセージングシステムです。HornetQ は、サーバーに障害が発生した場合のメッセージの信頼性を保証するために、自動クライアントフェイルオーバーで高可用性(HA)を提供します。HornetQ は、負荷分散されたメッセージで柔軟なクラスタリングソリューションもサポートします。
HornetQ は JBoss EAP 6 の Java Message Service(JMS)プロバイダーで、メッセージングサブシステムとして設定されます。

18.1.2. 低速な HornetQ コンシューマーの処理

サーバー側のキュー(JMS トピックサブスクライバーなど)を持つ低速なコンシューマーは、ブローカーのパフォーマンスに大きな問題を引き起こす可能性があります。メッセージがコンシューマーのサーバー側のキューで構築されると、メモリーは一杯になり、ブローカーはページングモードになり、パフォーマンスに悪影響を及ぼす可能性があります。ただし、メッセージをすぐに確認しないコンシューマーをブローカーから切断できるように基準を設定できます。この場合、非永続的な JMS サブスクライバーの場合、ブローカーがサブスクリプションを削除し、そのメッセージすべてで有用なサーバーリソースを解放できます。

18.1.3. フェイルオーバー中のブロック呼び出しの処理

クライアントコードがサーバーへのブロック呼び出しにあり、実行を継続する応答を待つと、フェイルオーバーが発生すると、新しいセッションには、進行中の呼び出しに関する知識はありません。そうでないと、この呼び出しはハングし、到達しない応答を待つ可能性があります。
これを防ぐため、HornetQ は、JMS を使用する場合は javax.jms.JMSException をスローし、エラーコード HornetQException.UNBLOCKED のある HornetQException をスローすることにより、フェイルオーバー時に進行中のブロッキング呼び出しのブロックを解除します。この例外をキャッチし、必要に応じて操作を再試行するかどうかはクライアントコード次第です。
ブロック解除されるメソッドが commit()または prepare()の呼び出しである場合、トランザクションは自動的にロールバックされ、HornetQ は(JMS を使用する場合) javax.jms.TransactionRolledBackException をスローし、コア API を使用する場合はエラーコード HornetQException.TRANSACTION_ROLLED_BACK を設定して HornetQException をスローします。

18.1.4. トランザクションによるフェイルオーバーの処理

セッションがトランザクションであり、現在のトランザクションでメッセージがすでに送受信された場合、サーバーはフェイルオーバー中に送受信されたメッセージが失われていないことを確認できません。
そのため、トランザクションはロールバック専用としてマークされ、その後コミットしようとすると javax.jms.TransactionRolledBackException (JMS を使用している場合は)をスローし、コア API を使用する場合はエラーコード HornetQException.TRANSACTION_ROLLED_BACK を設定して HornetQException をスローします。
例外をキャッチし、必要に応じてクライアント側のローカルロールバックコードを実行するのはユーザー次第です。セッションを手動でロールバックする必要はありません。すでにロールバックされています。その後、ユーザーは同じセッションでトランザクション操作を再試行できます。
コミット呼び出しの実行中にフェイルオーバーが発生すると、前述したようにサーバーが応答を返さないため、ハングを防ぐために呼び出しのブロックを解除します。この場合、障害が発生する前にトランザクションのコミットがライブサーバーで実際に処理されたかどうかをクライアントが判断するのは容易ではありません。
これを修正するには、クライアントはトランザクションで重複検出を有効にし、呼び出しがブロック解除された後にトランザクション操作を再試行します。フェイルオーバー前にトランザクションが実際にライブサーバーで正常にコミットされた場合、トランザクションが再試行されると、重複検出により、トランザクションで再送信された永続メッセージがサーバーで無視され、それらが複数回送信されないようにします。
注記
ロールバック例外をキャッチして再試行すると、ブロックされていない呼び出しをキャッチし、重複検出を有効にすることで、1 回限りの配信保証は、メッセージに障害が発生した場合に提供でき、100% の損失や重複の保証が保証されます。

18.1.5. 非トランザクションセッションを使用したフェイルオーバーの処理

セッションがトランザクションではない場合、フェイルオーバー時にメッセージまたは確認応答が失われる可能性があります。
トランザクション以外のセッションに、1 回限りの配信保証を提供し、重複検出を有効にし、ブロック解除例外をキャッチします。

18.1.6. 接続失敗の通知

JMS は、接続障害の非同期に通知する標準メカニズムを提供します( java.jms.ExceptionListener )。ExceptionListener の詳細は、Oracle javax.jms Javadoc を参照してください。
HornetQ コア API は、org.hornet.core.client.SessionFailureListener クラスの形式で同様の機能も提供します。
JMS ExceptionListener または Core SessionFailureListener インスタンスは、接続が正常に失敗したか、再接続または再アタッチされたかどうかに関係なく、接続障害が発生した場合に常に HornetQ によって呼び出されます。

18.1.7. Java Messaging Service (JMS)

メッセージングシステムにより、異種システムを疎結合して、信頼性も高めることができます。Java Messaging Service(JMS)プロバイダーはトランザクションのシステムを使用して、変更をアトミックにコミットまたはロールバックします。Remote Procedure Call (RPC) パターンに基づいたシステムとは異なり、メッセージングシステムは、リクエストと応答の間に密接な関係がないパターンを渡す非同期メッセージを主に使用します。ほとんどのメッセージングシステムは request-response モードもサポートしますが、メッセージングシステムの主な機能ではありません。
メッセージングシステムはメッセージのコンシューマーからメッセージの送信者を切り離します。メッセージの送信者とコンシューマーは完全に独立しており、相互に何も知りません。これにより、柔軟に結合されたシステムを作成できます。多くの場合、大規模な企業ではメッセージングシステムを使用して、異種システムを結合するメッセージバスを実装します。メッセージバスは、Enterprise Service Bus(ESB)の中核を形成することがよくあります。メッセージバスを使用して異種システムを切り離すことで、システムを拡大し、より容易に適応させることができます。また、不安定な依存関係がないため、より柔軟に新しいシステムを追加したり、古いシステムを廃止したりできます。

18.1.8. サポートされているメッセージ形式

HornetQ は、以下のメッセージ形式に対応しています。
Message Queue パターン
Message Queue パターンでは、メッセージをキューに送信する必要があります。キューに入ると、通常、メッセージは永続化され、配信が保証されます。メッセージがキューを通過すると、メッセージングシステムはメッセージコンシューマーに配信します。メッセージコンシューマーは、処理後にメッセージの配信を確認します。
Message Queue パターンでは、ポイントツーポイントメッセージングと併用すると、複数のコンシューマーをキューに入れることが可能ですが、各メッセージは単一のコンシューマーのみが受信可能となります。
Publish-Subscribe パターン
Publish-Subscribe パターンにより、複数の送信者がサーバー上の単一のエンティティーにメッセージを送信できます。このエンティティーは、「トピック」と呼ばれることがよくあります。各トピックは、「サブスクリプション」と呼ばれる複数のコンシューマーによって参加できます。
各サブスクリプションは、トピックに送信されたすべてのメッセージのコピーを受け取ります。これは、各メッセージが単一のコンシューマーによってのみ消費される Message Queue パターンとは異なります。
永続的なサブスクリプションは、サブスクライバーが消費するまで、トピックに送信された各メッセージのコピーを保持します。これらのコピーは、サーバーの再起動時にも保持されます。非永続的なサブスクリプションは、それらを作成した接続のみを保持します。

18.2. トランスポートの設定

18.2.1. アクセプターおよびコネクター

HornetQ は、メッセージングシステムの主要な部分としてコネクターおよびアクセプターを使用します。

アクセプターおよびコネクター

acceptor
アクセプターは、HornetQ サーバーが受け入れる接続タイプを定義します。
connector
コネクターは、HornetQ サーバーに接続する方法を定義し、HornetQ クライアントによって使用されます。
一致するコネクターとアクセプターのペアが同じ JVM 内に存在するかどうかに応じて、2 タイプのコネクターとアクセプターが用意されています。

Invm および Netty

invm
invm は Intra Virtual Machine の省略形です。クライアントとサーバーの両方が同じ JVM で実行されている場合に使用することができます。
Netty
JBoss プロジェクトの名前。クライアントとサーバーが異なる JVM で実行されている場合に使用する必要があります。
HornetQ クライアントは、いずれかのサーバーのアクセプターと互換性のあるコネクターを使用する必要があります。Invm コネクターのみが Invm アクセプターに接続でき、netty コネクターのみが netty アクセプターに接続できます。コネクターとアクセプターはいずれも standalone.xml および domain.xml のサーバー上で設定されます。管理コンソールまたは管理 CLI を使用して定義できます。

18.2.2. Netty TCP の設定

Netty TCP は暗号化されていない単純な TCP ソケットベースのトランスポートです。Netty TCP は、古いブロッキング Java IO または非ブロッキング Java NIO を使用するよう設定できます。多くの同時接続でスケーラビリティーを向上するには、サーバー側で Java NIO を使用することが推奨されます。同時接続の数が Java 古い IO が少ないと、NIO よりもレイテンシーが良くなります。
Netty TCP は暗号化されていないため、信頼できないネットワーク上で接続を実行する場合には推奨されません。Netty TCP トランスポートでは、すべての接続がクライアント側から開始されます。

例18.1 デフォルトの EAP 設定からの Netty TCP の設定例

<connectors>
  <netty-connector name="netty" socket-binding="messaging"/>
  <netty-connector name="netty-throughput" socket-binding="messaging-throughput">
    <param key="batch-delay" value="50"/>
  </netty-connector>
  <in-vm-connector name="in-vm" server-id="0"/>
</connectors>
<acceptors>
  <netty-acceptor name="netty" socket-binding="messaging"/>
  <netty-acceptor name="netty-throughput" socket-binding="messaging-throughput">
    <param key="batch-delay" value="50"/>
    <param key="direct-deliver" value="false"/>
  </netty-acceptor>
  <in-vm-acceptor name="in-vm" server-id="0"/>
</acceptors>
Copy to Clipboard Toggle word wrap
設定例は、HornetQ の JBoss EAP 6 実装がアクセプターおよびコネクター設定でソケットバインディングを使用する方法を示しています。これは、HornetQ のスタンドアロンバージョンとは異なり、特定のホストおよびポートを宣言する必要があります。
下表は Netty TCP 設定プロパティーの説明になります。
Expand
表18.1 Netty TCP 設定プロパティー
プロパティー デフォルト 説明
batch-delay 0 ミリ秒 パケットをトランスポートに書き込む前に、HornetQ は batch-delay ミリ秒の最大書き込みを一括処理するよう設定できます。これにより、メッセージ転送の平均待ち時間が長くなり、非常に小さいメッセージのスループットの合計が増加します。
direct-deliver true メッセージがサーバーに到達し、待機しているコンシューマーに配信されると、デフォルトでは、メッセージが到達した同じスレッドで配信が実行されます。これにより、メッセージが比較的小さく、コンシューマーの数が少ない環境では適切な待ち時間になりますが、スループットと待ち時間は低減されます。スループットを最大限にする場合は、このプロパティーを「false」に設定します。
local-address [使用可能なローカルアドレス] Netty コネクターでは、リモートアドレスへの接続時にクライアントが使用するローカルアドレスを指定するために使用されます。ローカルアドレスが指定されていない場合、コネクターは利用可能なローカルアドレスを使用します。
local-port 0 Netty コネクターでは、リモートアドレスへの接続時にクライアントが使用するローカルポートを指定するために使用されます。local-port のデフォルト(0)が使用される場合、コネクターはシステムが一時ポートを取得できるようにします。有効なポートは 0 から 65535 です。
nio-remoting-threads -1 NIO を使用するように設定されている場合、デフォルトでは受信パケットを処理するために Runtime.getRuntime().availableProcessors()によって報告されるコア(またはハイパースレッド)の数の 3 倍のスレッドを使用します。この値をオーバーライドするには、スレッド数にカスタム値を設定します。
tcp-no-delay true true の場合、Nagle アルゴリズムが有効になります。このアルゴリズムによりネットワーク上で送信されるパケット数を減らすことで、TCP/IP ネットワークの効率を向上します。
tcp-send-buffer-size 32768 バイト このパラメーターは TCP が送信するバッファーのサイズ (バイト単位) を決定します。
tcp-receive-buffer-size 32768 バイト このパラメーターは TCP が受信するバッファーのサイズ (バイト単位) を決定します。
use-nio false true の場合、ノンブロッキング NIO が使用されます。false に設定された場合、古いブロッキング Java IO が使用されます。多くの同時接続を処理するには、非ブロッキング Java NIO を使用する必要があります。それ以外の場合は、古い(ブロッキング)IO になります。
use-nio-global-worker-pool false このパラメーターにより、すべての JMS 接続で Java スレッドの 1 つのプールが共有されます(各コネクションに独自のプールがあるわけではありません)。これは、オペレーティングシステムのプロセスの最大数を使い切らないようにするためのものです。
重要
use-nio を true に設定した場合には、use-nio-global-worker-pool パラメーターを使用して、マシンが多数の接続を作成するリスクを最小限に抑え、OutOfMemory エラーが発生する可能性があります。
<netty-connector name="netty" socket-binding="messaging">
   <param key="use-nio" value="true"/>
   <param key="use-nio-global-worker-pool" value="true"/>
</netty-connector>
Copy to Clipboard Toggle word wrap
注記
Netty TCP プロパティーはすべてのタイプのトランスポートに対して有効です。

18.2.3. Netty セキュアソケットレイヤー (SSL) の設定

Netty TCP は暗号化されていない単純な TCP ソケットベースのトランスポートです。Netty SSL は Netty TCP と似ていますが、SSL(Secure Sockets Layer)を使用して TCP 接続を暗号化することでセキュリティーを強化します。
警告
SSL コネクター/アクセプターでの SSLv3 プロトコルの使用は、「Poodle」の脆弱性により許可されませんでした。このプロトコルに接続する JMS クライアントは拒否されます。
次の例は、一方向 SSL の Netty 設定を示しています。
注記
以下のパラメーターのほとんどは、アクセプターおよびコネクターで使用できます。ただし、一部のパラメーターはアクセプターでのみ機能します。パラメーターの説明では、これらのパラメーターをコネクターとアクセプターで使用する際の違いを説明します。
<acceptors>
 <netty-acceptor name="netty" socket-binding="messaging"/>
   <param key="ssl-enabled" value="true"/>
   <param key="key-store-password" value="[keystore password]"/>
   <param key="key-store-path" value="[path to keystore file]"/>
 </netty-acceptor>
</acceptors>
Copy to Clipboard Toggle word wrap
Expand
表18.2 Netty SSL 設定プロパティー
プロパティー名 デフォルト 説明
ssl-enabled true SSL を有効にします。
key-store-password [キーストアのパスワード]
アクセプターで使用されると、サーバー側のキーストアのパスワードになります。
コネクターで使用されると、クライアント側のキーストアのパスワードになります。これは、2 通りの SSL(相互認証)を使用している場合にコネクターにのみ関係します。この値はサーバー上で設定できますが、ダウンロードしてクライアントで使用します。
key-store-path [キーストアファイルへのパス]
アクセプターで使用される場合、これはサーバーの証明書を保持するサーバー(自己署名または認証局によって署名されるかどうか)の SSL キーストアへのパスになります。
コネクターで使用される場合、これはクライアント証明書を保持するクライアント側の SSL キーストアへのパスとなります。これは、双方向 SSL(相互認証など)を使用している場合にコネクターにのみ関係します。この値はサーバー上で設定されますが、ダウンロードしてクライアントで使用します。
双方向 SSL (サーバーとクライアント間の相互認証) に Netty を設定する場合は、前述の一方向 SSL の例で説明したパラメーターの他に 3 つのパラメーターが使用されます。
  • need-client-auth: クライアント接続の双方向(相互認証)の必要性を指定します。
  • trust-store-password: アクセプターで使用されると、サーバー側のトラストストアのパスワードになります。コネクターで使用されると、クライアント側のトラストストアのパスワードになります。これは、一方向および双方向 SSL のコネクターに関連します。この値はサーバー上で設定できますが、ダウンロードしてクライアントで使用します。
  • trust-store-path: アクセプターで使用されると、サーバーが信頼するすべてのクライアントのキーを保持するサーバー側の SSL トラストストアへのパスになります。コネクターで使用される場合、これはクライアント側の SSL キーストアへのパスになります。これは、クライアントが信頼するすべてのサーバーの公開鍵を保持します。これは、一方向および双方向 SSL のコネクターに関連します。このパスはサーバー上で設定できますが、ダウンロードしてクライアントで使用します。

18.2.4. Netty HTTP の設定

Netty HTTP は HTTP プロトコル上でパケットをトンネリングします。これは、ファイアウォールが HTTP トラフィックのみを通過できるシナリオで役に立ちます。Netty HTTP は Netty TCP と同じプロパティーを使用し、以下の追加プロパティーを使用します。
注記
以下のパラメーターはアクセプターおよびコネクターで使用できます。Netty HTTP トランスポートは標準の HTTP ポートを再利用することを許可しません(デフォルトでは 8080)。標準の HTTP ポートを使用すると例外が発生します。標準の HTTP ポートを介して HornetQ 接続をトンネリングするのに 「Netty サーブレットの設定」 (Netty Servlet Transport)を使用できます。
<socket-binding name="messaging-http" port="7080" />
Copy to Clipboard Toggle word wrap
<acceptors>
  <netty-acceptor name="netty" socket-binding="messaging-http">
    <param key="http-enabled" value="false"/>
    <param key="http-client-idle-time" value="500"/>
    <param key="http-client-idle-scan-period" value="500"/>
    <param key="http-response-time" value="10000"/>
   	<param key="http-server-scan-period" value="5000"/>
   	<param key="http-requires-session-id" value="false"/>
  </netty-acceptor>
</acceptors>
Copy to Clipboard Toggle word wrap
下表は、Netty HTTP の設定に使用する追加プロパティーの説明になります。
Expand
表18.3 Netty HTTP 設定プロパティー
プロパティー名 デフォルト 説明
http-enabled false true の場合、HTTP が有効になります。
http-client-idle-time 500 ミリ秒 接続を維持するために空の HTTP 要求を送信する前にクライアントがアイドル状態でいられる期間。
http-client-idle-scan-period 500 ミリ秒 アイドル状態のクライアントに対してスキャンを行う頻度 (ミリ秒単位)。
http-response-time 10000 ミリ秒 接続を維持するために空の HTTP 応答を送信する前に、サーバーが待機できる期間。
http-server-scan-period 5000 ミリ秒 応答が必要なクライアントに対してスキャンを行う頻度 (ミリ秒単位)。
http-requires-session-id false true の場合、クライアントは最初の呼び出しの後にセッション ID を取得するため待機します。
警告
自動クライアントフェールオーバーは、Netty HTTP トランスポートを通じて接続しているクライアントに対してはサポートされません。

18.2.5. Netty サーブレットの設定

サーブレットトランスポートを使用すると、HTTP 経由で HornetQ トラフィックをサーブレットエンジンで稼働しているサーブレットにトンネリングし、インVM HornetQ サーバーへリダイレクトできます。Netty HTTP トランスポートは、特定ポートで HTTP トラフィックをリッスンする Web サーバーとして機能します。サーブレットトランスポートでは HornetQ トラフィックは、すでに Web サイトや他のアプリケーションを提供している可能性のあるサーブレットエンジンを介してプロキシーされます。
Netty サーブレットトランスポートが動作するようにサーブレットエンジンを設定するには、以下の手順に従います。
  • サーブレットをデプロイします。以下の例はサーブレットを使用する Web アプリケーションを表しています。
    <web-app>
      <servlet>
        <servlet-name>HornetQServlet</servlet-name>
        <servlet-class>org.jboss.netty.channel.socket.http.HttpTunnelingServlet</servlet-class>
        <init-param>
          <param-name>endpoint</param-name>
          <param-value>local:org.hornetq</param-value>
        </init-param>
          <load-on-startup>1</load-on-startup>
      </servlet>
    
      <servlet-mapping>
        <servlet-name>HornetQServlet</servlet-name>
        <url-pattern>/HornetQServlet</url-pattern>
      </servlet-mapping>
    </web-app>
    
    Copy to Clipboard Toggle word wrap
    init パラメーター エンドポイント は、サーブレットがパケットを転送する Netty アクセプターのホスト属性を指定します。
  • Netty サーブレットアクセプターをサーバー側の設定に挿入します。以下の例は、サーバー設定ファイル(standalone.xml および domain.xml)でのアクセプターの定義を示しています。
    <acceptors>
       <acceptor name="netty-servlet">
          <factory-class>
             org.hornetq.core.remoting.impl.netty.NettyAcceptorFactory
          </factory-class>
          <param key="use-servlet" value="true"/>
          <param key="host" value="org.hornetq"/>
       </acceptor>
    </acceptors>
    
    Copy to Clipboard Toggle word wrap
  • 最後に、サーバー設定ファイル(standalone.xml および domain.xml)でクライアントのコネクターを定義します。
    <netty-connector name="netty-servlet" socket-binding="http">
       <param key="use-servlet" value="true"/>
       <param key="servlet-path" value="/messaging/HornetQServlet"/>
    </netty-connector>
    
    Copy to Clipboard Toggle word wrap
  • また、以下の設定をコネクターに追加すると、サーブレットトランスポートを SSL 上でも使用できます。
    <netty-connector name="netty-servlet" socket-binding="https">
       <param key="use-servlet" value="true"/>
       <param key="servlet-path" value="/messaging/HornetQServlet"/>
       <param key="ssl-enabled" value="true"/>
       <param key="key-store-path" value="path to a key-store"/>
       <param key="key-store-password" value="key-store password"/>
    </netty-connector>
    
    Copy to Clipboard Toggle word wrap
警告
自動クライアントフェールオーバーは、HTTP トンネリングサーブレットを介して接続しているクライアントに対してはサポートされません。
注記
HornetQ クラスターの設定するために Netty サーブレットを使用して EAP 6 サーバーを設定することはできません。

18.3. デッド接続の検出

18.3.1. サーバーでデッド接続リソースを閉じる

HornetQ コアまたは JMS クライアントアプリケーションは、終了する前にそのリソースを閉じる必要があります。アプリケーションのコードで finally ブロックを使用すると、アプリケーションがリソースを自動的に閉じるように設定できます。
以下の例は、finally ブロックでセッションとセッションファクトリーを閉じるコアクライアントアプリケーションを示しています。
ServerLocator locator = null;
ClientSessionFactory sf = null;
ClientSession session = null;

try
{
   locator = HornetQClient.createServerLocatorWithoutHA(..);

   sf = locator.createClientSessionFactory();;

   session = sf.createSession(...);
   
   ... do some operations with the session...
}

finally
{
   if (session != null)
   {
      session.close();
   }
   
   if (sf != null)
   {
      sf.close();
   }

   if(locator != null)
   {
      locator.close();
   }
}
Copy to Clipboard Toggle word wrap
以下の例は、finally ブロックでセッションとセッションファクトリーを閉じる JMS クライアントアプリケーションを示しています。
Connection jmsConnection = null;

try
{
   ConnectionFactory jmsConnectionFactory = HornetQJMSClient.createConnectionFactoryWithoutHA(...);

   jmsConnection = jmsConnectionFactory.createConnection();

   ... do some operations with the connection...
}
finally
{
   if (connection != null)
   {
      connection.close();
   }
}
Copy to Clipboard Toggle word wrap

接続 Time to Live (TTL) パラメーターの使用

connection-ttl パラメーターは、クライアントからデータまたは ping パケットを受信しない場合に、サーバーが接続を存続する期間を決定します。このパラメーターにより、古いセッションなどのデッドサーバーリソースが長く維持され、障害が発生したネットワーク接続が復旧したときにクライアントが再接続できるようになります。

HornetQConnectionFactory インスタンスに connection-ttl パラメーターを指定すると、JMS クライアントの接続 TTL を定義できます。JMS 接続ファクトリーインスタンスを JNDI に直接デプロイする場合は、standalone.xml および domain.xml サーバー設定ファイルで connection-ttl パラメーターを定義できます。
connection-ttl パラメーターのデフォルト値は 60000 ミリ秒です。クライアントが独自の接続 TTL を指定する必要がない場合は、サーバー設定ファイルに connection-ttl-override パラメーターを定義して、すべての値を上書きできます。connection-ttl-override パラメーターはデフォルトで無効にされ、値が -1 になります。

ガベージコレクション

HornetQ はガベージコレクションを使用して、finally ブロックで明示的に閉じられていないセッションを検出し、閉じます。HornetQ サーバーは、セッションを閉じる前に以下のような警告をログに記録します。

[Finalizer] 20:14:43,244 WARNING [org.hornetq.core.client.impl.DelegatingSession]  I'm closing a ClientSession you left open. Please make sure you close all ClientSessions explicitly before let
ting them go out of scope!
[Finalizer] 20:14:43,244 WARNING [org.hornetq.core.client.impl.DelegatingSession]  The session you didn't close was created here:
java.lang.Exception
   at org.hornetq.core.client.impl.DelegatingSession.<init>(DelegatingSession.java:83)
   at org.acme.yourproject.YourClass (YourClass.java:666)
Copy to Clipboard Toggle word wrap
このログメッセージには、JMS 接続またはユーザーセッションが作成され、閉じられなかったコード部分に関する情報が含まれます。

18.3.2. クライアントサイド障害の検出

クライアントアプリケーションは、クライアントがシャットダウンしないように、ping パケットをサーバーに自動的に送信します。同様に、クライアントアプリケーションは、サーバーからデータを受信する限り、接続がアライブ状態であると見なします。
クライアントが client-failure-check-period パラメーターで指定された期間サーバーからデータパケットを受信しないと、クライアントは接続が失敗したと見なします。その後、クライアントはフェイルオーバーを開始するか、FailureListener インスタンスを起動します。
JMS クライアントでは、HornetQConnectionFactory インスタンスの ClientFailureCheckPeriod 属性を使用してクライアント障害チェック期間が設定されます。JMS 接続ファクトリーインスタンスをサーバー側の JNDI に直接デプロイする場合は、standalone.xml および domain.xml サーバー設定ファイルで client-failure-check-period パラメーターを指定できます。
クライアント障害チェック期間のデフォルト値は 30000 ミリ秒です。-1 の値は、サーバーからデータが受信されない場合、クライアントが接続を閉じないことを意味します。

非同期接続実行の設定

デフォルトでは、サーバー側で受信されるパケットはリモーティングスレッドで実行されます。スレッドプールからの任意のスレッドで操作を非同期に処理して、リモーティングスレッドを解放できます。standalone.xml および domain.xml サーバー設定ファイルの async-connection-execution-enabled パラメーターを使用して、非同期接続実行を設定できます。このパラメーターのデフォルト値は「true」です。

注記
スレッドプールから任意のスレッドで操作を非同期的に処理すると、待ち時間が少し追加されます。パフォーマンス上の理由から、短い実行操作は常にリモーティングスレッドで処理されます。

18.4. サイズの大きなメッセージの処理

18.4.1. サイズの大きなメッセージの処理

HornetQ は、クライアントまたはサーバーでメモリーのサイズが制限されていても、大きなメッセージの使用をサポートします。大きなメッセージは、そのままストリーミングしたり、より効率的な転送のためにさらに圧縮したりできます。ユーザーはメッセージのボディーに InputStream を設定すると、大きなメッセージを送信できます。メッセージが送信されると、HornetQ はこの InputStream を読み取り、データを断片的にサーバーに送信します。
クライアントまたはサーバーは、大きなメッセージのボディーをメモリーに保存しません。コンシューマーは、最初にボディーが空の大きなメッセージを受け取った後、メッセージに OutputStream を設定して、断片的にディスクファイルへストリーミングします。

18.4.2. HornetQ の大きなメッセージの設定

サーバーの設定

スタンドアロンモードでは、大きなメッセージは EAP_HOME/standalone/data/largemessages ディレクトリーに保存されます。ドメインモードでは、大きなメッセージは EAP_HOME/domain/servers/SERVERNAME/data/largemessages ディレクトリーに保存されます。設定プロパティー large-messages-directory は、大きなメッセージが保存される場所を示します。

重要
最良のパフォーマンスを得るため、大きなメッセージは、メッセージジャーナルやページングディレクトリーとは別の物理ボリュームに保存することが推奨されます。

18.4.3. パラメーターの設定

さまざまなパラメーターを設定して HornetQ の大きなメッセージを設定できます。
クライアント側での HornetQ Core API の使用
クライアント側で HornetQ Core API を使用している場合は、ServerLocator.setMinLargeMessageSize パラメーターを設定して大きなメッセージの最小サイズを指定する必要があります。大きなメッセージの最小サイズ(min-large-message-size)はデフォルトで 100KiB に設定されています。
ServerLocator locator = HornetQClient.createServerLocatorWithoutHA(new TransportConfiguration(NettyConnectorFactory.class.getName()))

locator.setMinLargeMessageSize(25 * 1024);

ClientSessionFactory factory = HornetQClient.createClientSessionFactory();

Copy to Clipboard Toggle word wrap
Java Messaging Service (JMS) クライアントに対するサーバーの設定
Java Messaging Service(JMS)を使用している場合は、サーバー設定ファイル(standalone.xml および domain.xml)の min-large-message-size 属性に大きなメッセージの最小サイズを指定する必要があります。大きなメッセージの最小サイズ(min-large-message-size)はデフォルトで 100KiB に設定されています。
注記
min-large-message-size 属性の値はバイト単位である必要があります。
高速かつ効率的な転送のために大きなメッセージを圧縮することを選択できます。圧縮/圧縮解除操作はすべてクライアント側で処理されます。圧縮されたメッセージが min-large-message-size よりも小さい場合、通常のメッセージとしてサーバーに送信されます。Java Messaging Service(JMS)を使用すると、サーバーロケーターまたは ConnectionFactory にブール値プロパティー compress-large-messages "true" を設定して大きなメッセージを圧縮できます。
<connection-factory name="ConnectionFactory">
   <connectors>
      <connector-ref connector-name="netty"/>
   </connectors>
...
   <min-large-message-size>204800</min-large-message-size>
   <compress-large-messages>true</compress-large-messages>
</connection-factory>

Copy to Clipboard Toggle word wrap

18.5. ページング

18.5.1. ページングについて

HornetQ は、各キューに数百万個のメッセージが含まれる多くのメッセージキューをサポートします。HornetQ サーバーは制限されたメモリーで実行されるため、すべてのメッセージキューを一度にメモリーに保存することは困難です。
ページングは HornetQ サーバーによって使用されるメカニズムで、限られたメモリーで大きなメッセージキューに対応するために、必要に応じてメッセージを透過的に出し入れします。
メモリーにある特定アドレスのメッセージのサイズが最大設定メッセージサイズを越えたとき、HornetQ はメッセージをディスクにページングします。
注記
HornetQ のページングはデフォルトで有効になっています。

18.5.2. ページファイル

複数のファイルにメッセージを格納するファイルシステムの各アドレスには、個別のフォルダーがあります。メッセージを格納するこれらのファイルは、ページファイルと呼ばれます。各ファイルには、最大設定メッセージサイズ(page-size-bytes)までのメッセージが含まれています。
システムは必要に応じてページファイルを移動して、ページのメッセージがすべてクライアントに受信されるとすぐにページファイルを削除します。
注記
コンシューマーがキューからメッセージを読み取るメッセージセレクターを持っている場合、セレクターに一致するメモリーのメッセージのみがコンシューマーに送信されます。コンシューマーがこれらのメッセージの配信を確認すると、新しいメッセージはページングされ、メモリーに読み込まれます。パフォーマンス上の理由から、HornetQ は、ページングされたメッセージをコンシューマーのメッセージセレクターと一致するかどうかを確認せず、新しいページ化されたメッセージがコンシューマーのメッセージセレクターと一致することを確認することはありません。ページファイルのディスクのコンシューマーのセレクターに一致するメッセージがありますが、別のコンシューマーがメモリーでメッセージを読み取り、空き領域を提供するまで、HornetQ はそれらをメモリーに読み込みません。空き領域が利用できない場合、セレクターを持つコンシューマーは新しいメッセージを受信できない可能性があります。

18.5.3. ページングフォルダーの設定

グローバルページングパラメーターはサーバー設定ファイル(standalone.xml および domain.xml)に指定されます。paging-directory パラメーターを使用して、ページングディレクトリー/フォルダーの場所を設定できます。
<hornetq-server>
 ...
 <paging-directory>/location/paging-directory</paging-directory>
 ...
</hornetq-server>
Copy to Clipboard Toggle word wrap
paging-directory パラメーターは、ページファイルを保存する場所/フォルダーを指定するために使用されます。HornetQ は、このページングディレクトリーの各ページングアドレスにフォルダーを作成します。ページファイルはこれらのフォルダーに保存されます。
デフォルトのページングディレクトリーは EAP_HOME/standalone/data/messagingpaging (スタンドアロンモード)と EAP_HOME/domain/servers/SERVERNAME/data/messagingpaging (ドメインモード)です。

18.5.4. ページングモード

アドレスに送信されたメッセージが設定サイズを越える場合は、そのアドレスが「ページ/ページングモード」になります。
備考
ページングはアドレスごとに個別に行われます。アドレスに max-size-bytes を設定する場合は、一致する各アドレスに指定した最大サイズがあることを意味します。ただし、一致するすべてのアドレスの合計サイズが max-size-bytes に制限されるわけではありません。
page モードであっても、メモリー不足によるエラーが原因でサーバーがクラッシュする可能性があります。HornetQ は、ディスク上の各ページファイルへの参照を保持します。ページファイルが非常に多い状況では、HornetQ はメモリーの消費に直面する可能性があります。このリスクを最小限に抑えるには、page-size-bytes 属性を適切な値に設定することが重要です。JBoss EAP 6 サーバーのメモリーを( 宛先の数)*(max-size-bytes) より高く設定する必要があります。そうでないと、メモリー不足のエラーが発生する可能性があります。
サーバー設定ファイル(standalone.xml および domain.xml)のアドレスの最大サイズをバイト単位で設定できます(max-size-bytes)。
<address-settings>
   <address-setting match="jms.someaddress">
      <max-size-bytes>104857600</max-size-bytes>
      <page-size-bytes>10485760</page-size-bytes>
      <address-full-policy>PAGE</address-full-policy>
   </address-setting>
</address-settings>
Copy to Clipboard Toggle word wrap
以下の表には、アドレス設定のパラメーターをまとめています。
Expand
表18.4 ページングアドレス設定
要素 デフォルト値 説明
max-size-bytes 10485760
ページングモードになる前にアドレスが取得できる最大メモリーサイズを指定します。
page-size-bytes 2097152
これは、ページングシステムで使用される各ページファイルのサイズを指定するために使用されます。
address-full-policy PAGE
この属性の値は、ページングの決定に使用されます。この属性の値のいずれかを設定できます: PAGE: ページングを有効にし、設定された制限を超えたメッセージをディスクに指定するには、DROP: 設定された制限を超えるメッセージを警告なしで破棄するには、FAIL: FAIL: メッセージをドロップし、クライアントメッセージプロデューサーに例外を送信するには、BLOCK: クライアントメッセージプロデューサーがセット制限を超えるメッセージを送信するときにブロックします。
page-max-cache-size 5
システムは、ページングナビゲーション中に入出力を最適化するために、メモリーに最大 page-max-cache-size のページファイルを維持します。
重要
最大サイズに達したときにメッセージをページングしたくない場合は、address-full-policy をそれぞれ DROP に設定することで、メッセージをドロップしたり、クライアント側で例外のあるメッセージをドロップしたり、プロデューサーが追加のメッセージを送信しないようにブロックしたりすることを選択できます。 デフォルト設定では、アドレスが max-size-bytes に達すると、すべてのアドレスがメッセージのページングに設定されます。

複数のキューを持つアドレス

複数のキューがバインドされているアドレスにメッセージがルーティングされると、メッセージのコピーはメモリー内に 1 つだけあります。各キューは、このメッセージの元のコピーへの参照のみを処理します。したがって、メモリーは、元のメッセージを参照するすべてのキューがメッセージを配信した場合にのみ解放されます。

備考
単一のレイジーキュー/サブスクリプションによって、アドレス全体の入出力のパフォーマンスが軽減されることがあります。これは、ページングシステム上の追加ストレージから送信されたメッセージがすべてのキューにあるためです。

18.6. Diverts

迂回は HornetQ で設定されるオブジェクトです。メッセージをあるアドレス(メッセージがルーティングされる)から他のアドレスに迂回するのに役立ちます。迂回はサーバー設定ファイル(standalone.xml および domain.xml)で設定できます。
迂回は、以下のタイプに分類できます。
  • 特別な迂回: メッセージは新しいアドレスにのみ迂回され、古いアドレスには送信されません
  • 特別でない迂回: メッセージは古いアドレスに引き続き送信され、そのコピーは新しいアドレスに送信されます。特別でない迂回はメッセージのフローを分割するために使用できます。
迂回は、トランスフォーマーとオプションのメッセージフィルターを適用するように設定できます。オプションのメッセージフィルターは、指定されたフィルターに一致するメッセージのみを迂回するのに役立ちます。トランスフォーマーは、メッセージを別のフォームに変換するために使用されます。トランスフォーマーが指定されている場合、迂回されたメッセージはすべて トランスフォーマー によって変換されます。
迂回により、メッセージは同じサーバー内のアドレスにのみ迂回されます。別のサーバーのアドレスにメッセージを迂回する必要がある場合は、以下で説明されているパターンに従います。
  • メッセージをローカルストアと転送キューに迂回します。そのキューから消費して別のサーバーのアドレスにメッセージを送信するブリッジを設定
迂回とブリッジを組み合わせてさまざまなルーティングを作成できます。

18.6.1. 特別な迂回

特別な迂回により、すべてのメッセージを古いアドレスから新しいアドレスに迂回します。一致するメッセージは古いアドレスにルーティングされません。standalone.xml および domain.xml サーバー設定ファイルに exclusive 属性を true に設定すると、特別な迂回を有効にすることができます。
以下の例は、サーバー設定ファイルで設定された特別な迂回を示しています。
<divert name="prices-divert">
   <address>jms.topic.priceUpdates</address>
   <forwarding-address>jms.queue.priceForwarding</forwarding-address>
   <filter string="office='New York'"/>
   <transformer-class-name>
      org.hornetq.jms.example.AddForwardingTimeTransformer
   </transformer-class-name>
   <exclusive>true</exclusive>
</divert>
Copy to Clipboard Toggle word wrap
以下のリストは、上記の例で使用された属性を示しています。
  • アドレス: このアドレスに送信されたメッセージは別のアドレスに迂回されます。
  • forwarding-address: メッセージは古いアドレスからこのアドレスに迂回されます。
  • filter-string: filter-string 値に一致するメッセージは迂回されます。その他のメッセージはすべて通常のアドレスにルーティングされます。
  • transformer-class-name: このパラメーターを指定すると、一致する各メッセージの変換が実行されます。これにより、迂回する前にメッセージのボディーまたはプロパティーを変更できます。
  • 排他的: 特別な 迂回を有効または無効にするために使用されます。

18.6.2. 特別でない迂回

特別でない迂回は、元のメッセージのコピーを新しいアドレスに転送します。元のメッセージは古いアドレスに到達し続けます。standalone.xml および domain.xml サーバー設定ファイルで exclusive プロパティーを false に設定すると、特別でない迂回を設定できます。
以下の例は、特別でない迂回を示しています。
<divert name="order-divert">
  <address>jms.queue.orders</address>
  <forwarding-address>jms.topic.spyTopic</forwarding-address>
  <exclusive>false</exclusive>
</divert>
Copy to Clipboard Toggle word wrap
上記の例では、jms.queue.orders アドレスに送信されたすべてのメッセージのコピーを作成し、jms.topic.spyTopic アドレスに送信します。

18.7. クライアントクラスパス

HornetQ では、クライアントが HornetQ Core API、JMS、または JNDI を使用するかどうかに応じて、クライアントクラスパスにいくつかの jar が必要です。
警告
ここに記載されている jar はすべて HornetQ ディストリビューションの EAP_HOME/bin/client ディレクトリーにあります。リリースの正しいバージョンの jar のみを使用するようにしてください。異なる HornetQ バージョンからバージョンの jar を混在させたり、一致させたりしないでください。異なる jar バージョンの混在と一致により、少しエラーが発生してエラーが発生する可能性があります。
クライアントクラスパスを設定するには、EAP_HOME/bin/client/jboss-client.jar を追加します。EAP_HOME/bin/client/README-EJB-JMS.txt の説明どおりに、Maven の依存関係設定を使用することもできます。

18.8. 設定

18.8.1. JMS サーバーの設定

HornetQ に JMS サーバーを設定するには、サーバー設定ファイルを編集します。サーバー設定は、ドメインサーバーの EAP_HOME/domain/configuration/domain.xml ファイル、スタンドアロンサーバーの EAP_HOME/standalone/configuration/standalone-full.xml ファイルに含まれます。
サーバー設定ファイルの < subsystem xmlns="urn:jboss:domain:messaging:1.4 "> 要素にはすべての JMS 設定が含まれます。JNDI に必要な JMS ConnectionFactoryQueue、または Topic インスタンスを追加します。
  1. JBoss EAP 6 で JMS サブシステムを有効にします。

    要素内に <extensions> 以下の行が存在し、コメントアウトされていないことを確認します。
    <extension module="org.jboss.as.messaging"/>
    Copy to Clipboard Toggle word wrap
  2. 基本の JMS サブシステムを追加します。

    メッセージングサブシステムが設定ファイルに存在しない場合は、追加します。
    1. 使用する プロファイルに対応する &lt;profile> を検索し、その < subsystems> タグを 見つけます。
    2. < profile> タグの直後に以下の XML を 貼り付けます。
      <subsystem xmlns="urn:jboss:domain:messaging:1.4">
          <hornetq-server>
          <!-- ALL XML CONFIGURATION IS ADDED HERE -->
          </hornetq-server>
      </subsystem>
      Copy to Clipboard Toggle word wrap
      その他の設定はすべて、その上の空いている行に追加します。
  3. JMS の基本設定を追加します。

    < subsystem xmlns="urn:jboss:domain:messaging:1.4"> <hornetq-server > タグの後に空の行に以下の XML を追加します。
    <journal-min-files>2</journal-min-files>
    <journal-type>NIO</journal-type>
    <persistence-enabled>true</persistence-enabled>
    Copy to Clipboard Toggle word wrap
    ニーズに合わせて上記の値を変更します。
    警告
    journal-file-size の値は min-large-message-size (デフォルトでは 100KiB)以上の値である必要があります。そうでないと、サーバーはメッセージを保存できません。
  4. HornetQ に接続ファクトリーインスタンスを追加します。

    クライアントは JMS ConnectionFactory オブジェクトを使用してサーバーに接続します。JMS 接続ファクトリーオブジェクトを HornetQ に追加するには、以下のように各接続ファクトリーに単一の < jms-connection-factories > タグと < connection-factory > 要素が含まれます。
      <jms-connection-factories>
        <connection-factory name="InVmConnectionFactory">
            <connectors>
                <connector-ref connector-name="in-vm"/>
            </connectors>
            <entries>
                <entry name="java:/ConnectionFactory"/>
            </entries>
        </connection-factory>
        <connection-factory name="RemoteConnectionFactory">
            <connectors>
                <connector-ref connector-name="netty"/>
            </connectors>
            <entries>
                <entry name="java:jboss/exported/jms/RemoteConnectionFactory"/>
            </entries>
        </connection-factory>
        <pooled-connection-factory name="hornetq-ra">
            <transaction mode="xa"/>
            <connectors>
                <connector-ref connector-name="in-vm"/>
            </connectors>
            <entries>
                <entry name="java:/JmsXA"/>
            </entries>
        </pooled-connection-factory>
    </jms-connection-factories>
    
    Copy to Clipboard Toggle word wrap
  5. netty コネクターおよびアクセプターの設定

    この JMS 接続ファクトリーは netty アクセプターおよびコネクターを使用します。これらは、サーバー設定ファイルにデプロイされたコネクターおよびアクセプターオブジェクトへの参照です。コネクターオブジェクトは、HornetQ サーバーへの接続に使用されるトランスポートとパラメーターを定義します。アクセプターオブジェクトは、HornetQ サーバーが受け入れる接続タイプを識別します。
    Netty コネクターを設定する は、以下の設定を追加します。
    <connectors>
        <netty-connector name="netty" socket-binding="messaging"/>
        <netty-connector name="netty-throughput" socket-binding="messaging-throughput">
            <param key="batch-delay" value="50"/>
        </netty-connector>
        <in-vm-connector name="in-vm" server-id="0"/>
    </connectors>
    
    Copy to Clipboard Toggle word wrap
    netty アクセプターを設定するには、以下の設定を追加します。
    <acceptors>
        <netty-acceptor name="netty" socket-binding="messaging"/>
        <netty-acceptor name="netty-throughput" socket-binding="messaging-throughput">
            <param key="batch-delay" value="50"/>
            <param key="direct-deliver" value="false"/>
        </netty-acceptor>
        <in-vm-acceptor name="in-vm" server-id="0"/>
    </acceptors>
    
    Copy to Clipboard Toggle word wrap
  6. 設定を確認します。

    これまでの手順に従った場合、メッセージサブシステムは以下のようになるはずです。
    <subsystem xmlns="urn:jboss:domain:messaging:1.4">
        <hornetq-server>
            <journal-min-files>2</journal-min-files>
            <journal-type>NIO</journal-type>
            <persistence-enabled>true</persistence-enabled>
            <jms-connection-factories>
                <connection-factory name="InVmConnectionFactory">
                    <connectors>
                        <connector-ref connector-name="in-vm"/>
                    </connectors>
                    <entries>
                        <entry name="java:/ConnectionFactory"/>
                    </entries>
                </connection-factory>
                <connection-factory name="RemoteConnectionFactory">
                    <connectors>
                        <connector-ref connector-name="netty"/>
                    </connectors>
                    <entries>
                        <entry name="java:jboss/exported/jms/RemoteConnectionFactory"/>
                    </entries>
                </connection-factory>
                <pooled-connection-factory name="hornetq-ra">
                    <transaction mode="xa"/>
                    <connectors>
                        <connector-ref connector-name="in-vm"/>
                    </connectors>
                    <entries>
                        <entry name="java:/JmsXA"/>
                    </entries>
                </pooled-connection-factory>
            </jms-connection-factories>
            <connectors>
                <netty-connector name="netty" socket-binding="messaging"/>
                <netty-connector name="netty-throughput" socket-binding="messaging-throughput">
                    <param key="batch-delay" value="50"/>
                </netty-connector>
                <in-vm-connector name="in-vm" server-id="0"/>
            </connectors>	
            <acceptors>
                <netty-acceptor name="netty" socket-binding="messaging"/>
                <netty-acceptor name="netty-throughput" socket-binding="messaging-throughput">
                    <param key="batch-delay" value="50"/>
                    <param key="direct-deliver" value="false"/>
                </netty-acceptor>
                <in-vm-acceptor name="in-vm" server-id="0"/>
            </acceptors>
        </hornetq-server>
    </subsystem>
    
    Copy to Clipboard Toggle word wrap
  7. ソケットバインディンググループを設定します。

    Netty コネクターはメッセージングおよび messaging -throughput ソケットバインディングを参照します。メッセージング ソケットバインディングはポート 5445 を使用し、messaging-throughput ソケットバインディングはポート 5455 を使用します。 & lt;socket-binding-group&gt; タグはサーバー設定ファイルの個別のセクションにあります。<socket -binding-groups> 要素に以下のソケットバインディングがあることを確認 します。
    <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
        ...
        <socket-binding name="messaging" port="5445"/>
        <socket-binding name="messaging-throughput" port="5455"/>
        ...
      </socket-binding-group>
    
    Copy to Clipboard Toggle word wrap
  8. キューインスタンスを HornetQ への追加します。

    HornetQ 向けにキューインスタンス (または JMS 宛先) を設定する方法は 4 つあります。
    • 管理コンソールの使用
      管理コンソールを使用するには、Message-Enabled モードでサーバーを起動している必要があります。これは、-c オプションを使用して、standalone-full.xml (スタンドアロンサーバーの場合)設定ファイルの使用を強制することで実行できます。たとえば、スタンドアロンモードでは、以下はメッセージ enabled モードでサーバーを起動します。
      ./standalone.sh -c standalone-full.xml
      Copy to Clipboard Toggle word wrap
      サーバーが起動したら、管理コンソールにログインして Configuration タブを選択します。Subsystems メニューを展開し、Messaging メニューを展開し、Destinations をクリックします。JMS Messaging Provider テーブルの Default の横にある 表示 をクリックし、Add をクリックして JMS 宛先の詳細を入力します。
    • 管理 CLI の使用:
      最初に、管理 CLI へ接続します。
       bin/jboss-cli.sh --connect
      Copy to Clipboard Toggle word wrap
      次に、メッセージングサブシステムに移動します。
      cd /subsystem=messaging/hornetq-server=default
      Copy to Clipboard Toggle word wrap
      最後に、add 操作を実行します。以下の例の値は独自の値に置き換えてください。
      ./jms-queue=testQueue:add(durable=false,entries=["java:jboss/exported/jms/queue/test"])
      Copy to Clipboard Toggle word wrap
    • JMS 設定ファイルの作成および deployments フォルダーへの追加
      JMS 設定ファイル example-jms.xml を作成して開始します。以下のエントリーを追加し、値を独自の値に置き換えます。
      <?xml version="1.0" encoding="UTF-8"?>				  	  <messaging-deployment xmlns="urn:jboss:messaging-deployment:1.0">
          <hornetq-server>
              <jms-destinations>
                  <jms-queue name="testQueue">
                      <entry name="queue/test"/>
                      <entry name="java:jboss/exported/jms/queue/test"/>
                  </jms-queue>
                  <jms-topic name="testTopic">
                      <entry name="topic/test"/>
                      <entry name="java:jboss/exported/jms/topic/test"/>
                  </jms-topic>
              </jms-destinations>
          </hornetq-server>
      </messaging-deployment>
      Copy to Clipboard Toggle word wrap
      このファイルを deployments フォルダーに保存し、デプロイメントを実行します。
    • JBoss EAP 6 の設定ファイルにエントリーを追加します。
      キュー属性は 2 つの方法で設定できます。
      • JMS レベルの設定
        以下は、standalone.xml または domain.xml 設定ファイルで事前定義されたキューを示しています。
        <jms-queue name="selectorQueue">
        	<entry name="/queue/selectorQueue"/>
        	<selector string="color='red'"/>
        	<durable>true</durable>
        </jms-queue>
        Copy to Clipboard Toggle word wrap
        queue のこの name 属性はキューの名前を定義します。jms レベルでこれを行う場合、コアキューの実際の名前が jms.queue.selectorQueue になるように命名規則に従います。
        entry 要素は、キューを JNDI にバインドするために使用される名前を設定します。これは必須要素であり、キューには複数のものを含めることができ、同じキューを異なる名前にバインドできます。
        selector 要素は、事前定義されたキューが持つ JMS メッセージセレクターを定義します。セレクターに一致するメッセージのみがキューに追加されます。これは、省略した場合のデフォルト null を持つオプションの要素です。
        durable 要素はキューを永続化するかどうかを指定します。これは再度オプションであり、省略されている場合はデフォルトで true に設定されます。
      • コアレベルでの設定
        キューは、standalone.xml または domain.xml ファイルのコアレベルで事前定義できます。以下に例を示します。
        <core-queues>
        	<queue name="jms.queue.selectorQueue">
        		<address>jms.queue.selectorQueue</address>
        		<filter string="color='red'"/>
        		<durable>true</durable>
        	</queue>
        </core-queues>
        Copy to Clipboard Toggle word wrap
  9. 追加の設定を実行します。

    追加の設定が必要な場合は、EAP_HOME/docs/schema/jboss-as-messaging_1_4.xsd の DTD を確認します。

18.8.2. JMS アドレスの設定

JMS サブシステムには、メッセージの配信方法およびタイミング、試行回数、メッセージの有効期限などの側面を制御するいくつかの設定可能なオプションがあります。これらの設定オプションはすべて、< address-settings > 設定要素内に存在します。
アドレス設定の一般的な機能は、ワイルドカードとも呼ばれる複数のアドレスに一致する構文です。

ワイルドカード構文

アドレスワイルドカードを使用すると、1 つのステートメントで複数の同様のアドレスを照合できます。これは、システムがアスタリスク( *)文字を使用して 1 つの検索で複数のファイルまたは文字列を照合するのと似ています。以下の文字はワイルドカードステートメントに特別な意味を持ちます。

Expand
表18.5 JMS ワイルドカード構文
文字 説明
. (シングルピリオド) ワイルドカード式で単語と単語の間を示す。
# (ポンドまたはハッシュ記号) 0 個以上の連続する単語に相当する。
* (アスタリスク) 1 つの単語と一致します。
Expand
表18.6 JMS ワイルドカードの例
説明
news.europe.#
news.europenews.europe.sportnews.europe.politic と一致しますが、news.usaeurope は一致しない。
news.*
news.europe と一致しますが、news.europe.sport は一致しない。
news.*.sport
news.europe.sportnews.usa.sport と一致しますが、news.europe.politics は一致しない。

例18.2 デフォルトアドレス設定

この例の値は、このトピックの残りを説明するために使用されます。
<address-settings>
    <!--default for catch all-->
    <address-setting match="#">
        <dead-letter-address>jms.queue.DLQ</dead-letter-address>
        <expiry-address>jms.queue.ExpiryQueue</expiry-address>
        <redelivery-delay>0</redelivery-delay>
        <max-size-bytes>10485760</max-size-bytes>
        <address-full-policy>BLOCK</address-full-policy>
        <message-counter-history-day-limit>10</message-counter-history-day-limit>
    </address-setting>
</address-settings>
Copy to Clipboard Toggle word wrap
Expand
表18.7 JMS アドレス設定の説明
要素 説明 デフォルト値 Type
address-full-policy
max-size-bytes が指定されたアドレスが満杯の場合に何が起こるかを決定します。
PAGE
STRING
dead-letter-address
デッドレターアドレスが指定された場合、max-delivery-attempts 配信試行に失敗した場合、メッセージはデッドレターアドレスに移動します。それ以外の場合、これらの未配信メッセージは破棄されます。ワイルドカードは許可されます。
jms.queue.DLQ
STRING
expiry-address
期限切れアドレスが存在する場合、期限切れのメッセージは破棄されずに、一致するアドレスに送信されます。ワイルドカードは許可されます。
jms.queue.ExpiryQueue
STRING
last-value-queue
キューが最後の値のみを使用するかどうかを定義します。
false
BOOLEAN
max-delivery-attempts
メッセージを dead-letter-address に送信するか、破棄する前にメッセージを再配信する最大回数。
10
INT
max-size-bytes
最大バイトサイズ。
10485760L
LONG
message-counter-history-day-limit
メッセージカウンター履歴の日数制限。
10
INT
page-max-cache-size
ページングナビゲーション中に IO を最適化するためにメモリー内に保持するページファイルの数。
5
INT
page-size-bytes
ページングサイズ。
5
INT
redelivery-delay
メッセージの再配信試行間の遅延時間(ミリ秒単位)。0 に設定すると、再配信が無限に試行されます。
0L
LONG
redistribution-delay
メッセージを再配信する前に最後のコンシューマーがキューで閉じられたときの待機時間を定義します。
-1L
LONG
send-to-dla-on-no-route
キューにルーティングされず、そのアドレスに指定された無効なレターアドレス (DLA) に送信されたメッセージの条件を設定するアドレスのパラメーター。
false
BOOLEAN
slow-consumer-threshold
コンシューマーが「低速」とみなされる前に許可されるメッセージ消費の最小レート。 1 秒あたりのメッセージで測定されます。
-1
INT
slow-consumer-policy
低速なコンシューマーが検出されたときに何が起こるか。KILL はコンシューマーの接続を強制終了します(これは、同じ接続を使用する他のクライアントスレッドに明らかに影響を与えます)。NOTIFY は、アプリケーションが対応してアクションを実行できる CONSUMER_SLOW 管理通知を送信します。
STRING
slow-consumer-check-period
特定のキューで低速なコンシューマーをチェックする頻度。測定(秒単位)。
5
INT
  • アドレス設定とパターン属性の設定

    管理 CLI または管理コンソールを選択して、必要に応じてパターン属性を設定します。
    • 管理 CLI を使用したアドレス設定

      管理 CLI を使用してアドレスを設定します。
      1. 新しいパターンの追加

        必要に応じて add 操作を使用して新規アドレス設定を作成します。管理 CLI セッションのルートからこのコマンドを実行できます。以下の例では、patternname という名前の新しいパターンを作成し、max-delivery-attempts 属性を 5 として宣言します。完全な プロファイルで編集しているスタンドアロンサーバーと管理対象ドメインの両方の例が表示されます。
        [standalone@localhost:9999 /] /subsystem=messaging/hornetq-server=default/address-setting=patternname/:add(max-delivery-attempts=5)
        Copy to Clipboard Toggle word wrap
        [domain@localhost:9999 /] /profile=full/subsystem=messaging/hornetq-server=default/address-setting=patternname/:add(max-delivery-attempts=5)
        Copy to Clipboard Toggle word wrap
      2. パターン属性の編集

        書き込み 操作を使用して、新しい値を属性に書き込みます。タブ補完を使用すると、入力時のコマンド文字列の補完に役立つほか、利用可能な属性を明らかにできます。以下の例は、max-delivery-attempts の値を 10に更新します。
        [standalone@localhost:9999 /] /subsystem=messaging/hornetq-server=default/address-setting=patternname/:write-attribute(name=max-delivery-attempts,value=10)
        Copy to Clipboard Toggle word wrap
        [domain@localhost:9999 /] /profile=full/subsystem=messaging/hornetq-server=default/address-setting=patternname/:write-attribute(name=max-delivery-attempts,value=10)
        Copy to Clipboard Toggle word wrap
      3. パターン属性の確認

        値が変更されたことを確認するには、include-runtime=true パラメーターを指定して read-resource 操作を実行し、サーバーモデルでアクティブな現在の値をすべて公開します。
        [standalone@localhost:9999 /] /subsystem=messaging/hornetq-server=default/address-setting=patternname/:read-resource
        Copy to Clipboard Toggle word wrap
        [domain@localhost:9999 /] /profile=full/subsystem=messaging/hornetq-server=default/address-setting=patternname/:read-resource
        Copy to Clipboard Toggle word wrap
    • 管理コンソールを使用したアドレスの設定

      管理コンソールを使用してアドレスを設定します。
      1. 管理対象ドメインまたはスタンドアロンサーバーの管理コンソールにログインします。
      2. 画面上部の Configuration タブを選択します。ドメインモードの場合は、左上の Profile メニューからプロファイルを選択します。full および full-ha プロファイルのみが messaging サブシステムが有効になっています。
      3. Messaging メニューを展開し、Destinations を選択します。
      4. JMS プロバイダーの一覧が表示されます。デフォルト設定では、default という 1 つのプロバイダーのみが表示されます。View をクリックして、このプロバイダーの詳細な設定を表示します。
      5. Address Settings タブをクリックします。Add をクリックして新しいパターンを追加するか、既存のパターンを選択してEdit をクリックして設定を更新します。
      6. 新しいパターンを追加する場合、Pattern フィールドは address-setting 要素の match パラメーターを参照します。デッドレターアドレス、Expiry Address Redelivery Delay、および Max Delivery Attempts を編集することもできます。その他のオプションは、管理 CLI を使用して設定する必要があります。

18.8.3. 一時キューとランタイムキュー

リクエストを送信して応答を待つクライアントを含むリクエストリプライシナリオを設計しますが、アドレス指定可能な問題は、クライアントの各ランタイムインスタンスが応答専用のキューを持っているか、ランタイムインスタンスが共有キューにアクセスするかどうかに関わらず、適切な属性に基づいて特定の応答メッセージを選択します。複数のキューが必要な場合、クライアントで使用するために動的にキューを作成する機能が必要で、JMS は一時キューの概念を使用してこの機能を提供します。TemporaryQueue は、QueueSession がリクエストに作成され、QueueConnectionQueueConnection が閉じられるまで)が削除されるまで存在します。つまり、TemporaryQueue は特定の QueueSession によって作成されますが、同じ QueueConnection から作成されるその他の Queue Session で再利用でき、QueueReceiver を作成できます。
応答に共有キューを持つか、個別の一時キューを持つトレードオフは、アクティブなクライアントインスタンスの潜在的な数に影響されます。共有キューアプローチでは、一部のプロバイダー固有のしきい値で、キューへのアクセスの競合が懸念される可能性があります。これは、実行時にキューストレージを作成するプロバイダーに関連する追加のオーバーヘッドと、多数の一時キューをホストする必要があるマシンメモリーへの影響を比較する必要があります。
注記
一時キューの作成は、createTemporaryQueue メソッドで実行できます。同様に、createTemporaryTopic メソッドを使用して一時トピックを作成します。これらのメソッドは、共に物理キューと物理トピックを作成します。
QueueSession が終了したときに受信され、確認されていないメッセージがある場合は、これらのメッセージは保持され、コンシューマーが次にキューにアクセスするときに再配信されます。QueueSession は、Point toPoint 固有のオブジェクトを作成するために使用されます。一般的には、Session オブジェクトを使用します。QueueSession は既存のコードをサポートするために使用されます。Session オブジェクトを使用するとプログラミングモデルが簡素化され、トランザクションを 2 つのメッセージングドメイン全体で使用できるようになります。
TopicSession は、Pub/Sub 固有のオブジェクトを作成するために使用されます。通常、Session オブジェクトを使用し、TopicSession のみを使用して既存のコードをサポートします。Session オブジェクトを使用するとプログラミングモデルが簡素化され、トランザクションを 2 つのメッセージングドメイン全体で使用できるようになります。

18.8.4. last-Value キュー

last-Value キューは、明確に定義された Last-Value プロパティーと同じ値の新しいメッセージがキューに置かれると、メッセージを破棄する特殊なキューです。つまり、last-Value キューは最後の値のみを保持します。Last-Value キューの典型的な例は、株式価格で、特定の株式の最新値のみが対象となります。

last-Value キューの設定

last-value キューは address-setting 設定で定義されます。

<address-setting match="jms.queue.lastValueQueue">
	<last-value-queue>true</last-value-queue>
</address-setting>
Copy to Clipboard Toggle word wrap

last-Value プロパティーの使用

最後の値を識別するために使用されるプロパティー名は "_HQ_LVQ_NAME" (またはコア API の定数 Message.HDR_LAST_VALUE_NAME )です。たとえば、Last-Value プロパティーに同じ値を持つ 2 つのメッセージが Last-Value キューに送信される場合、最新のメッセージのみがキューに保持されます。

例18.3 Send 1st message with Last-Value property set to STOCK_NAME( STOCK_NAMEに設定された Last-Value プロパティーを持つ最初のメッセージを送信する)

TextMessage message = session.createTextMessage("1st message with Last-Value property set");
message.setStringProperty("_HQ_LVQ_NAME", "STOCK_NAME");
producer.send(message);
Copy to Clipboard Toggle word wrap

例18.4 Send 2nd message with Last-Value property set to STOCK_NAME

message = session.createTextMessage("2nd message with Last-Value property set");
message.setStringProperty("_HQ_LVQ_NAME", "STOCK_NAME");
producer.send(message);
Copy to Clipboard Toggle word wrap

例18.5 2 番目のメッセージのみが受信されます。最後に Last-Value プロパティーが設定されます。

TextMessage messageReceived = (TextMessage)messageConsumer.receive(5000);
System.out.format("Received message: %s\n", messageReceived.getText());
Copy to Clipboard Toggle word wrap

18.8.5. コアおよび JMS 宛先

HornetQ コアには JMS トピックの概念はありません。JMS トピックは、0 個以上のキューがバインドされたアドレス (トピック名) としてコアに実装されます。このアドレスにバインドされる各キューが、トピックサブスクリプションを表します。同様に、JMS キューはアドレス(JMS キュー名)として実装されますが、JMS キューを表す単一のキューがバインドされます。
JMS トピックは、ユーザーが JMS メッセージングのパブリッシュ/サブスクライブモデルでプロデューサーから特定のメッセージを受信するためにサブスクライブするチャネルです。
JMS キューは、特定のトピックでメッセージを自動的に受信するのではなく、ポイントツーポイント(p2p)モデルを使用して受信するユーザーの「プル」メッセージを示すチャネルです。プロデューサーはメッセージをキューに送信し、受信側はキューを参照し、受信するメッセージを判別できます。p2p モデルでは、配信を受け入れるかどうかを決定する前に、キューに保持されているメッセージの内容を確認できます。
名前が orders.europe の JMS Queue の設定を行うには、対応するコアキュー jms.queue.orders.europe を設定する必要があります。
<!-- expired messages in JMS Queue "orders.europe" will be sent to the JMS Queue "expiry.europe" -->
<address-setting match="jms.queue.orders.europe">
	<expiry-address>jms.queue.expiry.europe</expiry-address>
	...
</address-setting>
Copy to Clipboard Toggle word wrap

18.8.6. JMS メッセージセレクター

メッセージングアプリケーションが受信するメッセージをフィルターする必要がある場合は、JMS API メッセージセレクターを使用して、メッセージコンシューマーが対象のメッセージを指定できるようになります。メッセージセレクターは、メッセージをアプリケーションではなく JMS プロバイダーにフィルタリングする作業を割り当てます。
メッセージセレクターは以下のように定義できます。
@MessageDriven(name = "MDBMessageSelectorExample", activationConfig =
{
   @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
   @ActivationConfigProperty(propertyName = "destination", propertyValue = "queue/testQueue"),
   @ActivationConfigProperty(propertyName = "messageSelector", propertyValue = "color = 'RED'")
})
@TransactionManagement(value= TransactionManagementType.CONTAINER)
@TransactionAttribute(value= TransactionAttributeType.REQUIRED)
public class MDBMessageSelectorExample implements MessageListener
{
   public void onMessage(Message message)....
}
Copy to Clipboard Toggle word wrap

18.8.7. HornetQ でのメッセージングの設定

JBoss EAP 6 でメッセージングを設定する方法として、管理コンソールまたは管理 CLI が推奨されます。standalone.xml または domain.xml 設定ファイルを手動で編集しなくても、これらの管理ツールのいずれかで永続的な変更を行うことができます。ただし、デフォルトの設定ファイルのメッセージングコンポーネントを理解すると便利です。ここでは、管理ツールを使用したドキュメントの例では、参照用の設定ファイルスニペットが提供されます。

18.8.8. HornetQ のロギングの有効化

EAP 6.x で HornetQ のロギングを有効にするには、以下の方法の 1 つを使用します。
  • サーバー設定ファイル(standalone-full.xml および standalone-full-ha.xml)の手動での編集
  • CLI を使用してサーバー設定ファイルを編集します。

手順18.1 サーバー設定ファイルを手作業で編集して HornetQ ロギングを設定する

  1. サーバー設定ファイルを開いて編集します。例: standalone-full.xml および standalone-full-ha.xml
  2. ファイルの logging サブシステム設定に移動します。デフォルト設定は以下のようになります。
    <logger category="com.arjuna">
     <level name="TRACE"/>
    </logger>
    ...
    <logger category="org.apache.tomcat.util.modeler">
     <level name="WARN"/>
    </logger>
    ....
    
    Copy to Clipboard Toggle word wrap
  3. 以下の例のように、org.hornetq ロガーカテゴリーと必要なロギングレベルを追加します。
    <logger category="com.arjuna">
      <level name="TRACE"/>
    </logger>
    ...
    <logger category="org.hornetq">
      <level name="INFO"/>
    </logger>
    ....
    
    Copy to Clipboard Toggle word wrap

結果

HornetQ ロギングが有効になり、設定されたログレベルを基にログメッセージが処理されます。

CLI を使用してサーバー設定ファイルを編集して HornetQ ロギングを設定する

CLI を使用して、希望のロギングレベルとともに org.hornetq ロガーカテゴリーをサーバー設定ファイルに追加することもできます。詳細は以下を参照してください。 「CLI でのログカテゴリー設定」

18.8.9. HornetQ Core Bridge の設定

例18.6 HornetQ Core Bridge の設定例

この例の値は、このトピックの残りを説明するために使用されます。
<bridges>
  	<bridge name="myBridge">
        <queue-name>jms.queue.InQueue</queue-name>
        <forwarding-address>jms.queue.OutQueue</forwarding-address>
	<ha>true</ha>
        <reconnect-attempts>-1</reconnect-attempts>
        <use-duplicate-detection>true</use-duplicate-detection>
        <static-connectors>
        	<connector-ref>
                bridge-connector
                </connector-ref>
        </static-connectors>
        </bridge>
</bridges>
Copy to Clipboard Toggle word wrap
Expand
表18.8 HornetQ Core Bridge の属性
属性 説明
name
ブリッジの名前はすべてサーバー上で一意となる必要があります。
queue-name
必須パラメーターは、ブリッジが消費するローカルキューの一意の名前です。ブリッジが起動時にインスタンス化される時点でキューが存在している必要があります。
forwarding-address
これは、メッセージが転送されるターゲットサーバーのアドレスです。転送アドレスが指定されていない場合、メッセージの元のアドレスは保持されます。
ha
このオプションのパラメーターは、このブリッジが高可用性をサポートするべきかどうかを決定します。true これは、クラスター内の利用可能なサーバーに接続し、フェイルオーバーをサポートすることを意味します。デフォルト値は false です。
reconnect-attempts
このオプションのパラメーターは、断念してシャットダウンするまでにブリッジが行う再接続試行の総回数を決定します。-1 の値は、無制限の試行回数を示します。デフォルト値は -1 です。
use-duplicate-detection
任意のパラメーターで、ブリッジが転送する各メッセージに複製の ID プロパティーを自動的に挿入するかどうかを決定します。
static-connectors
static-connectors は、他の場所で定義されるコネクター要素を参照する connector-ref 要素のリストです。コネクターは、使用するトランスポート(TCP、SSL、HTTP など)とサーバー接続パラメーター(ホスト、ポートなど)の知識をカプセル化します。

18.8.10. JMS ブリッジの設定

HornetQ には、完全に機能する JMS メッセージブリッジが含まれています。このブリッジの機能は、ソースキューまたはトピックからメッセージを消費し、通常は別のサーバーにあるターゲットキューまたはトピックに送信することです。
ソースやターゲットサーバーは同じクラスターにある必要はないため、ブリッジングは異なるクラスターの間 (WAN など) や接続が信頼できない場所でメッセージを確実に送信するのに適しています。
ブリッジは、HornetQ スタンドアロンサーバーまたは JBoss AS インスタンス内部を使用してスタンドアロンアプリケーションとしてデプロイできます。ソースとターゲットは同じ仮想マシンまたは別の仮想マシンに置くことができます。

例18.7 JMS ブリッジの設定例

この例の値は、このトピックの残りを説明するために使用されます。
<subsystem>
  <subsystem xmlns="urn:jboss:domain:messaging:1.3">
             <hornetq-server>
             ...
             </hornetq-server>

             <jms-bridge name="myBridge">
                <source>
                    <connection-factory name="ConnectionFactory"/>
                    <destination name="jms/queue/InQueue"/>
                </source>
                <target>
                    <connection-factory name="jms/RemoteConnectionFactory"/>
                    <destination name="jms/queue/OutQueue"/>
                    <context>
                        <property key="java.naming.factory.initial" value="org.jboss.naming.remote.client.InitialContextFactory"/>
                        <property key="java.naming.provider.url" value="remote://192.168.40.1:4447"/>
                    </context>
                </target>
                <quality-of-service>AT_MOST_ONCE</quality-of-service>
                <failure-retry-interval>1000</failure-retry-interval>
                <max-retries>-1</max-retries>
                <max-batch-size>10</max-batch-size>
                <max-batch-time>100</max-batch-time>
                <add-messageID-in-header>true</add-messageID-in-header>
            </jms-bridge>
...
</subsystem>
Copy to Clipboard Toggle word wrap
警告
JMS ブリッジは再接続処理に独自の max-retries パラメーターがあるため、reconnect-attempts パラメーターを設定(または 0に設定)しない接続ファクトリーを使用することが推奨されます。これにより、再接続時間が長くなる可能性がある競合の発生を防ぐことができます。
Expand
表18.9 HornetQ Core JMS 属性
属性 説明
name
ブリッジの名前はすべてサーバー上で一意となる必要があります。
source connection-factory
SourceCFF Bean(beans ファイルにも定義されます)をインジェクトします。この Bean はソースの ConnectionFactory を作成します。
source destination name
SourceDestinationFactory Bean(beans ファイルにも定義されます)をインジェクトします。この Bean はソースの Destination を作成します。
target connection-factory
TargetCFF Bean(beans ファイルにも定義されます)をインジェクトします。この Bean はターゲット ConnectionFactory を作成します。
target destination name
TargetDestinationFactory Bean(beans ファイルにも定義されます)をインジェクトします。この Bean はターゲット Destination を作成します。
quality-of-service
このパラメーターは、必要なサービスモードの品質を示しています。使用できる値は AT_MOST_ONCE、DUPLICATES_OK、ONCE_AND_ONLY_ONCE です。
failure-retry-interval
ブリッジによって接続の失敗が検出されたときに、ソースまたはターゲットサーバーへの接続を再試行する前に待機する期間 (ミリ秒単位) を表します。
max-retries
ブリッジで障害が発生したことを検出したときに、ソースサーバーまたはターゲットサーバーへの接続の再作成を試行する回数を表します。この回数の試行後にブリッジが試行されます。-1 は「try forever」を表します。
max-batch-size
バッチでターゲット宛先に送信する前にソース宛先から消費するメッセージの最大数を表します。この値は >= 1 にする必要があります。
max-batch-time
消費されたメッセージの数が MaxBatchSize に達していない場合でも、ターゲットへバッチを送信するまで待機する最大時間(ミリ秒単位)を表します。実際の時間を指定するには、値が -1 である必要があります。「wait forever」または 1 以上(実際の時間)を表す必要があります。
add-messageID-in-header
true の場合、元のメッセージのメッセージ ID がヘッダー HORNETQ_BRIDGE_MSG_ID_LIST 内の宛先に送信されるメッセージに追加されます。メッセージが複数回ブリッジされる場合は、各メッセージ ID が追加されます。これにより、分散リクエスト/応答パターンを使用できます。
メッセージを受信するとき、最初のメッセージ ID の相関 IDを使用して応答を送信できます。そのため、元の送信側がメッセージを受信すると簡単に関連付けできます。
注記
quality-of-service 属性が ONCE_AND_ONLY_ONCE に設定されているデプロイ済みの JMS ブリッジを持つサーバーをシャットダウンする場合は、予期しない例外を防ぐために JMS ブリッジを持つサーバーを最初にシャットダウンします。
詳しい手順については、「JMS ブリッジの作成」 を参照してください。

18.8.11. 遅延再配信の設定

はじめに

遅延再配信は、Java Messaging Service(JMS)サブシステム設定の < address-setting> 設定要素の子要素である <redelivery - delay> 要素で定義されます。

<!-- delay redelivery of messages for 5s -->
<address-setting match="jms.queue.exampleQueue">
  <redelivery-delay>5000</redelivery-delay>
</address-setting>
Copy to Clipboard Toggle word wrap
再配信の遅延が指定されると、JMS システムはこの遅延期間待機した後にメッセージを再配信します。&lt ;redelivery-delay>0 に設定すると、再配信の遅延はありません。アドレスワイルドカードは < address- match > 要素の match 属性で使用し、ワイルドカードに一致するアドレスの再配信遅延を設定できます。

18.8.12. デッドレターアドレスの設定

はじめに

デッドレターアドレスは、Java Messaging Service(JMS)サブシステム設定の <address-setting > 要素で定義されます。

<!-- undelivered messages in exampleQueue will be sent to the dead letter address 
deadLetterQueue after 3 unsuccessful delivery attempts
-->
<address-setting match="jms.queue.exampleQueue">
  <dead-letter-address>jms.queue.deadLetterQueue</dead-letter-address>
  <max-delivery-attempts>3</max-delivery-attempts>
</address-setting>
Copy to Clipboard Toggle word wrap
< dead-letter-address > が指定されていない場合、< max-delivery-attempts> 時間の配信を試行した後にメッセージが削除さ れます。デフォルトでは 10 回メッセージの配信を試みます。< max-delivery-attempts> を - 1 設定すると、再配信が無限に試行されます。たとえば、一致するアドレスのセットに対してグローバルにデッドレターを設定し、特定のアドレスに対して < max-delivery-attempts > を - 1 に設定すると、このアドレスのみに対して無限再配信が試行されます。アドレスワイルドカードを使用して、アドレスのセットにデッドレターを設定することもできます。

18.8.13. メッセージ期限切れアドレス

はじめに

メッセージ期限切れアドレスは Java Messaging Service(JMS)の address-setting 設定で定義されます。以下に例を示します。

<!-- expired messages in exampleQueue will be sent to the expiry address expiryQueue -->
<address-setting match="jms.queue.exampleQueue">
  <expiry-address>jms.queue.expiryQueue</expiry-address>
</address-setting>
Copy to Clipboard Toggle word wrap
メッセージの期限が切れ、期限切れアドレスが指定されていない場合、メッセージは単にキューから削除されドロップされます。アドレスワイルドカード を使用して、アドレスのセットに期限切れアドレスの特定の範囲を設定することもできます。JMX ワイルドカード構文と例は、「JMS アドレスの設定」 を参照してください。

18.8.14. フロー制御

フロー制御は、クライアントまたはサーバーがデータでオーバーロードしないように、クライアントとサーバー間のデータフローを制限するために使用されます。
  • Consumer Flow Control: クライアントがメッセージを消費する際にサーバーとクライアント間のデータのフローを制御します。パフォーマンス上の理由から、クライアントは通常、receive() メソッドを介してコンシューマーに配信したり、メッセージリスナーを介して非同期的にコンシューマーに配信する前にメッセージをバッファーします。
    レート制限のあるフロー制御: コンシューマーがメッセージを消費できるレートを制御できます。これはスロットリングの形式であり、コンシューマーが指定のレートよりも速いメッセージを消費しないようにすることができます。この機能を有効にするには、レートは正の整数である必要があります。1 秒あたりのメッセージ単位で指定される必要なメッセージ消費率の最大値です。これを -1 に設定すると、レート制限フロー制御が無効になります。デフォルト値は -1 です。

    例18.8 JMS を使用したレート制限フロー制御

    JNDI を使用して接続ファクトリーを検索する場合は、standalone.xml または domain.xml で最大レートを設定できます。
    <connection-factory name="ConnectionFactory">
    	<connectors>
    		<connector-ref connector-name="netty-connector"/>
    	</connectors>
      <entries>
      	<entry name="ConnectionFactory"/>
      </entries>
      <!-- We limit consumers created on this connection factory to consume messages at a maximum rate of 10 messages per sec -->
    	<consumer-max-rate>10</consumer-max-rate>
    </connection-factory>
    Copy to Clipboard Toggle word wrap
    接続ファクトリーが直接インスタンス化されている場合、HornetQConnectionFactory.setConsumerMaxRate(int consumerMaxRate) メソッドを使用して最大レートサイズを設定できます。
  • プロデューサーフロー制御: サーバーが大きすぎないように、クライアントからサーバーに送信されるデータ量をサーバーに制限します。
    ウィンドウベースのフロー制御: HornetQ プロデューサーは、ジャーナルに十分なクレジットがある限り、メッセージをアドレスに送信できます。メッセージの送信に必要なクレジットの量は、メッセージのサイズで指定されます。プロデューサーはクレジットが少ないため、サーバーがより多くのクレジットを送信すると、より多くのメッセージを送信できます。プロデューサーリクエストのクレジットの量は、ウィンドウサイズ と呼ばれます。

    例18.9 JMS を使用したプロデューサーウィンドウサイズフロー制御

    JNDI を使用して接続ファクトリーを検索する場合は、プロデューサーウィンドウサイズを standalone.xml または domain.xml で設定できます。
    <connection-factory name="ConnectionFactory">
       <connectors>
          <connector-ref connector-name="netty-connector"/>
       </connectors>
       <entries>
          <entry name="ConnectionFactory"/>
       </entries>
       <producer-window-size>10</producer-window-size>
    </connection-factory>
    Copy to Clipboard Toggle word wrap
    接続ファクトリーが直接インスタンス化されている場合、HornetQConnectionFactory.setProducerWindowSize(int producerWindowSize) メソッドを使用してプロデューサーウィンドウサイズを設定できます。

18.8.15. HornetQ 設定属性のリファレンス

HornetQ の JBoss EAP 6 実装は設定の以下の属性を公開します。管理 CLI を使用すると、read-resource 操作で設定可能または表示可能な属性を表示できます。

例18.10 read-resource を使用して属性を表示します。

[standalone@localhost:9999 /] /subsystem=messaging/hornetq-server=default:read-resource
Copy to Clipboard Toggle word wrap
Expand
表18.10 HornetQ 属性
属性 デフォルト値 説明
allow-failback true BOOLEAN 元のライブサーバーが復旧したときにこのサーバーを自動的にシャットダウンするかどうか。
async-connection-execution-enabled true BOOLEAN サーバーの受信パケットをスレッドプールからのスレッドに渡して処理するかどうか。
address-setting 特定のキューでなく、アドレスワイルドカードに対して定義された一部の属性を定義するアドレス設定。
acceptor アクセプターは HornetQ サーバーへ接続を確立する方法を定義します。
backup-group-name STRING お互いをレプリケートする必要があるライブ/バックアップのセットの名前。
backup false BOOLEAN このサーバーがバックアップサーバーであるかどうか。
check-for-live-server false BOOLEAN 同じノード ID を持つライブサーバーがすでに存在するかを確認するため、レプリケートされたライブサーバーが現在のクラスターをチェックするかどうか。
clustered false BOOLEAN [廃止済み] サーバーがクラスター化されているかどうか。
cluster-password やり直してください! STRING クラスター化されたノードの間で通信するためにクラスター接続によって使用されるパスワード。
cluster-user HORNETQ.CLUSTER.ADMIN.USER STRING クラスター化されたノードの間で通信するためにクラスター接続によって使用されるユーザー。
cluster-connection クラスター接続はサーバーをクラスターにグループ化し、クラスターのノード間でメッセージの負荷を分散します。
create-bindings-dir true BOOLEAN 起動時にサーバーが bindings ディレクトリーを作成するかどうか。
create-journal-dir true BOOLEAN 起動時にサーバーが journal ディレクトリーを作成するかどうか。
connection-ttl-override -1L LONG 設定された場合、ping を受信せずに接続を維持する期間 (ミリ秒単位) を上書きします。
connection-factory 接続ファクトリーを定義します。
connector サーバーへの接続方法を定義するためクライアントはコネクターを使用できます。
connector-service
divert クライアントアプリケーションロジックを変更せずに、あるアドレスから別のアドレスにルーティングされたメッセージを透過的に迂回できるようにするメッセージングリソースです。
discovery-group コネクターをアナウンスする他のサーバーからブロードキャストを受信するためリッスンするマルチキャストグループ。
failback-delay 5000 LONG ライブサーバーの再起動でフェイルバックが発生する前に待機する期間。
failover-on-shutdown false BOOLEAN このバックアップサーバー (バックアップサーバーである場合) が通常のサーバーのシャットダウン時に稼働されるかどうか。
grouping-handler クラスターのどのノードがグループ ID が割り当てられたメッセージを処理するかを決定します。
id-cache-size 20000 INT メッセージ ID を事前作成するためのキャッシュのサイズ。
in-vm-acceptor HornetQ サーバーへ VM 内 (in-VM) 接続を確立する方法を定義します。
in-vm-connector サーバーへの接続方法を定義するため、VM 内のクライアントによって使用されます。
jmx-domain org.hornetq STRING MBeanServer で内部 HornetQ MBean を登録するために使用される JMX ドメイン。
jmx-management-enabled false BOOLEAN HornetQ が内部管理 API を JMX 経由で公開するかどうか。これらの MBean にアクセスすると設定が一貫性のない可能性があるため、この方法は推奨されません。
journal-buffer-size 501760 (490KiB) LONG ジャーナルの内部バッファーのサイズ。
journal-buffer-timeout ASYNCIO ジャーナルは 500000 (0.5 ミリ秒)、NIO ジャーナルは 3333333 (3.33 ミリ秒)。 LONG ジャーナルで内部バッファーをフラッシュするのに使用されるタイムアウト (ナノ秒単位)。
journal-compact-min-files 10 INT 圧縮開始前のジャーナルデータファイルの最小数。
journal-compact-percentage 30 INT ジャーナルの圧縮を考慮するライブデータの比率 (パーセント)。
journal-file-size 10485760 LONG 各ジャーナルファイルのサイズ (バイト単位)。
journal-max-io 1 INT 一度に AIO キューに入れることのできる書き込み要求の最大数。ASYNCIO ジャーナルが使用されると、デフォルト値は 500 に変わります。
journal-min-files 2 INT 事前作成するジャーナルファイルの数。
journal-sync-non-transactional true BOOLEAN クライアントに応答を返す前に、非トランザクションデータがジャーナルに同期化されるのを待つかどうか。
journal-sync-transactional true BOOLEAN クライアントに応答を返す前に、トランザクションデータがジャーナルに同期化されるのを待つかどうか。
journal-type ASYNCIO 文字列 使用するジャーナルのタイプ。この属性は「ASYNCIO」または「NIO」の値を取ることができます。
jms-topic JMS トピックを定義します。
live-connector-ref reference STRING [廃止済み] ライブコネクターへの接続に使用されるコネクターの名前。このサーバーが共有しない HA を使用するバックアップではない場合、値は「undefined」になります。
log-journal-write-rate false BOOLEAN ジャーナルの書き込み率およびフラッシュ率を周期的にログに記録するかどうか。
mask-password true BOOLEAN  
management-address jms.queue.hornetq.management STRING 管理メッセージを送信する先のアドレス。
management-notification-address hornetq.notifications STRING 管理通知を受け取るためにコンシューマーがバインドするアドレスの名前。
max-saved-replicated-journal-size 2 INT フェイルバック発生後に保持するバックアップジャーナルの最大数。
memory-measure-interval -1 LONG JVM メモリーのサンプリング頻度 (ミリ秒単位)。-1 を指定するとメモリーのサンプリングが無効になります。
memory-warning-threshold 25 INT この値を越えると警告ログが記録される使用可能なメモリーの比率 (パーセント)。
message-counter-enabled false BOOLEAN メッセージカウンターが有効であるかどうか。
message-counter-max-day-history 10 INT メッセージカウンターの履歴を保持する日数。
message-counter-sample-period 10000 LONG メッセージカウンターに使用するサンプル周期 (ミリ秒単位)。
message-expiry-scan-period 30000 LONG 期限切れメッセージをスキャンする頻度 (ミリ秒単位)。
message-expiry-thread-priority 3 INT メッセージを期限切れにするスレッドの優先度
page-max-concurrent-io 5 INT ページングで許可される同時読み取りの最大数。
perf-blast-pages -1 INT  
persist-delivery-count-before-delivery false BOOLEAN 配信前に配信数が永続化されるかどうか。false は、メッセージがキャンセルされた後にのみ発生することを意味します。
persist-id-cache true BOOLEAN ID がジャーナルへ永続化されるかどうか。
persistence-enabled true BOOLEAN サーバーがファイルベースのジャーナルを永続化に使用するかどうか。
pooled-connection-factory 管理対象接続ファクトリーを定義します。
remoting-interceptors undefined LIST [廃止済み] このサーバーによって使用されるインターセプタークラスのリスト。
remoting-incoming-interceptors undefined LIST このサーバーによって使用される受信インターセプタークラスのリスト。
remoting-outgoing-interceptors undefined LIST このサーバーによって使用される送信インターセプタークラスのリスト。
run-sync-speed-test false BOOLEAN 起動時にディスクが同期できる速度で診断テストを実行するかどうか。パフォーマンスの問題を特定する際に役立ちます。
replication-clustername STRING レプリケート元のクラスター接続の名前 (2 つ以上のクラスターが設定されている場合)。
runtime-queue ランタイムキュー
remote-connector サーバーへの接続方法を定義するためにリモートクライアントによって使用されます。
remote-acceptor HornetQ サーバーへリモート接続が確立される方法を定義します。
scheduled-thread-pool-max-size 5 INT メインのスケジュールされたスレッドプールが持つスレッドの数。
security-domain その他 STRING ユーザーおよびロールの情報を検証するために使用するセキュリティードメイン。
security-enabled true BOOLEAN セキュリティーが有効かどうか。
security-setting セキュリティー設定は、アドレスを基にキューに対してパーミッションのセットを定義できるようにします。
security-invalidation-interval 10000 LONG セキュリティーキャッシュを無効にする前に待機する時間 (ミリ秒単位)。
server-dump-interval -1 LONG 基本的なランタイム情報をサーバーログにダンプする頻度。1 未満の値を指定すると、この機能が無効になります。
共有ストア true BOOLEAN このサーバーがフェイルオーバーに共有ストアを使用しているかどうか。
thread-pool-max-size 30 INT メインのスレッドプールが持つスレッドの数。-1 は無制限を意味します。
transaction-timeout 300000 LONG 作成時の後、トランザクションをリソースマネージャーから削除できるまでの時間 (ミリ秒単位)。
transaction-timeout-scan-period 1000 LONG タイムアウトトランザクションをスキャンする頻度 (ミリ秒単位)。
wild-card-routing-enabled true BOOLEAN サーバーがワイルドカードルーティングをサポートするかどうか。
警告
journal-file-size の値は、サーバーに送信されるメッセージのサイズよりも大きくなければなりません。そうでないと、サーバーはメッセージを保存できません。

18.8.16. メッセージの有効期限の設定

はじめに

送信されたメッセージは、指定期間(ミリ秒単位)後にコンシューマーに配信されない場合にサーバーで期限切れになるように設定できます。Java Messaging Service(JMS)または HornetQ Core API を使用すると、有効期限をメッセージに直接設定できます。以下に例を示します。

// message will expire in 5000ms from now
message.setExpiration(System.currentTimeMillis() + 5000);
Copy to Clipboard Toggle word wrap
JMS MessageProducer には、送信するメッセージの有効期限を制御する TimeToLive パラメーターが含まれています。
// messages sent by this producer will be retained for 5s (5000ms) before expiration           
producer.setTimeToLive(5000);
Copy to Clipboard Toggle word wrap
期限切れアドレスより消費された期限切れメッセージは次のプロパティーを持っています。
  • _HQ_ORIG_ADDRESS
期限切れメッセージの元のアドレスが含まれる文字列プロパティー。
  • _HQ_ACTUAL_EXPIRY
期限切れメッセージの実際の失効時間が含まれるロングプロパティー。
JMS プロデューサーで time-to-live パラメーターを設定する他に、メッセージごとに設定することもできます。これを行うには、メッセージの送信時にプロデューサーの送信メソッドに TTL パラメーターを追加します。
producer.send(message, DeliveryMode.PERSISTENT, 0, 5000)
Copy to Clipboard Toggle word wrap
ここで、最後のパラメーターはメッセージ固有の TTL です。

期限切れアドレスの設定

期限切れアドレスは address-setting 設定で定義されます。

<!-- expired messages in exampleQueue will be sent to the expiry address expiryQueue -->
<address-setting match="jms.queue.exampleQueue">
   <expiry-address>jms.queue.expiryQueue</expiry-address>
</address-setting>
Copy to Clipboard Toggle word wrap
メッセージの期限が切れ、期限切れアドレスが指定されていない場合、メッセージはキューから削除されドロップされます。

期限切れリーパー (Reaper) スレッドの設定

リーパー (reaper) スレッドは、メッセージの期限切れを検証するためにキューを定期的に検査します。

  • message-expiry-scan-period
期限切れメッセージを検出するためにキューがスキャンされる頻度 (ミリ秒単位でデフォルト値は 30000 ミリ秒)。-1 を設定するとリーパースレッドが無効になります。
  • message-expiry-thread-priority
リーパースレッドの優先度。優先度が最も高い 0 から 9 までの値である必要があります。デフォルトは 3 です。

18.9. PRE_ACKNOWLEDGE モード

JMS は次の 3 つの承認モードを指定します。
  • AUTO_ACKNOWLEDGE
  • CLIENT_ACKNOWLEDGE
  • DUPS_OK_ACKNOWLEDGE
HornetQ は、PRE_ACKNOWLEDGE と INDIVIDUAL_ACKNOWLEDGE の 2 つの追加モードをサポートします。
シナリオによっては、障害発生時にメッセージを失わせる可能性があるので、クライアントへ配信する前にサーバーでメッセージを確認しやすくなります。
この追加モードは HornetQ によってサポートされ、事前承認モードと呼ばれます。
配信前にサーバーでメッセージを承認する欠点は、サーバーでメッセージを承認した後、クライアントに配信される前にシステムがクラッシュした場合にメッセージが失われることです。この場合、システムの再起動時にメッセージが失われ、復元されません。
メッセージングのケースに応じて、事前承認モードでは、メッセージ損失による対応により、追加のネットワークトラフィックと CPU を回避できます。
事前承認の使用例は、株式価格更新メッセージに関連します。これらのメッセージでは、クラッシュ発生時にメッセージが失われることは適切です。これは、次の価格更新メッセージがすぐに到達し、前の価格を上書きするためです。
注記
pre-acknowledge モードを使用する場合、消費されるメッセージのトランザクションセマンティクスが失われます。これは、トランザクションのコミット時ではなく、サーバーで最初に確認されるためです。

18.9.1. PRE_ACKNOWLEDGE の使用

事前承認モードは、接続ファクトリーの standalone.xml または domain.xml ファイルで設定できます。
<connection-factory name="ConnectionFactory">
   <connectors>
      <connector-ref connector-name="netty-connector"/>
   </connectors>
   <entries>
      <entry name="ConnectionFactory"/>
   </entries>
   <pre-acknowledge>true</pre-acknowledge>
</connection-factory>
Copy to Clipboard Toggle word wrap
または、JMS API を使用して事前承認モードを使用するには、HornetQSession.PRE_ACKNOWLEDGE 定数で JMS セッションを作成します。
// messages will be acknowledge on the server *before* being delivered to the client
Session session = connection.createSession(false, HornetQJMSConstants.PRE_ACKNOWLEDGE);
Copy to Clipboard Toggle word wrap
または、setset メソッドを使用して HornetQConnectionFactory インスタンスに事前承認を直接設定できます。
コア API を使用して事前承認モードを使用するには、セッターメソッドを使用して ClientSessionFactory インスタンスに直接設定できます。

18.9.2. 個々の Acknowledge

個別の確認応答の有効なユースケースとして、独自のスケジュールが必要であり、メッセージ処理が完了したときにわからない場合が挙げられます。スレッドワーカーごとに 1 つのコンシューマーの使用が優先されますが、処理の複雑な設定方法によっては、状況によってはこれを行うことはできません。これにより、個別の確認応答を使用できます。
HornetQJMSConstants.INDIVIDUAL_ACKNOWLEDGE で確認モードでセッションを作成して、個別の Acknowledge を設定する必要があります。個々の Acknowledge は、クライアント Acknowledge からすべてのセマンティクスを継承しますが、例外はメッセージを個別に承認されます。
注記
MDB 処理における混乱を避けるため、個別の ACKNOWLEDGE は MDB(またはインバウンドリソースアダプター)ではサポートされません。これは、MDB 内でメッセージのプロセスを終了する必要があるためです。

18.10. スレッド管理

18.10.1. サーバー側のスレッド管理

各 HornetQ サーバーは、一般的な使用のために単一のスレッドプールを維持し、スケジュール使用のためにスケジュールスレッドプールを維持します。Java のスケジュールスレッドプールは標準のスレッドプールを使用するように設定できません。それ以外は、スケジュールされたアクティビティーとスケジュールされていないアクティビティーの両方に単一のスレッドプールを使用できます。
古い(ブロッキング)IO を使用する場合は、別のスレッドプールを使用して接続を処理します。古い IO は接続ごとにスレッドを必要とするため、多くの接続が行われるとプールが使い切られるため、標準プールからスレッドを取得することは推奨されません。これにより、他の処理を行うスレッドが残っていないため、サーバーがハングします。サーバーが多くの同時接続を処理する必要がある場合は、古い IO ではなく NIO を使用する必要があります。
新しい IO(NIO)を使用する場合、HornetQ はデフォルトで受信パケットを処理するために .getRuntime().availableProcessors()Runtime によって報告されるコア(またはハイパースレッド)の数の 3 倍のスレッドを使用します。この値をオーバーライドするには、トランスポート設定に nio-remoting-threads パラメーターを指定してスレッド数を設定できます。
18.10.1.1. サーバースケジュールスレッドプール
サーバースケジュールスレッドプールは、定期的に実行する必要がある、または遅れて実行する必要があるサーバーサイドの多くのアクティビティーに使用されます。内部的には、java.util.concurrent.ScheduledThreadPoolExecutor インスタンスにマッピングします。
このプールによって使用されるスレッドの最大数は、scheduled-thread-pool-max-size パラメーターを使用して standalone.xml または domain.xml で設定されます。デフォルト値は 5 スレッドです。通常、このプールには少ない数のスレッドで十分です。
18.10.1.2. 汎用サーバースレッドプール
汎用スレッドプールは、サーバー側でほとんどの非同期操作に使用されます。内部的には、java.util.concurrent.ThreadPoolExecutor インスタンスにマッピングします。
このプールによって使用されるスレッドの最大数は、thread-pool-max-size パラメーターを使用して standalone.xml または domain.xml で設定されます。
-1 の値を使用すると、スレッドプールには上限がなく、要求を満たすのに十分なスレッドがない場合には、新しいスレッドがオンデマンドで作成されます。後でアクティビティーが従うと、スレッドはタイムアウトになり、閉じられます。
n の値(n はゼロより大きい正の整数)が使用される場合、スレッドプールはバインドされます。要求数が増え、プールに空きスレッドがなく、プールが満杯になると、スレッドが利用可能になるまでリクエストはブロックされます。バインドされたスレッドプールは、上限が低すぎると、デッドロックの状況が発生する可能性があるため、注意して使用することが推奨されます。
thread-pool-max-size のデフォルト値は 30 です。
18.10.1.3. 期限切れリーパースレッド
キュー内の期限が切れたメッセージをスキャンするためにサーバー側でも単一のスレッドが使用されます。このスレッドは、独自の設定可能な優先順位で実行する必要があるため、このためにスレッドプールのいずれかを使用することはできません。
18.10.1.4. 非同期 IO
非同期 IO には、ネイティブレイヤーからイベントを送受信するためのスレッドプールがあります。これは、接頭辞 HornetQ-AIO-poller-pool を持つスレッドダンプ上にあります。HornetQ は、ジャーナル上で開かれたファイルごとに 1 つのスレッドを使用します(通常は 1 つです)。
また、libaio で書き込みを呼び出すために使用されるスレッドも 1 つあります。これは、libaio で、パフォーマンスの問題を引き起こすコンテキスト切り替えを回避するために行われます。このスレッドは、接頭辞 HornetQ-AIO-writer-pool を持つスレッドダンプにあります。

18.10.2. クライアント側のスレッド管理

クライアント側で、HornetQ は単一の静的スケジュールスレッドプールと、その JVM インスタンスの同じクラスローダーを使用してすべてのクライアントによって使用される静的汎用スレッドプールを 1 つ維持します。
静的スケジュールスレッドプールの最大サイズは 5 つのスレッドで、汎用スレッドプールの最大サイズはバインドされません。
ClientSessionFactory インスタンスがこれらの静的プールを使用せず、代わりに独自のスケジュールおよび汎用プールを維持するように HornetQ を設定することもできます。その ClientSessionFactory から作成されたセッションは、代わりにそれらのプールを使用します。
ClientSessionFactory インスタンスが独自のプールを使用するように設定するには、作成直後に適切なセッターメソッドを使用します。以下に例を示します。
ServerLocator locator = HornetQClient.createServerLocatorWithoutHA(...)
ClientSessionFactory myFactory = locator.createClientSessionFactory();
myFactory.setUseGlobalPools(false);
myFactory.setScheduledThreadPoolMaxSize(10);
myFactory.setThreadPoolMaxSize(-1);
Copy to Clipboard Toggle word wrap
JMS API を使用している場合は、ClientSessionFactory に同じパラメーターを設定し、これを使用して ConnectionFactory インスタンスを作成できます。以下に例を示します。
ConnectionFactory myConnectionFactory = HornetQJMSClient.createConnectionFactory(myFactory);
Copy to Clipboard Toggle word wrap
JNDI を使用して HornetQConnectionFactory インスタンスをインスタンス化する場合は、接続ファクトリーを記述する standalone.xml または domain.xml ファイルにこれらのパラメーターを設定することもできます。以下に例を示します。
<connection-factory name="ConnectionFactory">
   <connectors>
      <connector-ref connector-name="netty"/>
   </connectors>
   <entries>
      <entry name="ConnectionFactory"/>
      <entry name="XAConnectionFactory"/>
   </entries>
   <use-global-pools>false</use-global-pools>
   <scheduled-thread-pool-max-size>10</scheduled-thread-pool-max-size>
   <thread-pool-max-size>-1</thread-pool-max-size>
</connection-factory>
Copy to Clipboard Toggle word wrap

18.11. メッセージのグループ化

18.11.1. メッセージのグループ化

メッセージグループは、共通した特定の特徴を持つメッセージのセット/グループです。
  • メッセージグループのすべてのメッセージは、共通のグループ ID でグループ化されます。これは、共通のグループプロパティーで識別できることを意味します。
  • メッセージグループのすべてのメッセージは、キューのカスタマーの数に関係なく、同じコンシューマーによって順次処理および消費されます。そのため、一意のグループ ID を持つ特定のメッセージグループは、常にそのメッセージグループを開く 1 つのコンシューマーによって処理されます。コンシューマーがメッセージグループを閉じると、メッセージグループ全体がキューの別のコンシューマーに移動されます。
重要
メッセージグループは、特定のプロパティーの値 (グループ ID) を持つメッセージが単一のコンシューマーによって順次処理される必要がある場合に便利です。

18.11.2. クライアント側での HornetQ Core API の使用

_HQ_GROUP_ID プロパティーは、クライアント側で HornetQ Core API のメッセージグループを特定するために使用されます。ランダムな一意のメッセージグループ識別子を選択するには、SessionFactory で auto-group プロパティーを true に設定することもできます。

18.11.3. Java Messaging Service (JMS) クライアントのサーバー設定

JMSXGroupID プロパティーは、Java Messaging Service (JMS) クライアントのメッセージグループを特定するために使用されます。別のメッセージを持つメッセージグループを 1 つのコンシューマーに送信する場合は、異なるメッセージに同じ JMSXGroupID を設定できます。
 Message message = ...
 message.setStringProperty("JMSXGroupID", "Group-0");
 producer.send(message);

 message = ...
 message.setStringProperty("JMSXGroupID", "Group-0");
 producer.send(message);
Copy to Clipboard Toggle word wrap
2 つ目は、HornetQConnectonFactoryauto-group プロパティーを true に設定する方法です。その後、HornetQConnectionFactory はランダムな一意のメッセージグループ識別子を選択します。以下のようにサーバー設定ファイル(standalone.xml および domain.xml)に auto-group プロパティーを設定できます。
<connection-factory name="ConnectionFactory">
   <connectors>
      <connector-ref connector-name="netty-connector"/>
   </connectors>
   <entries>
      <entry name="ConnectionFactory"/>
   </entries>
   <auto-group>true</auto-group>
</connection-factory>
Copy to Clipboard Toggle word wrap
上記の方法の代替は、接続ファクトリーを介して特定のメッセージグループ識別子を設定することです。これにより、この接続ファクトリーを介して送信されたすべてのメッセージに対して JMSXGroupID プロパティーが指定された値に設定されます。接続ファクトリーに特定のメッセージグループ識別子を設定するには、サーバー設定ファイル(standalone.xml および domain.xml)の group-id プロパティーを以下のように編集します。
<connection-factory name="ConnectionFactory">
   <connectors>
      <connector-ref connector-name="netty-connector"/>
   </connectors>
   <entries>
      <entry name="ConnectionFactory"/>
   </entries>
   <group-id>Group-0</group-id>
</connection-factory>
Copy to Clipboard Toggle word wrap

18.11.4. クラスター化されたグルーピング

重要
クラスター化されたグループ化は テクノロジープレビュー としてのみ提供されます。実稼働環境での使用はサポートされず、今後大幅に変更される可能性があります。
クラスター化されたグルーピングは、通常のメッセージのグループ化とは異なる方法に従います。クラスターの中では、特定のグループ ID を持つメッセージグループが、ノードのいずれかに到達できます。ノードでは、どのノードの、どのコンシューマーに、どのグループ ID がバインドされるかを判断することが重要です。各ノードは、メッセージグループがデフォルトで到達する場所に関係なく、それらのグループ ID を処理するコンシューマーを持つノードにメッセージグループを正しくルーティングします。指定したグループ ID を持つメッセージが、クラスター内の指定したノードに接続されている特定のコンシューマーに送信されます。この場合、これらのメッセージはコンシューマーが切断されても別のノードに送信されることはありません。
この状況は、グルーピングハンドラーによって処理されます。各ノードにグルーピングハンドラーがあります。また、このグルーピングハンドラー (と他のハンドラー) は、メッセージグループを正しいノードにルーティングする役割を担います。グルーピングハンドラーには、ローカルリモート という 2 つのタイプがあります。
ローカルハンドラーは、メッセージグループが取るルートを決定します。リモートハンドラーはローカルハンドラーと通信し、適切に動作します。各クラスターは、特定のノードを選択してローカルグルーピングハンドラー指定するようにします。また、その他のすべてのノードには、リモートハンドラー指定する必要があります。
警告
メッセージのグループ化がクラスターで使用されると、設定されたリモートグルーピングハンドラーを持つサーバーが失敗すると破損します。リモートグルーピングハンドラーのバックアップの設定にも影響はありません。
以下のようにサーバー設定ファイル(standalone.xml および domain.xml)で「ローカル」および「リモート」グルーピングハンドラーを設定できます。
<grouping-handler name="my-grouping-handler">
   <type>LOCAL</type>
   <address>jms</address>
   <timeout>5000</timeout>
</grouping-handler>

<grouping-handler name="my-grouping-handler">
   <type>REMOTE</type>
   <address>jms</address>
   <timeout>5000</timeout>
</grouping-handler>
Copy to Clipboard Toggle word wrap
"timeout" 属性は、指定した時間内にルーティングを決定することを保証します。この時間内にデシジョンが行われないと、例外が発生します。
最初にメッセージグループを受け取るノードは、通常のクラスタールーティング条件(ラウンドロビンキューの可用性)に基づいてルーティングの決定を行います。ノードは、この決定をそれぞれのグルーピングハンドラーに提案します。グルーピングハンドラーが受け入れた場合は、提案されたキューにメッセージをルーティングします。
グルーピングハンドラーが提案を拒否した場合は、他のルートを提案し、それに応じてルーティングを行います。その他のノードも先例に従い、選択したキューにメッセージグループを転送します。メッセージがキューに到達すると、そのキューのカスタマーに固定されます。

18.11.5. クラスター化されたグルーピングのベストプラクティス

クラスター化されたグループ化のベストプラクティスには、以下のものがあります。
  • コンシューマーを定期的に作成して閉じる場合は、コンシューマーが別のノードに均等に分散されていることを確認します。キューが固定されると、キューからカスタマーを削除するかどうかに関わらず、そのキューにメッセージが自動的に転送されます。
  • メッセージグループがバインドされているキューを削除する場合は、メッセージを送信しているセッションによってキューが削除されていることを確認してください。これを実行することで、他のノードは削除後にこのキューにメッセージをルーティングしないようにします。
  • フェイルオーバーメカニズムとして、ローカルグルーピングハンドラーを持つノードを常にレプリケートします。

18.12. 複製メッセージの検出

18.12.1. 複製メッセージの検出

複製メッセージの検出により、アプリケーション内で重複検出ロジックをコーディングせずに複製メッセージをフィルターできます。HornetQ で複製メッセージの検出を設定できます。
送信側(クライアント/サーバー)がメッセージを別のサーバーに送信する場合、メッセージの送信後に処理が成功したことを示す応答を送信する前にターゲットサーバー(受信側)または接続に失敗する可能性があります。このような状況では、送信側(クライアント)がメッセージが目的の受信者に正常に送信されたかどうかを判断することは非常に困難です。
メッセージ送信は、(メッセージの送信前または送信後)ターゲット受信側または接続が失敗したタイミングによって、成功することがあります。送信側(クライアント/サーバー)が最後のメッセージを再送信すると、アドレスに重複メッセージが送信される可能性があります。
HornetQ は、アドレスに送信されたメッセージに対して複製メッセージの検出機能を提供します。

18.12.2. メッセージ送信に重複メッセージ検出を使用する

送信メッセージに対して複製メッセージの検出を有効にするには、メッセージで特別なプロパティーを一意の値に設定する必要があります。この値は必要に応じて作成できますが、この値は一意でなければなりません。
ターゲットサーバーがこのメッセージを受信すると、特別なプロパティーが設定されているかどうかを確認します。プロパティーが設定されている場合、ターゲットサーバーはヘッダーのその値で受信したメッセージのメモリーキャッシュをチェックします。サーバーがヘッダーと同じ値を持つメッセージを見つけると、クライアントが送信したメッセージを無視します。
トランザクションでメッセージを送信する場合、そのトランザクションで送信するすべてのメッセージにプロパティーを設定する必要はありません。トランザクションで一度だけ設定する必要があります。サーバーがトランザクションのメッセージの重複メッセージを検出すると、トランザクション全体を無視します。
設定するプロパティーの名前は、org.hornetq.api.core.HDR_DUPLICATE_DETECTION_ID の値によって指定されます( _HQ_DUPL_ID )。このプロパティーの値は、コア API の byte[] または SimpleString 型です。Java Messaging Service(JMS)クライアントの場合、一意の値を持つ String タイプである必要があります。一意の ID を簡単に生成する方法は、UUID を生成することです。
下例はコア API のプロパティーを設定する方法を示しています。
...     

ClientMessage message = session.createMessage(true);

SimpleString myUniqueID = "This is my unique id";   // Can use a UUID for this

message.setStringProperty(HDR_DUPLICATE_DETECTION_ID, myUniqueID);

...
Copy to Clipboard Toggle word wrap
下例は JMS クライアントのプロパティーを設定する方法を示しています。
...     

Message jmsMessage = session.createMessage();

String myUniqueID = "This is my unique id";   // Could use a UUID for this

message.setStringProperty(HDR_DUPLICATE_DETECTION_ID.toString(), myUniqueID);

...
Copy to Clipboard Toggle word wrap

18.12.3. 複製 ID キャッシュの設定

サーバーは、各アドレスに送信された org.hornetq.core.message.impl.HDR_DUPLICATE_DETECTION_ID プロパティーの受信値のキャッシュを維持します。各アドレスは独自のアドレスキャッシュを維持します。
キャッシュのサイズは固定です。キャッシュの最大サイズは、サーバー設定ファイル(standalone.xml および domain.xml)の id-cache-size パラメーターを使用して設定されます。このパラメーターのデフォルト値は 2000 要素です。キャッシュの最大サイズが n 要素である場合、(n + 1)番目の ID が保存されていると、キャッシュ内の 0 番目の要素が上書きされます。
キャッシュは、ディスクに永続化するように設定することもできます。これは、サーバー設定ファイル(standalone.xml および domain.xml)で persist-id-cache パラメーターを使用して設定できます。この値を「true」に設定すると、各 ID は受信時に永続ストレージに永続化されます。このパラメーターのデフォルト値は true です。
注記
メッセージを再送信した場合にキャッシュに保存されている送信済みのメッセージが上書きされないようにするには、重複 ID キャッシュのサイズを大きなサイズに設定します。

18.12.4. ブリッジおよびクラスター接続での複製検出の使用

コアブリッジは、メッセージをターゲットに転送する前に、一意の重複 ID 値(メッセージにまだない場合)を自動的に追加するように設定できます。重複メッセージ検出にコアブリッジを設定するには、サーバー設定ファイル(standalone.xml および domain.xml)でプロパティー use-duplicate-detection を "true" に設定します。このパラメーターのデフォルト値は「true」です。
クラスター接続は内部的にコアブリッジを使用してクラスターのノード間でメッセージを移動します。重複メッセージ検出にクラスター接続を設定するには、サーバー設定ファイル(standalone.xml および domain.xml)でプロパティー use-duplicate-detection を "true" に設定します。このパラメーターのデフォルト値は「true」です。

18.13. JMS ブリッジ

18.13.1. ブリッジ

ブリッジの機能は、ソースキューからメッセージを消費し、通常は異なる HornetQ サーバーにあるターゲットアドレスに転送することです。ブリッジは信頼できる接続に対応し、接続が再び利用可能になると自動的に再接続します。HornetQ ブリッジはフィルター式で設定でき、特定のメッセージのみを転送できます。
重要
JMS ブリッジは、HornetQ が専用のバックアップとして設定された EAP 6 サーバーにデプロイできません。そのため、専用のバックアップサーバーのトランザクションマネージャーは、HornetQ ライブサーバーで以前に開始したトランザクションをリカバリーできないからです。

18.13.2. JMS ブリッジの作成

概要

JMS ブリッジはソースの JMS キューまたはトピックからメッセージを消費し、通常は異なるサーバーにあるターゲット JMS キューまたはトピックへ送信します。JMS 1.1 に準拠する JMS サーバーの間でメッセージをブリッジするために使用できます。送信元および宛先の JMS リソースは、JNDI を使用してルックアップされ、JNDI ルックアップのクライアントクラスはモジュールでバンドルされる必要があります。モジュール名は JMS ブリッジ設定で宣言されます。

手順18.2 JMS ブリッジの作成

この手順では、JMS ブリッジを設定して、メッセージを JBoss EAP 5.x サーバーから JBoss EAP 6 サーバーへ移行する方法を示します。
  1. ソース JMS メッセージングサーバーでのブリッジの設定
    サーバータイプに記載されている手順に従って、ソースサーバーに JMS ブリッジを設定します。JBoss EAP 5.x サーバーに JMS ブリッジを設定する方法の例は、JBoss EAP 6 『『移行ガイド』』 『の「JMS ブリッジの作成』 」