7. WebOTXの内部サービス

7.1. TPシステム

TPシステムに関する運用操作法について説明します。 WebOTX V6.3以降の統合運用管理ツールでは、WebOTX V5の運用管理ツールと比べてショートカットキーが一部以下のように変更されています。

7.1.1. 操作・状態確認(TPシステム)

7.1.1.1. 設定の変更

統合運用管理ツールから設定

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューよりWebOTXシステム[TPシステム]を選択します。
3. リストビューより変更したい項目を選択し、変更します。

図7.1.1.1-1

コマンドから設定

1. otxadminコマンドを起動し、ドメインにログインします。

   otxadmin> login --user admin --password adminadmin --port 6212
   

2. 現在設定している値を確認します。

   otxadmin> get tpsystem.*
   

3. 変更したい属性を変更します。

   otxadmin> set tpsystem.serverName=host1
   

注意事項

システムパラメータ、イベントジャーナル、ジャーナルに関する設定はTPシステムが停止している必要があります。

7.1.1.2. 設定値の説明

7.1.1.3. 起動・停止

統合運用管理ツールから起動・停止

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューよりWebOTXシステム[TPシステム]を選択します。
3. 右クリックメニューより「システムの起動」あるいは「システムの停止」を実行します。

図7.1.1.3-1

コマンドから起動・停止

1. otxadminコマンドを起動し、ドメインにログインします。

   otxadmin> login --user admin --password adminadmin --port 6212
   

2. 起動・停止を実行します。
   
   起動

   otxadmin> start-system
   

   停止

   otxadmin> stop-system
   

7.1.1.4. 状態

WebOTXシステム(TPシステム)の状態について説明します。

注意事項

ドメイン起動中（TPモニタ・マネージャライフサイクル起動処理中）にTPシステムの状態チェックコマンドを実行すると、TPモニタ・マネージャライフサイクルの起動に失敗することがあります。 ドメインが起動状態になってから状態チェックを行ってください。

IIOPリスナの状態は、個別に起動停止することはできません。 TPシステムの起動停止に合わせて動作します。 状態に関しては、TPシステムの状態と同じです。 アライブチェックを行うために、TPモニタ・マネージャからIIOPリスナに対してセッションを1本張ります。 このアライブチェックに失敗した場合、起動停止処理失敗となります。

7.1.2. 操作・状態確認(アプリケーショングループ)

7.1.2.1. 作成・削除

統合運用管理ツールから新規作成

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューよりTPシステム配下のアプリケーショングループを選択します。
3. 右クリックメニューより「アプリケーショングループの新規作成」を実行します。
4. 新規作成するアプリケーショングループ名を入力し、作成します。

図7.1.2.1-1

統合運用管理ツールから削除

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューよりTPシステム配下のアプリケーショングループを選択します。
3. 右クリックメニューより「アプリケーショングループの削除」を実行します。
4. 削除するアプリケーショングループ名を選択し、削除します。

なお、直接該当アプリケーショングループ名のノードを選択して右クリックメニューより「アプリケーショングループの削除」を実行することもできます。

コマンドから新規作成・削除

1. otxadminコマンドを起動し、ドメインにログインします。

   otxadmin> login --user admin --password adminadmin --port 6212
   

2. アプリケーショングループ名を指定して新規作成・削除を実行します。
   
   新規作成

   otxadmin> create-apg apg
   

   削除

   otxadmin> delete-apg apg
   

注意事項

アプリケーショングループ作成後にドメインのパスを変更することはできません。

7.1.2.2. 設定の変更

統合運用管理ツールから設定

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューより設定を変更するアプリケーショングループを選択します。
3. リストビューより変更したい項目を選択し、変更します。

図7.1.2.2-1

コマンドから設定

1. otxadminコマンドを起動し、ドメインにログインします。

   otxadmin> login --user admin --password adminadmin --port 6212
   

2. 現在設定している値を確認します。

   otxadmin> get tpsystem.applicationGroups.apg.*
   

3. 変更したい属性を変更します。

   otxadmin> set tpsystem.applicationGroups.apg.applicationGroupAutoStart=true
   

注意事項

アプリケーショングループの各プロパティについては、アプリケーショングループ起動中でも設定は可能ですが、設定内容を反映させるにはアプリケーショングループの再起動が必要です。

7.1.2.3. 設定値の説明

7.1.2.4. 起動・停止

統合運用管理ツールから起動・停止

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューより起動・停止するアプリケーショングループを選択します。
3. 右クリックメニューより「アプリケーショングループの起動」あるいは「アプリケーショングループの停止」を実行します。 強制停止を行う場合は「アプリケーショングループの強制停止」を実行します。

図7.1.2.4-1

コマンドから起動・停止

1. otxadminコマンドを起動し、ドメインにログインします。

   otxadmin> login --user admin --password adminadmin --port 6212
   

2. 起動・停止を実行します。
   
   起動

   otxadmin> start-apg apg
   

   停止

   otxadmin> stop-apg apg
   

   強制停止

   otxadmin> stop-apg --force=true apg
   

強制停止について

停止しようとしているプロセスグループがクライアントからのオペレーション実行中の場合、通常停止処理が失敗(タイムアウト)する場合があります。 通常停止を行なっても停止できない場合は強制停止を行なって停止させてください。 なお、強制停止を行なった場合実行中の処理は強制的に終了させますので、処理の保証は行なえません。 したがって強制停止は通常停止が行なえない場合に限り利用ください。

7.1.2.5. 状態

アプリケーショングループの状態について説明します。

7.1.3. 操作・状態確認(プロセスグループ)

7.1.3.1. 作成・削除

統合運用管理ツールから新規作成

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューよりアプリケーショングループ配下のプロセスグループを選択します。
3. 右クリックメニューより「プロセスグループの新規作成」を実行します。
4. 新規作成するプロセスグループ名を入力し、WebOTXバージョンとモジュールの種類を選択して作成します。

図7.1.3.1-1

モジュールの種類は以下の通りです。 コマンド指定時文字列は、運用管理コマンドからプロセスグループを作成するときに指定します。

統合運用管理ツールから削除

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューよりアプリケーショングループ配下のプロセスグループを選択します。
3. 右クリックメニューより「プロセスグループの削除」を実行します。
4. 削除するプロセスグループ名を選択し、削除します。

なお、直接該当プロセスグループ名のノードを選択して右クリックメニューより「プロセスグループの削除」を実行することもできます。

コマンドから新規作成・削除

1. otxadminコマンドを起動し、ドメインにログインします。

   otxadmin> login --user admin --password adminadmin --port 6212
   

2. プロセスグループ名を指定して新規作成・削除を実行します。 新規作成時はWebOTXバージョンとモジュールの種類も設定します。 モジュールの種類は前述の通りです。
   
   新規作成

   otxadmin> create-pg --version 8 --kind javaee --apgroup apg pg
   

   削除

   otxadmin> delete-pg --apgroup apg pg
   

注意事項

プロセスグループの作成、削除は、アプリケーショングループ起動中の場合は実行できません。 アプリケーショングループを停止して実行してください。

7.1.3.2. 設定の変更

統合運用管理ツールから設定

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューより設定を変更するプロセスグループを選択します。
3. リストビューより変更したい項目を選択し、変更します。

図7.1.3.2-1

コマンドから設定

1. otxadminコマンドを起動し、ドメインにログインします。

   otxadmin> login --user admin --password adminadmin --port 6212
   

2. 現在設定している値を確認します。

   otxadmin> get tpsystem.applicationGroups.apg.processGroups.pg.*
   

3. 変更したい属性を変更します。

   otxadmin> set tpsystem.applicationGroups.apg.processGroups.pg.processCount=1
   

4. リストのように配列指定する場合は、{{変数1,値1},{変数2,値2},...}として指定します。

   otxadmin> set tpsystem.applicationGroups.apg.processGroups.pg.javaSystemPropertyList={{var1,value1},{var2,value2}}
   

注意事項

プロセスグループの各プロパティについては、アプリケーショングループ起動中でも設定は可能ですが、設定内容を反映させるにはアプリケーショングループの再起動が必要です。

7.1.3.3. 設定値の説明

7.1.3.4. 起動・停止

統合運用管理ツールから起動・停止

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューより起動・停止するプロセスグループを選択します。
3. 右クリックメニューより「起動」あるいは「停止」を実行します。 強制停止を行う場合は「プロセスグループの強制停止」を実行します。

図7.1.3.4-1

コマンドから起動・停止

1. otxadminコマンドを起動し、ドメインにログインします。

   otxadmin> login --user admin --password adminadmin --port 6212
   

2. 起動・停止を実行します。
   
   起動

   otxadmin> start-pg --apgroup apg pg
   

   停止

   otxadmin> stop-pg --apgroup apg pg
   

   強制停止

   otxadmin> stop-pg --apgroup apg --force=true pg
   

強制停止について

停止しようとしているプロセスグループがクライアントからのオペレーションが実行中の場合、通常停止処理が失敗(タイムアウト)する場合があります。 通常停止を行なっても停止できない場合は強制停止を行なって停止させてください。 なお、強制停止を行なった場合実行中の処理は強制的終了させますので、処理の保証は行なえません。 したがって強制停止は通常停止が行なえない場合に限り利用ください。

7.1.3.5. 状態

プロセスグループの状態について説明します。

7.1.4. 操作・状態確認(モジュール)

7.1.4.1. 設定の変更

統合運用管理ツールから設定

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューより設定を変更するモジュールを選択します。
3. リストビューより変更したい項目を選択し、変更します。

図7.1.4.1-1

コマンドから設定確認

1. otxadminコマンドを起動し、ドメインにログインします。

   otxadmin> login --user admin --password adminadmin --port 6212
   

2. 現在設定している値を確認します。

   otxadmin> get applications.j2ee-applications.ShopApp.ShopApp.ear.*
   

3. 変更したい属性を変更します。

   otxadmin> set applications.j2ee-applications.ShopApp.ShopApp.ear.sharedComponentList=shareApp
   

注意事項

モジュールの各プロパティについては、プロセスグループ起動中でも設定は可能ですが、設定内容を反映させるにはプロセスグループの再起動が必要です。

7.1.4.2. 設定値の説明

7.1.4.3. 活性化・閉塞

統合運用管理ツールから活性化・閉塞

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューより活性化・閉塞するモジュールを選択します。
3. 右クリックメニューより「活性化」あるいは「閉塞」を実行します。

図7.1.4.3-1

コマンドから活性化・閉塞

1. otxadminコマンドを起動し、ドメインにログインします。

   otxadmin> login --user admin --password adminadmin --port 6212
   

2. 活性化・閉塞を実行します。
   
   活性化

   otxadmin> invoke applications.j2ee-applications.ShopApp.ShopApp.ear.enable
   

   閉塞

   otxadmin> invoke applications.j2ee-applications.ShopApp.ShopApp.ear.disable
   

7.1.4.4. 状態

モジュールの状態について説明します。

7.1.5. 操作・状態確認(インタフェース)

7.1.5.1. 設定の変更

統合運用管理ツールから設定

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューより設定を変更するオブジェクトを選択します。
3. リストビューより変更したい項目選択し、変更します。

図7.1.5.1-1

コマンドから設定確認

1. otxadminコマンドを起動し、ドメインにログインします。

   otxadmin> login --user admin --password adminadmin --port 6212
   

2. 現在設定している値を確認します。

   otxadmin> get applications.j2ee-applications.ShopApp.ShopApp.ear.ShopEJB.Shop.*
   

3. 変更したい属性を変更します。

   otxadmin> set applications.j2ee-applications.ShopApp.ShopApp.ear.ShopEJB.Shop.maxGenerationObject=0
   

7.1.5.2. 設定値の説明

7.1.6. 操作・状態確認(オペレーション)

7.1.6.1. 設定の変更

統合運用管理ツールから設定

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューより設定を変更するオペレーションを選択します。
3. リストビューより変更したい項目選択し、変更します。

図7.1.6.1-1

コマンドから設定確認

1. otxadminコマンドを起動し、ドメインにログインします。

   otxadmin> login --user admin --password adminadmin --port 6212
   

2. 現在設定している値を確認します。

   otxadmin> get applications.j2ee-applications.ShopApp.ShopApp.ear.ShopEJB.Shop.*
   

3. 変更したい属性を変更します。

   otxadmin> set applications.j2ee-applications.ShopApp.ShopApp.ear.ShopEJB.Shop.addAccount(int).exetimeMax=-1
   

7.1.6.2. 設定値の説明

7.1.6.3. 起動・停止

統合運用管理ツールから起動・停止

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューより活性化するオペレーションを選択します。
3. 右クリックメニューより「起動」あるいは「停止」を実行します。

図7.1.6.3-1

コマンドから設定確認

1. otxadminコマンドを起動し、ドメインにログインします。

   otxadmin> login --user admin --password adminadmin --port 6212
   

2. 起動・停止を実行します。
   
   起動

   otxadmin> invoke applications.j2ee-applications.ShopApp.ShopApp.ear.ShopEJB.Shop.addAccount(int).start
   

   停止

   otxadmin> invoke applications.j2ee-applications.ShopApp.ShopApp.ear.ShopEJB.Shop.addAccount(int).stop
   

7.1.6.4. 状態

オペレーションの状態について説明します。

7.1.7. 設定詳細

7.1.7.1. クライアント制御

接続しているクライアント制御の設定について以下に示します。

クライアント情報の表示

統合運用管理ツールで[クライアントセッション]を選択することにより現在接続しているクライアントに関する情報を表示します。 ただし thinクライアントから利用している場合は、実際にTPシステムにアクセスを行っているのはWebコンテナであるため、Webコンテナの情報が表示され、実際のブラウザの情報は表示されません。

V6.5より、IIOPリスナのアライブチェックを行うため、TPモニタ・マネージャよりIIOPリスナに対してセッションを1本張っています。 このときのIPアドレスは127.0.0.1です（127.0.0.1であるセッションすべてがアライブチェック用のセッションとは限りません）。 このセッションは切断しないように注意してください。 切断した場合、IIOPリスナが起動停止失敗(failed)状態になります。 ただし、つぎのアライブチェック時にセッションを張りなおします。

クライアントの強制切断

接続しているクライアントを統合運用管理ツール上で切断することができます。

1. 統合運用管理ツールで[クライアントセッション]を選択します。
2. [操作]-[クライアント切断]メニューを実行します。
3. 切断したいクライアントを設定し、切断を実行します。

クライアントにメッセージ送信

接続しているクライアントに統合運用管理ツールよりメッセージを送ることができます。 ただし、メッセージが送れるクライアントはクライアント管理ライブラリをリンクしているCORBAのクライアントアプリケーションのみです。

1. 統合運用管理ツールで[クライアントセッション]を選択します。
2. [操作]-[メッセージ送信]メニューを実行します。
3. メッセージを送りたいクライアントを設定し、メッセージを入力して実行ボタンを押します。

クライアントに送信するメッセージは187バイト以内で指定します。 メッセージに半角セミコロン";"は使用できません。

クライアント無通信監視

接続しているクライアントより、一定時間が経過してもオペレーション呼び出しがない場合、強制的にクライアントからの接続を切断させることができます。

1. 統合運用管理ツールで[IIOPリスナ]を選択します。
2. [クライアント制御]を選択し、[クライアント無通信監視を行う]をチェックします。
3. [クライアント無通信監視間隔]に監視時間を秒単位(60〜2147483)で指定します。
4. 設定を反映させるためにTPシステムを再起動します。

クライアントアライブチェック

クライアント及び回線の有効性を確認するため、WebOTXの機能を使用して所定の間隔でアライブチェックを行うことができます。 アライブチェックで応答がないクライアントは強制的に切断されます。 ただし、アライブチェックが可能なクライアントはクライアント管理ライブラリを使って決められた手続きを行っているCORBAのクライアントアプリケーションのみです。 クライアント管理ライブラリを使っていないクライアントがいる環境でクライアントアライブチェックを使用しても害はありませんが機能しません。

1. 統合運用管理ツールで[IIOPリスナ]を選択します。
2. [クライアント制御]を選択し、[クライアントアライブチェックを行う]をチェックします。
3. [クライアントアライブチェック間隔]に監視時間を秒単位(60〜2147483)で指定します。
4. 設定を反映させるためにTPシステムを再起動します。

接続クライアント情報のホスト名表示

統合運用管理ツールの[クライアントセッション]では接続しているクライアントのホスト名の表示を行っています。 ただ、クライアントのIPアドレスからホスト名への変換ができない場合に、ホスト名変換ができずにWebOTX全体のレスポンスを悪化させてしまいます。 そのような環境の場合は接続クライアント情報のホスト名表示を行わない指定をする必要があります。

1. 統合運用管理ツールで[TPシステム]を選択します。
2. [クライアント制御]を選択し、[クライアント情報表示時にホスト名の逆引き処理を行う]からチェックを外します。
3. 設定を反映させるためにTPシステムを再起動します。

TCPレベルでのアライブチェック

クライアント及び回線の有効性を確認するため、OSの機能を使用してアライブチェックを行うことができます。 アライブチェックで応答がないクライアントは強制的に切断されます。 WebOTXの機能を使ったCORBAのクライアントアプリケーションのアライブチェックと違って本機能は全てのクライアントに有効です。 但し、アライブチェック間隔はOS側の設定となります。 OS側の設定については [ 高度な管理と運用サイクルガイド > 2. チューニング > 2.9. 通信 > 2.9.1. TCP/IPに関する設定 ] を参照してください。

TPシステムに関しては以下の手順で設定してください。

1. 統合運用管理ツールで[TPシステム]を選択します。
2. [クライアント制御]を選択し、[TCPレベルでのアライブチェックを行う]をチェックします。
3. 設定を反映させるためにTPシステムを再起動します。

7.1.7.2. 常駐オブジェクト

常駐オブジェクトの登録・置換

常駐オブジェクトは、あらかじめ共有コンポーネントとして登録されている必要があります。 統合運用管理ツール上で[アプリケーション]を選択し、[操作]-[コンポーネントの配備]コマンドを実行すると、コンポーネント(C++,VC++.NETの場合は.DLL(.SL,.SO),Javaの場合は.ZIPもしくは.JAR)を追加または置換することができます。

常駐オブジェクトとして登録する場合は.IFファイルを指定する必要はありません。 常駐オブジェクトとして使用する場合、プロセスグループのプロパティにおいて常駐オブジェクト名を指定する必要があります。

常駐オブジェクトの設定

統合運用管理ツールで、常駐オブジェクトを使用するプロセスグループの設定を行います。

統合運用管理ツールを起動し、ドメインと接続します。 プロセスグループを選択し[常駐オブジェクト]を選択して[常駐オブジェクトを使用する]にチェックを入れて更新します。 配下に[常駐オブジェクト]が表示されますのでそれを選択し[操作]-[複数常駐オブジェクトの設定]を実行して以下の項目について設定します。

ここで登録した常駐オブジェクトはコールバック呼び出しの際にリストの登録順に呼び出されます。 また、Javaの場合はクラスパスにこの順番で追加されます。

順番を変えたいときは設定した常駐オブジェクトを選択し、[常駐オブジェクト]の[ロード順]を変更してください。

注意事項

• オブジェクト識別名が同一である場合、設定は上書きされます。 また、Javaにおいてはオブジェクト識別名、オブジェクトファイル名が違ってオブジェクトクラス名が同じ、というパターン（下表Javaパターン7）は設定できません。

常駐オブジェクトの削除

削除したい場合は[常駐オブジェクト]を選択し、[複数常駐オブジェクトの削除]などの削除メニューを実行してください。 削除する項目を選択して削除を実行してください。

注意事項

常駐オブジェクトを削除する場合、そのオブジェクトをロードしているサーバアプリケーションを含むアプリケーショングループを停止する必要があります。

7.1.7.3. 共有コンポーネント

各プロセスが共通に使用するコンポーネントや共通の基底クラスをもつコンポーネントなどは共有コンポーネントとして追加します。 以下に共有コンポーネントの設定について示します。

共有コンポーネントの登録・置換

統合運用管理ツール上で[アプリケーション]を選択し、[操作]-[コンポーネントの配備]コマンドを実行して配備します。 コンポーネントタイプとして、共有コンポーネントを選択してください。

また、共有コンポーネントとして登録されているifファイルを指定してコンポーネントを登録することができます。 複数実装を実現する際、共通部分は共有コンポーネントとして作成してあらかじめ登録しておき、実装部分のみを個別に作成してコンポーネントとして登録することができます。 共有部分として作成したコンポーネントをここで登録してください。

ifファイルのみを登録することもできます。 コンポーネント登録時にこのifファイルを参照することができます。

共有コンポーネントとして使用する場合、モジュールのプロパティにおいて共有コンポーネント名を指定する必要があります。 使用しないものについては、モジュールのプロパティから共有コンポーネント名を削除する必要があります。 使用しない場合、共有コンポーネント情報は継承されません。

共有コンポーネントのプロパティにおいて、「全てのコンポーネントで使用する」チェックボックスをチェックしたときは、全てのモジュールのプロパティにおいて使用する設定になります（既定値:使用しない）。 ただし、チェックをはずした場合はモジュールのプロパティを変更しません。 モジュールのプロパティ設定はそのままになります。

また、チェックしてある場合、以降に配備したモジュールは自動的にその共有コンポーネントを使用する設定になります。 チェックしていない場合は、以降に配備したモジュールは自動的にその共有コンポーネントを使用しない設定になります。

継承情報の更新はプロセスグループを選択し、[操作]-[継承情報の更新]コマンドを実行してください。

共有コンポーネントの削除

統合運用管理ツール上で[アプリケーション]配下のアプリケーション名を選択し、[操作]-[配備解除]コマンドを実行して配備解除します。

注意事項

• 共有コンポーネントを削除する場合、そのオブジェクトをロードしているサーバアプリケーションをすべて停止する必要があります。
• WebOTX V5までは共有コンポーネントにJDBCドライバのアーカイブファイルを登録することにより、アプリケーションからJDBCドライバクラスをロードすることができましたが、V6ではクラスローダの実装が変わっているためJDBCドライバのクラスはロードすることができません。 クラスパスの設定で行なってください。

共有コンポーネントのifファイルを使用してコンポーネントの配備をしている場合、共有コンポーネントの削除によってそのコンポーネントが正常に動作しなくなります。 削除前にコンポーネントのほうから削除してください。

7.1.7.4. 名前サーバへの登録

名前サーバへの登録

CORBAコンポーネントでは名前サーバへのInteroperable Object Reference(IOR)登録URLをcorbaname形式で任意に指定することができます。EJBコンポーネントの場合URLはcorbaname://*となります。

また、その登録を永続化するか一時的に扱うかを選択し、どのタイミングで名前サーバに登録するかを選択することができます。 名前サーバへのIOR登録方法は名前サーバへの負荷を軽減するため"永続的に扱う"が既定値です。 つまり、プロセス起動時に自動で登録されないため、運用管理ツールから手動で登録を行う必要があります。 プロセス起動時に自動で登録する場合は運用管理ツールから名前サーバの登録で"一時的に扱う"設定にしてください。 システムの名前サーバの登録でも"一時的に扱う"設定にすることができます。

1. 統合運用管理ツールを起動し、ドメインと接続します。
2. インタフェースの[名前サーバへの登録]を選択し[名前サーバへの登録名]を選択します。 [任意に設定する」を選択した場合、名前サーバへの登録URL等の設定が可能になります。 [登録は行わない]を選択した場合は、名前サーバへの登録は行いません。
3. [任意に設定する]を選択した場合、[名前サーバのリスト]に登録用URLをcorbaname形式で任意に指定します。 既定値はV4.2までの登録URLです。 IDLファイルのモジュール名、インタフェース名から構築されます。
   旧バージョンでCORBAコンポーネントを登録した場合は名前サーバのルートに直接登録されるURLも既定値として存在します。
4. [名前サーバへの登録]にて永続的に扱うか一時的に扱うかを選択してください。 永続的に扱う場合、任意のタイミングで登録できます。 また、プロセスが停止してもその情報は登録されたままになります。 プロセス起動時の名前サーバアクセス負荷を軽減することができます。
   一時的に扱う場合、プロセス起動時にWebOTX内部で登録を行います。 プロセス停止時に削除されます。 ユーザが明示的に名前サーバへの登録を行う必要はありません。
   [システムの設定を参照する]にチェックを入れている場合はTPシステムの[名前サーバへの登録]で設定されている値が引き継がれます。
5. [登録するIORの生成方式]で、シングルサーバで扱う場合はチェックをはずしてください（既定値）。 複数サーバに関する設定を行う場合は、チェックを入れて[複数サーバシステムグループ名]を設定してください。 名前サーバへの登録時、システムグループに設定されている全TPシステムの情報を登録します。
   [複数サーバシステムグループ名]はツリービューから[マルチサーバ]を選択して設定することができます。
   詳細は [ 7.1.7.5. マルチサーバラウンドロビン負荷分散運用 ] をご覧ください。
6. ラウンドロビン機能を利用する場合は、[ラウンドロビン機能を使用する]にチェックを入れてください。 同一のサーバアプリケーションが登録されたTPシステム間で負荷分散を行います。(既定値:行う)

名前サーバに登録したオブジェクトリファレンスの確認

サーバアプリケーションのオブジェクトは、WebOTXが名前サーバに登録するほかに、ユーザが任意に登録することができます。 その登録内容をWindows版のOrbManagerを使用して確認することができます。 以下にその確認方法について示します。

1. WebOTXインストールディレクトリにObject Brokerがインストールされます。 そのbinディレクトリ配下にあるorbmanag.exeを起動します。
2. 該当名前サーバに登録されているオブジェクト一覧が確認できます。 設定したcorbaname形式の“/”を区切りとしたツリーとして表示されます。

なお、orbmanag.exeは指定したホストで名前サーバが起動していないとエラーになります。 かならず名前サーバが起動しているホスト名を指定して下さい。

orbmanag.exe起動中にオブジェクトが登録された時、ツリービューが構築されない時はツリーを一度閉じてください。

インタフェース削除後のIOR削除

IORを永続的に扱う設定をしている場合、IORの削除をしないうちにコンポーネント削除や置換によるインタフェース名の変更・削除があると、登録されたIORは無効となります。 運用管理ツールからは情報が消えるため削除できなくなりますのでコンポーネント削除やインタフェース名変更前に名前サーバからIORを削除してください。 IORを一時的に扱う設定にしている場合はプロセス停止時にWebOTXが削除します。

IOR削除前にインタフェース名を変更・削除してしまった場合は、実行環境のIOR削除コマンドwoiorunbindで手動削除してください。 この時指定するURLは、名前サーバホスト名の省略はできません。

コマンドは以下の位置にインストールされています。

• Windows:${AS_INSTALL}\Trnsv\bin\woiorunbind
• UNIX:${AS_INSTALL}/Trnsv/command/woiorunbind

URLを指定できずコマンドも使用できないという場合はOrbManagerを起動し、手動で削除してください。 起動の方法に関しては名前サービスに登録したオブジェクトリファレンスの確認を参照してください。

ただし、このツールで表示されるURLはユーザが手動登録したIOR以外も含まれます。 WebOTXが自動登録したIORやWebOTX製品自身が動作するのに必要なIORを削除した場合、動作が不定になります。 IOR削除は極力運用管理ツールでインタフェース変更・削除前に行うかIOR削除コマンドで行ってください。どうしてもOrbManagerを使用しなければならない場合は誤って他のIORを削除することのないよう取り扱いには十分注意してください。

1. URLを登録したホストにアクセスし、左側の"Root Context"をダブルクリックしてください。
   ホスト名の変更はメニューの[参照先]-[ホスト名指定]で行うことができます。
2. 登録したURLがツリー構造になっていますので、該当URLを探してください。
   最後まで探してクリックすると右側に"Object Name"が表示されます。
3. 削除する名前を選択し、メニューの[オブジェクト]-[アンバインド]を実行してください。

CORBAアプリケーションの自動名前登録

CORBAアプリケーションの自動名前登録の設定を以下に示します。

運用管理ツールからの配備時に自動名前登録を行う場合は、[TPシステム]-[アプリケーション]を右クリックし、表示されたメニューより[コンポーネントの配備]を選択します。
[コンポーネントの配備]-[CORBA関連情報]の名前サーバの登録方式を"永続的に扱う"を選択し、配備を行います。

図7.1.7.4-1

また、運用管理コマンドからの配備時に自動名前登録を行う場合は、以下のコマンドを使用し"--bindtype"オプションを使用します。
詳細は、deployコマンドを参照してください。

otxadmin> deploy --apgroup <アプリケーショングループ名> --pgroup <プロセスグループ名> --bindtype=<transient|persistent> <配備するファイル>

7.1.7.5. マルチサーバラウンドロビン負荷分散運用

マルチサーバラウンドロビン負荷分散はEJBのホームインタフェース、ステートレスセッションBeanのリモートインタフェース、CORBAアプリケーションのオブジェクトリファレンスに複数の接続先の情報を含める(IOR 多重化)ことにより、クライアントからのオペレーション呼び出し毎にラウンドロビン方式で接続先を決定することにより、複数ドメイン間の負荷分散運用を行うことができます。

オブジェクトのIORにマルチサーバの定義を行うためのサーバ、クライアントの設定について説明します。

7.1.7.5.1. サーバ実行環境の設定

サーバ実行環境においては、統合運用管理ツールを使って以下の設定を行います。 全てのサーバで同一の設定を行ってください。

1. [名前サーバへの登録]の設定
   TPシステムのプロパティで[名前サーバへの登録]を[永続的に扱う]に設定します。
2. 複数サーバの設定
   [マルチサーバ]を選択し、[操作]-[システムグループの設定]でシステムグループを作成します。 配下にシステムグループが作成されるので、[操作]-[サーバセットの設定]を実行して自システムを含め負荷分散を行うTPシステム全てを登録します。 いくつかの負荷分散パターンがある場合は複数のシステムグループを作成してください。
3. インタフェースの設定
   インタフェースの属性で負荷分散を行う全てのインタフェースに、次の設定を行います。 [名前サーバへの登録]について[システムの設定を参照する]とし[永続的に扱う]にします。 [登録するIORの生成方式]にチェックを入れ、[複数サーバシステムグループ名]に[マルチサーバ]で作成したシステムグループ名を指定します。
4. IORの登録
   インタフェースを選択して、[操作]-[名前サーバへ登録]を実行し、IORを名前サーバに登録します。 この作業は全てのシステムで実行してください。 登録を行うときに、各TPシステムに対してポート番号やSSLの設定などの情報取得を行いますので、全てのサーバのWebOTXシステムを起動させた状態で実行してください。

7.1.7.5.2. クライアント実行環境の設定

マルチサーバ負荷分散を行うためのクライアント実行環境の設定について説明します。

C++,VB

クライアントの実行環境においては、レジストリまたはAPIで以下の設定を行います。

1. レジストリで設定する場合
   MultiConnection=true,ConnectionRoundRobin=true に設定されているかをご確認下さい。既定値はtrueです。
   設定に関する詳細は[ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.10. Object Broker > 1.10.1. Object Broker設定項目・設定方法 ]をご覧ください。
2. APIで設定する場合
   Ob_use_multi_connection及び__use_connection_roundrobinの設定を行ってください。
   設定方法に関する詳細は[ リファレンス集 開発編（共通） > 4. CORBA > 4.4. WebOTX Object Broker C++ > 4.4.9. オブジェクト多重化を利用するためのインタフェース ] をご覧ください。

Java

クライアントの実行環境においては、システムプロパティまたはAPIで以下の設定を行います。

1. システムプロパティで設定する場合
   UseMultiConnection=true,UseConnectionRoundRobin=true に設定されているかをご確認下さい。既定値はtrueです。
   設定方法に関する詳細は[ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.10. Object Broker > 1.10.2. Object Broker JavaにおけるORBのプロパティ定義 ]をご覧ください。
2. APIで設定する場合
   setUseMultiConnection及びsetUseConnectionRoundRobinの設定を行ってください。
   設定に関する詳細はリファレンス集 開発編 (共通)の jp.co.nec.orb.Config をご覧ください。

注意事項

ステートレスセッションBeanやファクトリを使用したCORBAアプリケーションをステートレスで動作させる場合、クライアントでオペレーション呼び出し毎、もしくは頻繁にEJBホームインターフェースのcreate()、CORBA ファクトリオブジェクトのCreateServerObject()を呼び出してオブジェクトリファレンスを取得すると負荷が偏るのでご注意下さい。これはcreate()、CreateServerObject()で取得したリファレンスに対する呼び出しは複数の接続先の中から同じ順番で振り分けられるためです。

7.1.7.6. 非同期トランザクション

非同期トランザクションの設定方法について以下に示します。

図7.1.7.6-1

1. 非同期トランザクションを行うための1stステージ、2ndステージコンポーネントを作成します。
2. 通常コンポーネント同様非同期トランザクションを行う1stステージ、2ndステージコンポーネントを登録します。
3. 1stステージコンポーネントを登録したプロセスグループのプロパティにて[非同期オペレーション呼び出し]を選択し、[非同期オペレーション呼び出しを行う]にチェックします。
4. トランザクション型VDを作成します。 [VDのプロパティ」では1stステージから呼び出される2ndステージのオペレーションとそれが属するアプリケーショングループ、プロセスグループ、モジュール名、インタフェース名を設定します。
5. トランザクション型VDを起動します。
6. 1stステージ、2ndステージのアプリケーショングループを起動します。

以下に、トランザクション型VDと間接型VDについて説明します。 端末型VDに関しては、[ 7.1.7.9. 帳票印刷(WebOTX Print Kit) ] を参照してください。

VDの作成 トランザクション型VD

1. 統合運用管理ツールを起動し、ドメインに接続します。
2. TPシステムを停止します。
3. [VDインフォメーション]を選択し、VDを使用するをチェックして最大VD数を設定します。
4. TPシステムを起動します。
5. [VDインフォメーション]を選択し[操作]-[トランザクション型VDの新規作成]を実行します。
6. VD名を英数字16文字以内で設定します。
   また、非同期オペレーションとして指定するオペレーション名と、そのオペレーションが属するアプリケーショングループ、プロセスグループ、モジュール、インタフェース名を指定します。 モジュール名は、アプリケーション名ではなくファイル名で指定してください。

VDの作成 間接型VD

1. 統合運用管理ツールを起動し、ドメインに接続します。
2. TPシステムを停止します。
3. [VDインフォメーション]を選択し、VDを使用するをチェックして最大VD数を設定します。
4. TPシステムを起動します。
5. [VDインフォメーション]を選択し[操作]-[トランザクション型VDの新規作成]を実行してトランザクション型VDを作成します。
6. [VDインフォメーション]を選択し[操作]-[間接型VDの新規作成]を実行します。
7. VD名を英数字16文字以内で設定します。 また、VDの型をラウンドロビンか滞留数優先か選択し、使用するトランザクション型VDのリストを選択します。

VDの削除

1. 統合運用管理ツールを起動し、ドメインに接続します。
2. VDが実行中である場合は、[VDインフォメーション]配下の該当VDを選択し、[操作]-[停止]を実行します。
3. [VDインフォメーション]を選択し[操作]- [削除]を実行して削除するVDを選択します。

なお、直接該当VD名のノードを選択して右クリックメニューより「削除」を実行することもできます。

VDの起動

1. 統合運用管理ツールを起動し、ドメインに接続します。
2. [VDインフォメーション]配下の該当VDを選択し、[操作]-[起動]を実行します。

VDの停止

1. 統合運用管理ツールを起動し、ドメインに接続します。
2. [VDインフォメーション]配下の該当VDを選択し、[操作]-[停止]を実行します。

VDの閉塞

1. 統合運用管理ツールを起動し、ドメインに接続します。
2. [VDインフォメーション]配下の該当VDを選択し、[操作]-[閉塞]を実行します。

VD滞留メッセージのクリア

1. 統合運用管理ツールを起動し、ドメインに接続します。
2. [VDインフォメーション]配下の該当VDを選択し、[操作]-[VD滞留メッセージのクリア]を実行します。

VDのプロパティ

1. 統合運用管理ツールを起動し、ドメインに接続します。
2. [VDインフォメーション]配下の該当VDを選択します。
3. 設定したい項目を設定します。

VDのプロパティについて以下に示します。 なおプロパティを設定する場合はVDを停止してから行ってください。

注意事項

• VDを使用するときは以下の設定を追加してください。
  ファイル名

  ${INSTANCE_ROOT}/config/tpsystem/mcs
  

  追加する設定

  VDCTLVDF ${INSTANCE_ROOT}/config/tpsystem/data/vd_cntl
  

• すでに非同期オペレーションとして登録されているオペレーションは選択できません。
• データファイルを多数利用するとVDの性能に影響があります。 ファイルを複数利用する必要がない場合、マスタデータファイルのみを利用してください。
• ディスクへのフラッシュを行うと、更新が行われるたびにディスクI/Oが発生し、性能が著しく劣化します。 通常はフラッシュを行わないでください。
• VDに関連するプロパティの変更を行った場合、VDデータ用のファイルを必ず初期化してください。 初期化せずにそのまま利用した場合の動作は保証されません。
• 非同期オペレーションを含むモジュールを配備解除するときは、先にトランザクション型VDを削除してください。
• トランザクション型VDの場合、呼び出したオペレーションをvdserverが監視しています。 終了待ち合わせ時間の既定値は30秒となっています。 この値を変更するためには以下の設定をする必要があります。
  1. 統合運用管理ツールを起動し、ドメインと接続します。
  2. [VDインフォメーション]を選択し、[呼び出したオペレーション終了待ち合わせ時間]を設定します。 設定を省略した場合の既定値は30です。 0秒を指定すると無限となります。
• 非同期オペレーションの最大電文サイズの既定値は32KBです（WebOTX内部で使用する領域を含む）。 この値を変更するためには以下の2つの設定をする必要があります。
  設定1
  1. 統合運用管理ツールを起動し、ドメインと接続します。
  2. [VDインフォメーション]を選択し、[非同期オペレーション電文サイズ]を設定します。 バッファサイズをKB単位の整数で指定してください。 範囲は32から9765KBです。
  設定2
  プロセスグループのプロパティの環境変数
  変数：TP_TX_DATA_SIZE
  値：非同期オペレーション電文サイズ
  値として上記で設定したバッファサイズをKB単位の整数で指定してください。

7.1.7.7. Transactionサービス連携

複数に分散されたデータベースの一括更新管理を行う場合、2フェーズコミットメント機能を提供する「Transactionサービス」を利用する必要があります。

TransactionサービスはFoundation、StandardまたはEnterpriseをインストールすると標準でインストールされます。 ただしリカバリサーバはインストール時に明示的にインストール指定を行う必要があります。 リカバリサーバを利用して分散トランザクション処理を実行する場合にはご注意ください。

次に、Transactionサービスと連携するための設定について示します。

図7.1.7.7-1

1. 統合運用管理ツールを起動し、ドメインと接続します。
2. ツリーの部分で、プロセスグループをクリックします。
3. 右側に表示される[Transaction Service]プロパティを選択し「Transaction Service連携を行う」をチェックします。 EJBの場合は、「Transaction Service連携を行う」が既定値です。
4. 「トランザクションの制御」の設定を行ないます。 Recovery Coordination Server(RCS)を使用してアプリケーションと同一の空間でトランザクション処理を実行するか、リカバリサーバを使用してトランザクション処理を実行するかを選択してください。
5. RCSを使用する場合で、WebOTX V5互換のアプリケーションを動作させる場合には「RCSID」の一覧が表示されますので、これも設定を行ってください。 WebOTX V6のアプリケーションでは設定の必要はありません。
6. 「OTSポリシ」を選択してください。 トランザクションの動作を指定します。
7. C++,VC++.NETアプリケーションの場合はオープンするデータベースを設定してください。 10個まで選択できます。 なお使用するデータベースは統合運用管理ツールのserver.transactionserviceの設定で追加できますので、予め設定しておいてください。 設定方法については [ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.9. Transactionサービス > 1.9.3. Transactionサービスに関する設定 ] をご参照ください。
   なお、リカバリサーバを利用する場合にはTransaction Service 運用管理ツールを使用して作成してください。 Java, EJBの場合は選択する必要はありません。

なお、連携時にはこれらのサービス(RCSもしくはリカバリサーバ)が起動している必要があります。

注意事項

リカバリサーバを利用してTransactionサービスとの連携を行う場合、リカバリサーバとのコネクションが常に張られた状態になります。 また、この時ライセンスを1つ消費します。

クライアント情報の画面に表示されますが手動で切断しないようにしてください。

7.1.7.8. ダウンローダ管理サービス

ダウンローダ管理ツールを使ってクライアント配布を行う場合や、syslog(unix)とイベントログ(Windows)に出力されるOTX190000xxメッセージを抑制する場合にはダウンローダ管理サービスの設定が必要です。 ダウンローダ管理サービスの設定について以下に示します。

ダウンローダ管理サービスの設定

ダウンローダ管理サービスの設定内容は次の通りです。 設定は統合運用管理ツールと運用コマンドから行うことができます。

統合運用管理ツールから設定

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューよりTPシステム内のダウンローダ管理サービスを選択します。
3. リストビューより変更したい項目選択し、変更します。

コマンドから設定

1. otxadminコマンドを起動し、ドメインにログインします。

   otxadmin> login --user admin --password adminadmin --port 6212
   

2. 現在設定している値を確認します。

   otxadmin> get tpsystem.downloaderManagerService.*
   

3. 変更したい属性名を指定して変更します。

   otxadmin> set tpsystem.downloaderManagerService.portNumber=port番号
   

4. 抑制メッセージ番号を複数指定する場合は、カンマ区切りで指定します。

   otxadmin> set tpsystem.downloaderManagerService.ignoreMessage=番号,番号,番号
   

7.1.7.9. 帳票印刷(WebOTX Print Kit)

WebOTX Print Kitなどを使って帳票印刷を行うためには端末型VDとOLFリスナの設定が必要です。 サーバ実行環境側の設定について以下に示します。

端末型VDの作成

1. 統合運用管理ツールを起動し、ドメインに接続します。
2. TPシステムを停止します。
3. [VDインフォメーション]を選択し、VDを使用するをチェックして最大VD数を設定します。
4. TPシステムを起動します。
5. [VDインフォメーション]を選択し[操作]-[端末型VDの新規作成]を実行します。
6. VD名を英数字16文字以内で設定します。

端末型VDの削除

1. 統合運用管理ツールを起動し、ドメインに接続します。
2. VDが実行中である場合は、[VDインフォメーション]配下の該当VDを選択し、[操作]-[停止]を実行します。
3. [VDインフォメーション]を選択し[操作]- [削除]を実行して削除するVDを選択します。

なお、直接該当VD名のノードを選択して右クリックメニューより「削除」を実行することもできます。

端末型VDの起動

1. 統合運用管理ツールを起動し、ドメインに接続します。
2. [VDインフォメーション]配下の該当VDを選択し、[操作]-[起動]を実行します。

端末型VDの停止

1. 統合運用管理ツールを起動し、ドメインに接続します。
2. [VDインフォメーション]配下の該当VDを選択し、[操作]-[停止]を実行します。

端末型VDの閉塞

1. 統合運用管理ツールを起動し、ドメインに接続します。
2. [VDインフォメーション]配下の該当VDを選択し、[操作]-[閉塞]を実行します。

VD滞留メッセージのクリア

1. 統合運用管理ツールを起動し、ドメインに接続します。
2. [VDインフォメーション]配下の該当VDを選択し、[操作]-[VD滞留メッセージのクリア]を実行します。

端末型VDのプロパティ

1. 統合運用管理ツールを起動し、ドメインに接続します。
2. [VDインフォメーション]配下の該当VDを選択します。
3. 設定したい項目を設定します。

VDのプロパティについて以下に示します。 なおプロパティを設定する場合はVDを停止してから行ってください。

${INSTANCE_ROOT}/config/tpsystem/vdf/<個別VDデータファイル名>

注意事項

• VDを使用するときは以下の設定を追加してください。
  ファイル名

  ${INSTANCE_ROOT}/config/tpsystem/mcs
  

  追加する設定

  VDCTLVDF ${INSTANCE_ROOT}/config/tpsystem/data/vd_cntl
  

• データファイルを多数利用するとVDの性能に影響があります。 ファイルを複数利用する必要がない場合、マスタデータファイルのみを利用してください。
• ディスクへのフラッシュを行うと、更新が行われるたびにディスクI/Oが発生し、性能が著しく劣化します。 通常はフラッシュを行わないでください。
• VDに関連するプロパティの変更を行った場合、VDデータ用のファイルを必ず初期化してください。
• 初期化せずにそのまま利用した場合の動作は保証されません。

OLFTPリスナの設定

OLFTPリスナに関する設定は統合運用管理ツールを実行し、ドメインと接続を行い[OLFTPリスナ]を選択して設定します。

7.1.7.10. プロセスグループの設定の動的変更

動的変更の設定について以下に示します。

動的変更方法

• 運用管理ツールより設定する場合
  動的設定変更に対応している項目を変更し、更新する。
  [TPシステム]-[アプリケーショングループ名]-[プロセスグループ名]を右クリックし、表示されたメニューより[動的に設定値を変更する]を選択します。
• 運用管理コマンドより設定する場合
  動的設定変更に対応している項目のMOの属性を変更後、以下のコマンドで実行することができます。
  (各設定に対応するMOの属性名は、 [ リファレンス集 運用管理・設定編 > 2. MO定義リファレンス ] を参照してください。)

  otxadmin> invoke tpsystem.aplicationGroups.<アプリケーショングループ名>.proecssGroups.<プロセスグループ名>.dynamicUpdateProperty

図7.1.7.10-1

以下の動作の場合は、再起動回数による起動リトライは行われず、旧設定のプロセスで動作継続します。

• 新設定のプロセス起動時にOutOfMemoryError等により、起動が失敗した場合
• 初期化完了通知のタイムアウトが発生した場合

旧設定のプロセスの終了でタイムアウトが発生した場合、タイムアウトの旨をプロセスIDとともにsyslog(またはイベントログ)に出力しますが、 再起動処理自体は正常終了となり、業務は新プロセスで継続します。

動的設定変更に対応している項目は以下となります。

• [TPシステム]-[アプリケーショングループ]-[プロセスグループ]-[トレース設定]
  • 標準出力の出力先
  • 標準エラー出力の出力先
• [TPシステム]-[アプリケーショングループ]-[プロセスグループ]-[JavaVMオプション]
  • 最大ヒープサイズ
  • 最大ヒープサイズの単位
  • 初期ヒープサイズ
  • 初期ヒープサイズの単位
  • スタックトレース採取時にJavaヒープの情報を採取する
  • Javaヒープの情報採取時に何位の情報まで出力するか
  • OutOfMemoryErrorの監視を行う
  • メモリ使用量閾値 (Old領域)
  • メモリ使用量閾値 (Parmanent領域)
  • メモリ使用量閾値の超過時GCを行う
  • GC後メモリ使用量閾値
  • GC後メモリ使用量閾値の超過時プロセス停止を行う
  • その他の引数
  • プロセス固有指定を行う
  • プロセス固有の引数
• [TPシステム]-[アプリケーショングループ]-[プロセスグループ]-[Javaシステムプロパティ]
  • Javaシステムプロパティ
• [TPシステム]-[アプリケーション]-[アプリケーション名]-[コンポーネント名]-[コンポーネント初期化関数]
  • コンポーネント初期化関数
• [TPシステム]-[アプリケーション]-[アプリケーション名]-[コンポーネント名]-[共有コンポーネント]
  • 使用する共有コンポーネント
• [TPシステム]-[CORBAアプリケーション(WebOTX J2EEアプリケーション)]-[アプリケーション名]-[コンポーネント名]-[インターフェース]-[事前生成オブジェクト]
  • オペレーションオールのモード
  • スレッディングモデル
  • オブジェクトの事前生成を行う
  • 事前生成オブジェクト数
  • 最大生成オブジェクト数

動的設定変更に関する設定及び状態

動的設定変更に関する以下の設定及び状態が追加になります。

• 動的設定変更時初期化待ち時間
  TPモニタがAPの初期化完了通知を待ち合わせる時間。(既定値:600sec)
• 動的設定変更時終了待ち時間
  TPモニタからの終了要求の完了待ち時間。(既定値:600sec)
  プロセスがストールしている場合、正常終了できないため、再起動処理が継続できなくなることを防止します。
• 動的設定変更状態
  動的設定変更の状態を示します。以下の状態があります。
  • 反映中 : 動的設定変更を反映のため、プロセスグループを再起動しています。
  • 反映失敗 : 動的設定変更に失敗しました。プロセスグループは変更反映前の状態で起動しています。
  • 変更無し : 変更を行っていません。

上記設定は、運用管理ツールの以下の箇所で設定・参照することができます。

• [TPシステム]-[アプリケーショングループ]-[プロセスグループ]-[プロセス制御]
  • 動的設定変更時初期化待ち時間
  • 動的設定変更時終了待ち時間
• [TPシステム]-[アプリケーショングループ]-[プロセスグループ]-[状態]
  • 動的設定変更状態

MOの属性名は以下となります。

• 動的設定変更時初期化待ち時間
  tpsystem.aplicationGroups.<アプリケーショングループ名>.proecssGroups.<プロセスグループ名>.dynamicUpdateInitWaitTime
• 動的設定変更時終了待ち時間
  tpsystem.aplicationGroups.<アプリケーショングループ名>.proecssGroups.<プロセスグループ名>.dynamicUpdateInitStopTime
• 動的設定変更状態
  tpsystem.aplicationGroups.<アプリケーショングループ名>.proecssGroups.<プロセスグループ名>.updateStatus

ログ出力

動的設定変更で出力するTPSメッセージは、 [ メッセージ一覧 > 3. TPシステム > 3.2. メッセージ一覧 > 3.2.4. イベントログ出力されないメッセージ ] を参照してください。

7.1.7.11. 予備スレッドの事前生成と活性化

予備スレッドの事前生成と活性化の設定を以下に示します。
予備スレッドはプロセス起動時には閉塞状態となっており、オペレーションの実行を行うことができません。
予備スレッドの閉塞・閉塞解除は、[TPシステム]-[アプリケーショングループ名]-[プロセスグループ名]を右クリックし、表示されたメニューより[動的多重度変更]の"スレッドの多重度"を設定することにより閉塞解除できます。このとき、"プロセス多重度"の設定は必須です。
スレッドの多重度は "スレッド数"+"予備スレッド数"の範囲で設定してください。

図7.1.7.11-1

図7.1.7.11-2

予備スレッド数は運用管理ツールから設定する場合、

• [TPシステム]-[アプリケーショングループ]-[プロセスグループ]-[スレッド制御]
  • 予備スレッド数(既定値:0)

で設定することができます。
また、運用管理コマンドからは以下のMOの属性に設定します。

• tpsystem.applicationGroups.<アプリケーショングループ名>.processGroups.<プロセスグループ名>.reserveThreads

7.1.7.12. アプリケーショングループ停止処理時間の短縮

プロセスグループの強制停止処理に即時強制停止する設定を以下に示します。
運用管理ツール上の設定項目は以下の通りとなります。

• [TPシステム]-[起動／停止]
  • プロセスを即時停止する

上記に対応するMOの属性は、

• tpsystem.immediateStopProcess

となります。

7.1.7.13. IIOPリスナ

RMI-IIOPのリクエストを処理するリスナです。統合運用管理ツールで設定できる項目は次の通りです。

SSL通信を行うための設定手順は次の通りです。

1. TPシステムを停止します。
2. [SSL]-[SSLを使用する]にチェックを入れます。
3. クライアント認証を行わない場合、[SSL]-[SSLポート番号クライアント認証なし]にチェックを入れ、ポート番号を指定します。クライアント認証を行う場合、[SSL]-[SSLポート番号クライアント認証あり]にチェックを入れ、ポート番号を指定します。必ずどちらかのポート番号を指定する必要があります。
4. OpenSSLを使用する場合、[SSLOpenSSL]-[秘密鍵ファイル名], [証明書ファイル名], [信頼するCAの証明書ファイル名]を全て指定します。フルパス指定不可ですのでファイル名のみ指定してください。セキュリティパックを使用する場合、[SSLSecureWare]-[鍵識別子]を指定します。
5. 設定完了後、更新ボタンを押します。
6. ${INSTANCE_ROOT}\config\tpsystem 配下に秘密鍵ファイル、証明書ファイル、信頼するCAの証明書ファイルを置きます。
7. 名前サーバへの登録が「永続的に扱う」設定である場合、名前サーバにIORを登録します。
8. TPシステムを起動します。

7.1.8. 統計情報(統合運用管理ツールでの表示)

統合運用管理ツールから確認できるスレッド情報、CPU情報、キュー情報、接続クライアント情報に関して説明します。

7.1.8.1. スレッド情報

起動しているプロセスグループのスレッド情報を見ることができます。

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューよりプロセスグループを選択します。
3. リストビューより動作情報を選択します。

7.1.8.2. プロセス情報

起動しているプロセスグループのプロセス情報を見ることができます。

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューよりプロセスグループを選択します。
3. リストビューより動作情報を選択します。

7.1.8.3. キュー情報

起動しているTPシステム全体のキュー情報を見ることができます。

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューより[キュー]を選択します。
3. リストビューよりキュー情報を選択します。

7.1.8.4. クライアントセッション情報

TPシステムと接続しているクライアント情報を見ることができます。

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューより[クライアントセッション]を選択します。
3. リストビューよりクライアント情報を選択します。

7.1.9. 統計情報(ジャーナル)

ジャーナルはWebOTXの稼働状況を評価するための性能及び統計情報を各種レポートとして提供します。 レポートの種類は以下の通りです。

• アクティビティレポート（レポートNo.01）
  指定された時間間隔におけるWebOTX全体の動作状況を表示します。 表示項目はCPU使用量(秒)、CPU使用率(%)、トランザクション数(件数、%)、スループット、レスポンス時間※(最大、最小、合計)、キュー滞留数(最大、最小、平均)です。
  
  
• トランザクションサマリレポート（レポートNo.02/03）
  アプリケーショングループ、プロセスグループ単位に発生したトランザクション処理状況を表示します。 表示項目はCPU時間の合計(秒、使用率)、トランザクション件数の合計(件数、%)、レスポンス時間※(最大、最小、合計)、キュー滞留数(最大、最小、平均)です。
  
  
• CPU時間タイムチャート（レポートNo.05/06/07）
  全体、アプリケーショングループ、プロセスグループ単位に、一定時間間隔におけるトランザクション処理とCPU時間の推移を表示します。 表示項目は単位時間あたりのCPU時間の合計とそのグラフ化です。
  
  
• トランザクション件数タイムチャート（レポートNo.09/10/11）
  全体、アプリケーショングループ、プロセスグループ単位に、一定時間間隔におけるトランザクション処理数の推移を表示します。 表示項目は単位時間あたりのトランザクション件数の合計とそのグラフ化です。
  
  
• トランザクション件数レスポンス時間グラフ（レポートNo.13/14/15）
  全体、アプリケーショングループ、プロセスグループ単位に、一定レスポンス時間内で処理されたトランザクションの数の一覧表示です。 表示項目はトランザクション件数とそのグラフ化です。
  ※レスポンス時間に対する補足事項
  本ジャーナルにおけるレスポンス時間とは、サーバAPにおいてユーザの実装を呼び出してからその結果が返るまでの時間を測定したものです。 通信リスナとの間のキューに滞留している時間は含まないことに注意して下さい。 なお、統合運用管理ツールにおいてオペレーションの情報として表示される最小/最大/平均レスポンス時間は、通信リスナとの間のキューに滞留している時間を含んでいます。

ジャーナル採取の手順は以下のようになります。

0. 準備
   下記で説明する各コマンドはWindowsでは${AS_INSTALL}\Trnsv\bin、UNIXでは${AS_INSTALL}/Trnsv/commandにあります。 UNIX版のWebOTXをご使用で、且つ、WebOTX運用ユーザを設定している場合は、WebOTX運用ユーザでコマンドを実行して下さい。
   
   
1. ジャーナル採取の設定
   ジャーナルの採取は統合運用管理ツールで指定できます。 なお、ここで指定するファイルサイズは以下を目安として下さい。

   SIZE(MB) = 0.084nt + 0.028mt + 0.009gt
   

   • n：サーバアプリケーションのプロセス数
   • m：サーバアプリケーションのオペレーション数
   • g：起動しているプロセスグループ数
   • t：採取時間(単位:時間)
   
   
2. ジャーナル採取
   WebOTXを再起動するとジャーナルの採取を始めます。 ジャーナル情報を格納したファイル（ジャーナルファイル）はカタログディレクトリ下のjnlディレクトリにjnl000x.logという名前で作られます(xは1〜3)。 ファイルはサイクリックに使用されます。 次のファイルに移る契機は指定された容量に達した時、もしくは、WebOTXを再起動した時です。
   
   
3. ジャーナルの状態表示
   現在のジャーナルの採取状況はjnldispコマンドで確認できます。 コマンドの書式は以下の通りです。

   jnldisp [-C journaldir]
   

   • -C：jnlディレクトリを指定します。 省略時はカレントディレクトリとなります
   
   出力例を以下に示します。

   ********** Control File Infomation **********
     Status      : Active
     Groupnum    : 1
     Filenum     : 3
     Filesize    : 10
   ****** Group 0 Journal File Infomation *****
   
    ***** Current Journal File *****
     number       : 2
     PathName     : C:\Program Files\NEC\WebOTX\domains\domain1\config\tpsystem\jnl\jnl0002.log
     record count : 1
     Save Flag    : 0 : (Not Save)
     FirstDate    : 2005.04.12    FirstTime    : 10:10:36
     LastDate     : 2005.04.12    LastTime     : 10:10:36
   
     number       : 1
     PathName     : C:\Program Files\NEC\WebOTX\domains\domain1\config\tpsystem\jnl\jnl0001.log
     record count : 67
     Save Flag    : 0 : (Not Save)
     FirstDate    : 2005.04.11    FirstTime    : 15:37:16
     LastDate     : 2005.04.11    LastTime     : 21:02:16
   
     number       : 3
     PathName     : C:\Program Files\NEC\WebOTX\domains\domain1\config\tpsystem\jnl\jnl0003.log
     record count : 99
     Save Flag    : 1 : (Saved)
     FirstDate    : 2005.04.11    FirstTime    : 15:22:16
     LastDate     : 2005.04.11    LastTime     : 15:34:51
   
   

   Filenum：ファイル数
   FileSize：ファイルサイズ（単位Ｍbyte）
   

   *** Current Journal File ***
   

   ジャーナルファイルが新しい順に表示されます。 最初に表示されるジャーナルファイルをカレントジャーナルファイルと言います（例ではjnl0002.logのファイル）。
   
   
4. ジャーナルファイルの退避
   ジャーナルファイルはそのままではサイクリックに使用されてしまうため、定期的に退避する必要があります。 退避は単にコピーコマンドを使用するかもしくはjnlsaveコマンドを使用します。 コマンドはWindowsでは${AS_INSTALL}\Trnsv\bin、UNIXでは${AS_INSTALL}/Trnsv/commandにあります。 jnlsaveコマンドを使うと複数のジャーナルファイルを１つにまとめることができます。 また、使用中のカレントジャーナルファイル（ジャーナルが動作中の時のカレントジャーナルファイル）は、jnlsaveコマンドで一旦退避しないと編集できません。
   ジャーナル退避のコマンドの書式は以下の通りです。

   jnlsave -n SystemName [-C journaldir] [-d savefilename] [file_num]
   

   • -n：WebOTXが起動中の場合はシステム名（例：MySystem）を指定します。
   • -C：jnlディレクトリを指定します。 省略時はカレントディレクトリとなります。
   • -d：退避するファイル名を指定します。 省略時はjnlsv.logとなります。
   • file_num：退避するジャーナルファイルの番号を指定します（1〜3）。 省略時は1〜3の全てのジャーナルファイルが対象になります。 複数のファイルを指定する場合、番号は1つ以上のスペースで区切り、時刻の古いファイル順に指定する必要があります。 時刻はjnldispコマンドで確認してください。
   
   
5. ジャーナルファイルの編集
   各種レポートを編集するために、ジャーナル編集コマンド(wojnledt)を実行します。 コマンドはWindowsでは${AS_INSTALL}\Trnsv\bin、UNIXでは${AS_INSTALL}/Trnsv/commandにあります。 ジャーナル編集コマンドの書式は以下の通りです。

   wojnledt [-I InputFile] [-a ApplicationGroup] [-p ProcessGroup] [-t OutputType] [-x SuppressionType] [-l TimeLength] [-r ResponseTime] [-L LinesPerPage] [-O Output] [-D TargetTime]
   

   • -I：入力ファイルのパス名を255文字以内で指定します。 省略時はカレントディレクトリのjnlsv.logとなります。 ジャーナルファイルとその退避ファイルを入力ファイルとして指定できますが、使用中のカレントジャーナルファイルは指定できません。
   • -a：編集対象とするアプリケーショングループ名を指定します。 最大は32文字までで","（カンマ）をデリミタとして複数指定が可能です。 省略時は全アプリケーショングループが編集対象となります。
   • -p：編集対象とするプロセスグループ名を指定します。 最大は32文字までで","（カンマ）をデリミタとして複数指定が可能です。 省略時は全プロセスグループが編集対象となります。
   • -t：編集出力するレポートの種別を数値（01〜15）で指定します。 ","（カンマ）をデリミタとした複数指定や、"_"（アンダーバー）でつないだ範囲指定が可能です。 -xとの同時指定はできません。 省略時は全レポートを出力します。
     

      指定例：
     01,02,03
     05_10
     _05 (01から05まで）
     11_（11から15まで）
     

   • -x：編集出力を抑止するレポートの種別を数値（01〜15）で指定します。 指定方法は-tと同じです。 また-tとの同時指定はできません。
   • -l：時系列レポートの時間間隔（単位：分、1から999まで）を指定します。 省略時は30分間隔となります。
   • -r：トランザクション件数レスポンス時間グラフにおける、レスポンス時間間隔（単位：秒）、編集開始レスポンス時間（単位：秒）、レスポンス時間間隔数をそれぞれss.ss1,ss.ss2,limit_cntとして指定します。 指定可能な範囲はss.ss1が0.01〜100.00まで、ss.ss2が0.00から100.00まで、limit_cntは1〜99983です。 省略時はss.ss1は0.01秒、ss.ss2は0.00秒、limit_cntは1ページに収まる行数となります。
   • -L：レポートの1ページあたりの行数を指定します。 指定可能な範囲は30〜100000です。 省略された場合は60行となります。
   • -O：レポートの出力先ファイル名を指定します。 省略時は標準出力に出力します。
   • -D：編集対象日時をdate1/time1_date2/time2で指定します。 date1（開始日）、date2（終了日）はyyyy.mm.ddの形式で指定します。 time1（開始時）、time2（終了時）はhh:mmの形式で指定します。 省略時は全レコードを編集します。

ジャーナルのファイル数またはファイルサイズの変更手順は次の通りです。

1. TPシステムを停止します。
2. ファイル数を変更する場合、${INSTANCE_ROOT}/config/tpsystem/jnlwrt.ped ファイルを開き、-F オプションの引数を書き換えます。既定値は3で、2 から 100 の範囲で指定可能です。
3. ファイルサイズを変更する場合、統合運用管理ツールでTPシステムをクリックし、右ページの[ジャーナルの設定]タブの[ファイルサイズ]で設定します。
4. ${INSTANCE_ROOT}/config/tpsystem/jnl/journal.ctl ファイルを削除します。削除すると、それまで採取していたジャーナル情報は削除されます。設定変更前のジャーナルが必要な場合、事前にジャーナルを採取してください。
5. TPシステムを起動します。

7.1.10. 統計情報(オペレーションジャーナル)

オペレーションジャーナルは、システムの稼働状況・統計をオペレーション単位でレポート出力します。 オペレーションごとの実行時間情報（平均値・最大値・最小値）、オペレーションの実行回数、プロセスグループごとの稼動スレッド数(起動中のスレッドのうち実際にオペレーションを実行しているスレッド数)を知ることができます。 それぞれの情報について、全体の統計と単位時間ごとの推移がレポート出力されます。

V6.3からはこれに加えて、オペレーションのCPU使用時間（ユーザモード、カーネルモード）の平均・最大・最小、プロセスグループのCPU使用率・CPU使用時間(ユーザモード、カーネルモード)をレポート出力します。

またオペレーション情報のサマリに「実行時間上限推奨値」が追加されました。 実行時間上限を設定する際の参考にしてください。

ジャーナルに蓄積された各オペレーションの実行時間データは、CVS形式のファイルで出力されます。 データはデータ種別（平均時間、最大時間、最小時間、呼び出し回数、最大同時稼動スレッド数、平均同時稼動スレッド数）ごとに編集可能です。 編集時刻、情報採取時間帯や、全体の情報がファイルの先頭に表示されます。 一度も実行されていないオペレーションについては表示されません。

コマンドはWindowsでは${AS_INSTALL}\Trnsv\bin、UNIXでは${AS_INSTALL}/Trnsv/commandにあります。 UNIX版のWebOTXで、且つWebOTX運用ユーザを設定している場合は、WebOTX運用ユーザでコマンドを実行して下さい。

7.1.10.1. オペレーションジャーナル編集コマンド

オペレーションジャーナル編集コマンドの使用方法は以下のとおりです。

> woopjnledt  [-I InputFile] [-O Output] [-type EditType] [-intvl TimeLength] [-time TargetTime] [-line LinesPerPage] [-ag ApplicationGroup][-pg ProcessGroup] [-cmp Component] [-rep RepositoryID] [-op Operation] [-txid TXID] [-txn TxIDNumber]  [-c CatalogDir]

使用例：

1. まずジャーナルを待避します。

   jnlsave -n MySystem -C ${INSTANCE_ROOT}\config\tpsystem\jnl -d jnlsv.log
   

2. 待避したジャーナルをオペレーションジャーナル編集コマンドにより編集します。

   woopjnledt -I jnlsv.log -c ${INSTANCE_ROOT}\config\tpsystem -O domain1jnl.csv
   

以下のオプションは必ず指定するようにしてください。

-c

カタログディレクトリ(${INSTANCE_ROOT}/config/tpsystem)を絶対パスで指定します。 省略時はプロセスグループ名、オペレーション名、起動時設定スレッド数、スレッド使用率などの一部情報が出力されなくなります。 スレッド数などの設定の変更を行っていない場合はカタログディレクトリを指定することを推奨します。

以下のオプションで編集間隔を指定することができます。

-intvl

時系列レポートの時間間隔（単位：分、1から999まで）を指定します。 省略時は30分となります。 「TPシステム」-「情報採取間隔」で設定された情報採取間隔より短い値を設定すると、編集結果が不正確になるのでご注意ください。

ファイル入出力に関するオプションには以下があります。

-I

入力ファイルのパス名を255文字以内で指定します。 省略時はカレントディレクトリのjnlsv.log(jnlsaveコマンドで生成)となります。 ジャーナルファイルとその退避ファイルを入力ファイルとして指定できますが、使用中のカレントジャーナルファイルは指定できません。

-O

レポートの出力先ファイル名を指定します。 省略時は標準出力に出力します。

以下のオプションはデータ量が多いときに使用してください。

情報のフィルタリングを行うオプションには以下があります。

-type

編集出力するレポートの種別を数値（01〜15）で指定します。 ","（カンマ）をデリミタとした複数指定できます。 省略時は全レポートを出力します。 レポートナンバー01がオペレーション情報サマリ、02がプロセス情報サマリ、03が平均値、04が最大値、05が最小値、06がオペレーション実行回数、07が平均同時稼動スレッド数、08が最大同時稼動スレッド数、20がCPU使用率、21がプロセスCPU使用時間(ユーザモード) 、22がプロセスCPU使用時間(カーネルモード)、30がオペレーションCPU使用時間平均(ユーザモード)、31がオペレーションCPU使用時間最大(ユーザモード)、32がオペレーションCPU使用時間最小(ユーザモード)、33がオペレーションCPU使用時間平均(カーネルモード)、34がオペレーションCPU使用時間最大(カーネルモード)、35がオペレーションCPU使用時間最小(カーネルモード)のそれぞれ集計です。
指定例：
01,02,03

-time

編集対象日時をdate1/time1_date2/time2で指定します。 date1（開始日）、date2（終了日）はyyyy.mm.ddの形式で指定します。 time1（開始時）、time2（終了時）はhh:mmの形式で指定します。 省略時は全レコードを編集します。

-ag

編集するアプリケーショングループを指定します。 指定されたアプリケーショングループに含まれるオペレーション、またはプロセスのみを編集します。 アプリケーショングループは複数指定できます。 その場合はカンマで区切ってください。 省略時は全てのオペレーション、またはプロセスについて編集します。 -pg,-txid,-rep,-cmp,-opオプションと共に使用された場合は、全ての条件に適合するオペレーションについて編集します。 本オプションを使用するには、-cオプションによりカタログディレクトリを指定する必要があります。

-pg

編集するプロセスグループを指定します。 指定されたプロセスグループに含まれるオペレーション、またはプロセスのみを編集します。 プロセスグループは複数指定できます。 その場合はカンマで区切ってください。 省略時は全てのオペレーション、またはプロセスについて編集します。 -ag,-txid,-rep,-cmp,-opオプションと共に使用された場合は、全ての条件に適合するオペレーションについて編集します。 -cによりカタログディレクトリが指定されていない場合、プロセスについては指定プロセスのみの編集となりますが、オペレーションについては全てのオペレーション情報を編集します。

-txid

編集するオペレーションをTxIDで指定します。 TxIDは複数指定することができます。 その場合はカンマで区切ってください。 省略時は全てのオペレーションを編集します。 -ag,-pg,-cmp,-rep,-opオプションと共に使用された場合は、全ての条件に適合するオペレーションについて編集します。

-rep

編集するオペレーションをリポジトリIDで指定します。 指定されたリポジトリIDを持つ全てのオペレーションを編集します。 リポジトリIDは複数指定することができます。 その場合は、カンマで区切ってください。 省略時は全てのオペレーションを編集します。 このオプションを利用するためには、-cオプションによりカタログディレクトリが指定されている必要があります。 -ag,-pg,-cmp,-op,-txidオプションと共に使用された場合は、全ての条件に適合するオペレーションについて編集します。

-cmp

編集するオペレーションをコンポーネント名で指定します。 指定されたコンポーネント名を持つ全てのオペレーションを編集します。 コンポーネント名は複数指定することができます。 その場合は、カンマで区切ってください。 省略時は全てのオペレーションを編集します。 このオプションを利用するためには、-cオプションによりカタログディレクトリが指定されている必要があります。 -ag,-pg,-rep,-op,-txidオプションと共に使用された場合は、全ての条件に適合するオペレーションについて編集します。

-op

編集するオペレーションをオペレーション名で指定します。 指定されたオペレーション名を持つ全てのオペレーションを編集します。 オペレーション名は複数指定することができます。 その場合は、カンマで区切ってください。 省略時は全てのオペレーションを編集します。 このオプションを利用するためには、-cオプションによりカタログディレクトリが指定されている必要があります。 -ag,-pg,-cmp,-rep,-txidオプションと共に使用された場合は、全ての条件に適合するオペレーションについて編集します。

テーブルの整形をするオプションです。

-line

レポートの1ページあたりの行数を指定します。 指定可能な範囲は30〜100000です。 省略された場合は、txt形式で60行、CSV形式で100000行となります。

-txn

1つの表に表示するオペレーションの数を指定します。 指定可能な範囲は1〜10000です。 指定された数を越えるオペレーションが存在する場合は、別の表に表示します。 省略された場合は、全てのオペレーションが1つの表に表示されます。

-txt

テキスト形式で編集します。 プロセスグループ名は先頭の14文字までしか表示されません。 省略した場合はCSV形式で出力します。

7.1.10.2. オペレーションジャーナルの読み方

オペレーションジャーナル編集コマンドでは、以下の17種類のテーブルを出力します。

• オペレーション情報統計サマリ
• プロセスグループ情報統計サマリ
• オペレーション平均実行時間推移
• オペレーション最大実行時間推移
• オペレーション最小実行時間推移
• オペレーション実行回数推移
• 最大稼動スレッド数推移
• 平均稼動スレッド数推移
• CPU使用率平均推移（プロセスグループ）
• ユーザモードCPU使用時間推移（プロセスグループ）
• カーネルモードCPU使用時間推移（プロセスグループ）
• ユーザモードCPU使用時間平均推移（オペレーション）
• ユーザモードCPU使用時間最大推移（オペレーション）
• ユーザモードCPU使用時間最小推移（オペレーション）
• カーネルモードCPU使用時間平均推移（オペレーション）
• カーネルモードCPU使用時間最大推移（オペレーション）
• カーネルモードCPU使用時間最小推移（オペレーション）

テーブルの読み方は以下のようになります。 ここではオペレーション情報統計サマリとプロセスグループ情報統計サマリを例にしています。 以下に示すテーブルはCSV形式で編集されたものです。

オペレーション実行時間統計サマリのレポートは以下のように出力されます。

図7.1.10.2-1

各値はそれぞれ秒単位です。

実行時間とCPU使用時間に差がある場合は、データベース処理やネットワーク関連など何らかの「待ち」が生じていると推測されます。 オペレーションジャーナルからCPUを多く使用しているオペレーションを特定することもできます。

プロセスグループ情報統計サマリのレポートは以下のように出力されます。

図7.1.10.2-2

どのプロセスグループでCPUを消費しているかがオペレーションジャーナルよりわかります。 障害解析や、システムの稼働状況把握に役立ててください。

ここでいうスレッド稼働率は、[稼動スレッド数/(稼動可能なプロセス数×稼動可能なスレッド数)]となります。 これは多重度設定が適切かどうかの指標になります。

7.1.10.3. オペレーションジャーナル採取間隔時間の設定

オペレーションジャーナルの情報採取間隔は１分から１４４０分(24時間)の間で指定可能です。 デフォルトは５分となっています。 この情報採取間隔がオペレーションジャーナルの最小編集単位となります。 情報採取間隔を変更したい場合は以下の設定を変更してください。

「TPシステム」-「運用アシスタント」タブ-「情報採取間隔」

この設定は運用アシスタント機能でも使用されます。

7.1.10.4. 補足事項

• オペレーションジャーナルにおける実行時間とは、サーバAPにおいてユーザの実装を呼び出してからその結果が返るまでの時間を測定したものです。 通信リスナとの間のキューに滞留している時間は含まないことに注意して下さい。 なお、統合運用管理ツールにおいてオペレーションの情報として表示される最小/最大/平均レスポンス時間は、通信リスナとの間のキューに滞留している時間を含んでいます。
• ジャーナルに蓄積されるデータのサイズは「TPシステム」の「ジャーナルの設定」-「ファイルサイズ」で設定することができます。
• コマンドによる編集以前に設定が変更されると、以下の項目が正しく表示されない場合があります。
  オペレーション名
  指定されたプロセスグループに属するオペレーション情報
  各プロセスグループに設定された起動スレッド数、プロセス数、スレッド稼働率 (動的多重度変更が成された場合は設定の変更がなくても正確に表示されません)
• 実行時間上限推奨値は運用アシスタント機能での算出機能と同様の算出方法を用いていますが、オペレーションジャーナル編集コマンドの場合はジャーナルとして待避された情報のみが、解析の対象となります。 そのため統合運用管理ツールで表示される値と異なる場合があります。 オペレーションジャーナルで推奨値算出に用いている推奨基準は「ノーマル」です。
• 情報採取間隔時間経過前のデータはTPシステム停止時に破棄されます。 情報採取間隔を大きく設定している場合はご注意ください。
• 複数スレッド構成で何らかの問題によりいくつかのスレッドが閉塞した場合、その閉塞したスレッドは稼動状態としてオペレーションジャーナルにカウントされます。 つまり、オペレーション呼び出しをしていなくても、1スレッドが閉塞状態であれば稼動スレッド数は1として表示されます。 オペレーション呼び出しをしていないにもかかわらず、スレッド使用率が高い場合はスレッドが閉塞していると考えられるので、必要に応じてアプリケーションログなどからスレッド閉塞の原因を特定してください。
• 平均同時稼動スレッド数の計算式は以下の通りです。
  平均同時稼動スレッド数= 情報採取時の稼動スレッド数の総和 / 情報採取回数
  情報採取回数=(採取終了時間 - 採取開始時間)　/　情報採取間隔
• (V6.31以降)V6.3以降のWebOTXでは、オペレーションのCPU情報取得機能が新規に追加されたことにより、Solaris版とHP-UX版でV6.2と比べてオペレーションの実行性能が遅くなっています。 V6.2と比較して、HP-UX版で約4%、Solaris版で約16%遅くなっています。 Windows版とLinux版ではV6.2との性能差はありません。 V6.31以降では、このオペレーションのCPU情報取得機能を抑制し、オペレーション呼び出しの実行性能をV6.2と同等にすることができます。
  CPU情報取得を抑制するには、プロセスグループの設定の「環境変数」に以下の値を設定し、アプリケーショングループを再起動します。 この環境変数を指定すると、オペレーションジャーナルに記録されるオペレーションのCPU使用時間が全て0になります。 オペレーションのCPU情報採取機能を利用しない場合は、本環境変数を設定してください。
  名前：WO_NO_SAMPLING_CPUINFO
  値：ON

7.1.11. 通信情報(イベントジャーナル)

オペレーションの実行の過程で起きる障害については、イベントジャーナルを追っていくことで、どこで障害が発生しているか調べることができます。 また、イベントジャーナルではクライアントからの受信開始から応答の送信終了までを確認できるため、障害箇所がサーバ側なのかそうではないのか（ネットワークやクライアント側なのか）を切り分けることができます。

イベントジャーナルの編集は統合運用管理ツールから実行できます。 編集の対象となる期間は前回TPシステム起動時から編集実行時までを1世代分として、3世代分まで遡って編集することが出来ます。 TPシステムを終了した状態で編集を実行しても前回の運用中の情報が採取できます。 ログは次の箇所に出力されます。

[世代数を指定しない、現在稼動しているシステムを選択した場合]
${INSTANCE_ROOT}\logs\tpsystem\logcollect\{日付10桁}\{システム名}_woejout{数字}.log

[世代数を指定した場合]
${INSTANCE_ROOT}\logs\tpsystem\logcollect\{日付10桁}\{システム名}_woejout_{世代数}_{数字}.log

以下に主な採取ポイントを示します。 空欄は採取項目がないか、もしくは開発向けの内部情報です。 また、採取ポイントは他にもありますが、それらも開発向けの内部情報です。

• ※1：OBJMNGはオブジェクトマネージャのこと
• ※2：統合運用管理ツールを使ってオペレーション終了時に自動的にCommit/Rollbackする設定にした場合のみ
• ※3：TPSSetTxStatus()で設定した値

TX処理における上記コンポーネント(通信リスナ、サーバAP)の位置づけを以下に示します。 図中の数字は上表での種別の数字に対応しています。

図7.1.11-1

次に編集形式を以下に示します。

Event Journal Ver6.2                          05/04/12
(イベントジャーナルのバージョン)              (編集日)

System name : MySystem
Last Output Time = 05/04/12:11:16:42 (情報の最終出力時刻)

DATE      TIME             PID    THREAD  RECNO  BLOCKNO  COMP   TYPE  ITEM1                ITEM2  ...
05/04/12  10:05:26.622000  02728  65535   13832  000      TPLIB  01    Lower(IDL:Loop:1.0)  sample
05/04/12  10:05:26.782000  02728  65535   13837  000      TPLIB  02    2                    1
(日付)    (時刻)           (プロセスID)   (レコード通番)  (コンポーネント名)                (項2)
                                  (スレッドID)   (ブロック#)     (種別)(項1)

コマンドによるイベントジャーナルの編集

イベントジャーナルの編集はコマンドでも実行可能です。 但しWebOTXが動作しているマシン上で直接コマンドを実行する必要があります。 コマンドはWindowsでは${AS_INSTALL}\Trnsv\bin、UNIXでは${AS_INSTALL}/Trnsv/commandにあります。 UNIXでWebOTXの運用ユーザを設定している場合は必ず運用ユーザでコマンドを実行する必要があります。 また、運用管理コマンドからの実行も可能です。

コマンドは下記の通りです。

[コマンドからの実行]

> woejedit catalogpath maxline outpath systemname

[運用管理コマンドからの実行]

otxadmin> invoke tpsystem.editEventJournal maxline

• catalogpath：カタログディレクトリをフルパスで指定します。
• maxline：編集後の1ファイルの行数(目安)を指定します。 ここで指定した行数を越えないように分割してファイルを作成します。
• outpath：編集後の出力ファイル名をフルパスで指定します。
• systemname：システム名を指定します。

実行例

[コマンドからの実行]

> woejedit /opt/WebOTX/domains/domain1/config/tpsystem 30000 /opt/WebOTX/domains/domain1/logs/tpsystem/ejout.log MySystem

[運用管理コマンドからの実行]

otxadmin> invoke tpsystem.editEventJournal 30000

この場合、実際の出力ファイルはejout1.log, ejout2.log, ejout3.log … となります。

コマンドによる前世代のイベントジャーナルの編集

イベントジャーナルの編集は基本的に1世代分(前回TPシステム起動時からコマンド実行時まで)の情報を編集します。 統合運用管理ツールによる編集と同じく、コマンドによる編集でも3世代前までの情報を編集することが可能です。 また、運用管理コマンドからの実行も可能です。

コマンドは下記の通りです。

[コマンドからの実行]

> woejedit catalogpath maxline outpath systemname savedfile

[運用管理コマンドからの実行]

otxadmin> invoke tpsystem.editEventJournal maxline generation

• savedfile：1世代前は#0msj、2世代前は#1msj、3世代前は#2msjを指定します。
• generation：1世代前は1、2世代前は2、3世代前は3を指定します。

実行例

[コマンドからの実行]

> woejedit /opt/WebOTX/domains/domain1/config/tpsystem 30000 /opt/WebOTX/domains/domain1/logs/tpsystem/ejout.log MySystem #0msj

[運用管理コマンドからの実行]

otxadmin> invoke tpsystem.editEventJournal 30000 1

この場合、1世代前のイベントジャーナルを編集します。

なお、3世代分のイベントジャーナルの編集前ファイルは

${INSTANCE_ROOT}/config/tpsystem/tmp/saveディレクトリ

ファイルサイズ

イベントジャーナル採取データはTPモニタにより定期的に${INSTANCE_ROOT}/config/tpsystem/tmpディレクトリ下のファイルmsjに出力されます。

msjファイルのファイルサイズは設定変更可能(既定値10MB)であり、そのサイズまでアペンド出力します。 ファイルサイズ上限に達した場合はサイクリックに出力されます。 設定は統合運用管理ツールの[TPシステム]をクリックし、右ページの[イベントジャーナル]-[ファイルサイズ]で行ってください。

7.1.12. キュー滞留情報

クライアントからのリクエストは通信リスナが受付を行い、アプリケーション側のキューに一旦格納されます。 キューはプロセスグループ単位のキューとプロセス単位のキューが作成されますが、ステートレスの場合はプロセスグループ単位のキューが、ステートフルの場合はプロセス単位のキューが使用されます。 アプリケーション側では処理スレッドに空きがあればすぐにリクエストをキューから取りだして処理しますが、スレッドが塞がっている場合にはしばらくキューに滞留した状態が続くことになります。 以下では、このキュー滞留数を確認する方法を説明します。

otxadminコマンドによるキュー滞留数の確認

otxadminコマンドを用いてキューの状態を確認できます。

• システムレベルでの最大キュー滞留数の参照
  キューはプロセスグループ単位で作成されていますが、その中で現在最も多いキュー滞留数を確認することができます。 これを参照することにより、システム全体の滞留状況が確認できます。

  otxadmin> get --monitor tpsystem.Queue.MaxStayMsgNum-Current
  

• プロセスグループレベルでの最大キュー滞留数の参照
  該当プロセスグループのキュー滞留数を確認します。 これを参照することにより、問題のプロセスグループが特定できます。

  otxadmin> get --monitor tpsystem.applicationGroups.apg_name.processGroups.pg_name.queueingCount-Current
  

• オペレーションレベルでの最大キュー滞留数の参照
  実際にキュー滞留している要求がどのオペレーションであるかを確認することが出来ます。
  CORBAオペレーションの場合

  otxadmin> get --monitor applications.ap_name.module_name.interface_name.operation_name.queue-Current
  

  Java EEオペレーションの場合

  otxadmin> get --monitor applications.ap_name.module_name.ejb_nameinterface_name.operation_name.queue-Current
  

quewrtコマンドによるキュー滞留数の確認

このコマンドで確認できるのはプロセスグループ単位での滞留リクエスト数(ステートレスの場合)、プロセス単位での滞留リクエスト数(ステートフルの場合)です。

コマンドはWindowsでは${AS_INSTALL}\Trnsv\bin、UNIXでは${AS_INSTALL}/Trnsv/commandにあります。 UNIX版のWebOTX使用の場合は、WebOTX運用ユーザでコマンドを実行して下さい。

> quewrt -n システム名 -M 収集間隔 -C 収集回数 [-f ファイル名]

• システム名：TPシステム名
• 収集間隔：情報の収集間隔を秒単位で指定（1〜2^31-1。10以上を推奨）
• 収集回数：情報の収集回数を指定（1〜2^31-1）
• ファイル名：データ収集結果を格納するファイル名を64バイト以内で指定

結果表示例：

MODE QUE-NAME                          MSG-NUM  POOL-NAME  CONECT DEQUE
  Q  STPCTLQUE28752                          0       ea60     ON    ON
  Q  QUE_TIMER                               0   746d6d70     ON    ON
  Q  TPproc029983                            0       ea60     ON    ON
  Q  java                                    0       ea60     ON    ON
  Q  _OTSLink                                0       ea60     ON    ON
  Q  JOURNALQUE0                             0      13880     ON    ON
  Q  SENDTPPQUE                              0       ea60     ON    ON
  Q  STPRCVQUE                               0       ea60     ON    ON
  Q  TPproc028754                            0       ea60     ON    ON
  Q  IIOPLISTENER                            0       ea60     ON    ON
  Q  TPproc028758                            0       ea60     ON    ON

• QUE-NAME
  キュー名称です(WebOTX内部で使用するキューも含まれます)。 プロセスのキューはTPproc(プロセスID) となっています。 プロセスIDとプロセスグループの対応は、カタログディレクトリに作成されるhistory.actファイルを参照して下さい。
• MSG-NUM
  キューに滞留しているリクエストの数が表示されます。

contpsコマンドによるキュー滞留数の確認

このコマンドで確認できるのはオペレーション単位での滞留リクエスト数です。

このコマンドはWebOTX運用ユーザで実行してください。 コマンドはWindowsでは${AS_INSTALL}\Trnsv\bin、UNIXでは${AS_INSTALL}/Trnsv/commandにあります。

> contps -n システム名 DI N TR

結果表示例：

********** TPBASE TR STATUS ****************************************************
TxID    :処理状態:Tx滞留数  :総Tx数    :最小応答:最大応答:平均応答:応答合計
LOX000  :IDLE    :         0:         0:      -1:      -1:      -1:        -1
UKN000  :IDLE    :         0:         0:      -1:      -1:      -1:        -1
APR000  :IDLE    :         0:         0:      -1:      -1:      -1:        -1
ABAAAB  :START   :         0:   1022991:       3:     503:       4:   4727079
ABAAAA  :IDLE    :         0:         0:      -1:      -1:      -1:        -1
ABaa00  :IDLE    :         0:         0:      -1:      -1:      -1:        -1
ABaa01  :IDLE    :         0:         0:      -1:      -1:      -1:        -1
ABaa20  :IDLE    :         0:         0:      -1:      -1:      -1:        -1
ABaa21  :IDLE    :         0:         0:      -1:      -1:      -1:        -1
********** END OF TR STATUS ****************************************************

• Tx滞留数
  TxIDに対応するオペレーションで処理待ちとなっているリクエストの数です。 ここに表示される6桁のTxIDとCORBAオペレーションの対応付けには、イベントジャーナルを実行した時にカタログディレクトリ/tmpにできるotx.t2oファイルを参照して下さい。

7.1.13. 運用アシスタント

V6.3 から、オペレータの運用を支援する自律運用機能「運用アシスタント」を実現しました。 運用アシスタントに関する各種設定について以下に説明します。

7.1.13.1. 運用アシスタント機能全体に関する設定

運用アシスタント機能全体に関する設定について説明します。

なお、本節では統合運用管理ツールからの操作をメインに説明します。

設定箇所について

統合運用管理ツールから設定する場合の設定箇所は、「TPシステム」ノードの「運用アシスタント」タブをクリックしてください。 通常はここで一括して設定します。

アプリケーショングループ、プロセスグループ、モジュール、オペレーション単位で細かく設定することも可能です。 個別に設定したい場合は、統合運用管理ツールの左上のメニュー「システム」−「システム設定」をクリックし、画面表示の「属性の表示レベル」と「操作の表示レベル」を「詳細レベルの情報を表示」に変更してください。 すると各ノードに「運用アシスタント」タブが表示されます。

以下の項目をまず確認してください。

• 学習期間
  学習期間とは、システムの稼働状況を採取し始めてから、実際に自動設定などのアクションをとるまでの期間を示します。 学習期間内は、情報を採取・蓄積するのみで、以下の操作を行いません。
  • 多重度の適正チェック
  • 実行時間上限の一括設定・自動設定（推奨値の提示は行います）
  • スローダウン障害検出
  例えば学習期間を1日(1440分)に設定すると、少なくとも1日分以上の情報をもとに上記のアクションがなされます。 週末になると負荷が高くなるといったシステムであれば、学習期間には1週間以上を設定してください。 現在までの学習時間は、プロセスグループまたはオペレーションのノードに表示されます。 学習期間を終えても情報の採取･蓄積は続けられます。 システムの稼動情報採取はプロセスグループ作成時、アプリケーション配備時に開始されます。 プロセスグループ未起動の状態であっても学習時間の経過時間に含みます。

以下の項目は必要であれば見直してください。

• 情報採取間隔
  システムの稼動情報を採取する間隔を設定します。 この間隔ごとに運用アシスタント機能による解析が行われます。 また、ここで設定された時間は、オペレーションジャーナルの最小編集間隔でもあります。

以下の操作により、内部的に蓄積された情報を一旦クリアすることができます。

• 運用アシスタント統計情報のクリア
  通常、運用アシスタント機能では学習開始から現在までの全てのデータをもとに稼働状況を解析します。 しかし、明示的な環境の変化があった場合など、それ以前の情報を勘案することがふさわしくない場合もあります。 この操作を行うと今までの情報は一旦破棄され、新しく採取された情報より多重度最適化支援・実行時間上限適正値算出・スローダウン検出を行います。 システムの稼動状況を決定的に変えるような変更があった場合に、この操作を実行してください。 この操作を行うことにより、運用アシスタントの解析動作が素早く新しい環境に適合されます。
  この操作は通常「TPシステム」のノードを右クリックして実行します。細かい単位でクリアしたい場合は、統合運用管理ツールの左上のメニュー「システム」−「システム設定」をクリックし、画面表示の「操作の表示レベル」を「詳細レベルの情報を表示」に変更してください。

以下の操作により、運用アシスタント機能の利用有無が設定できます。

• 運用アシスタント機能を使用する
  運用アシスタント機能を利用しない場合は「TPシステム」ノードの「運用アシスタント」タブをクリックして運用アシスタントの 「運用アシスタント機能を使用する」 のチェックを外してください。
  運用アシスタント機能を利用しない場合は、統計情報やシステムの状態を監視しませんので、 障害発生時の解析が困難になる場合があります。

7.1.13.2. 多重度の最適化支援

多重度最適化支援機能の設定について以下に説明します。

多重度最適化支援機能ではシステムの稼働状況を解析し、多重度の増減を推奨、または自動変更します。 多重度の増減が推奨される場合は、以下のメッセージが統合運用管理ツールに通知され、イベントログ/syslog, webotx_agent.log(webotx_tpmmgr.log)に出力されます。 同時にスタックトレースを3秒間隔5回でアプリケーションログに出力します。

"OTX20220100 プロセスグループxxxの多重度が不足しています。プロセス数/スレッド数の増加を検討してください。"
"OTX20220001 プロセスグループxxxは多重度を減らしても同じ処理能力を維持できます。プロセス数/スレッド数の削減を検討してください。もしくは予備プロセス数を変更してください。"
"OTX20220100 The multiplicity of process group xxx is insufficient. Please examine an increase in the the number of process or threads."
"OTX20220001 Even if the multiplicity is decreased, process group xxx can maintain the same processing performance. Please examine an decrease in the the number of process or threads, or modify backup process count."

[注] イベントIDがV6.3から変更になりました(OTX20220000 → OTX20220100)

多重度の自動変更機能を利用している場合は、以下のメッセージとなります。

"OTX20220010 プロセスグループxxxの多重度が不足しています。プロセス数をaに変更しました。"
"OTX20220011 プロセスグループxxxは多重度を減らしても同じ処理能力を維持できます。プロセス数をaに変更しました。"
"OTX20220010 The multiplicity of process group xxx is insufficient. So the count of process is changed to a."
"OTX20220011 Even if the multiplicity is decreased, process group xxx can maintain the same processing performance. So the count of process is changed to a."

多重度最適化支援機能の設定としては、以下の設定をまず確認してください。

• 多重度最適化支援:目標応答時間
  最低限確保したいキュー待ち時間を含む応答時間を設定してください。 現在キューの最後尾で待機しているリクエストが応答期限を越える可能性があると予測される場合、運用アシスタント機能は多重度が不足していると判断し、オペレータへの通知、またはプロセス多重度増加を行います。 リクエストの応答時間の予測は、オペレーションの優先度が同一である場合が想定されています。
  以下のメッセージが表示された場合は応答期限設定を長めに設定することを検討してください。

  "OTX20220020 プロセスグループxxxの応答期限設定が小さすぎます。応答期限設定を変更するか、オペレーションzzzの処理を見直してください。"
  "OTX20220020 The response time limit of process group xxx is insufficient. So modify the configration or review the processing of operation zzz."
  

  このメッセージはオペレーションzzzのキュー待ち時間を含まない処理時間が応答期限設定を超えているため、多重度を増やしても応答期限を満たせないことを意味します。 運用アシスタントでは、このメッセージを出力した後もそれまでと同様に多重度最適化支援を続けます。

必要に応じて以下の設定も見直してください。 多重度を増加させるべきかの判断基準を示す設定には、上記の応答期限に加えて以下のものがあります。

• 多重度最適化支援:アイドルCPU使用率
  最低限確保しておきたいマシンのアイドルCPU使用率を設定してください。 運用アシスタント機能では、キューの最後尾で待機しているリクエストが応答期限を越える可能性があると予測される場合であっても、プロセス多重度を増加させた結果、マシンのアイドルCPU使用率がこの設定を下回ると予測されるならば、多重度を増加すべきとは判断しません。 マシンのアイドルCPU使用率が0に近い状態で多重度を上げても、処理能力の向上はのぞめません。
  * Linux版では多重度を増加させた場合のCPU使用率を予測しません。 アイドルCPU使用率設定と現在のマシンのアイドルCPU使用率を比較します。
• 最大マルチプロセス数
  プロセスグループあたりのプロセス数の上限を設定することができます。 本設定は「TPシステム」ノードの「運用アシスタント」タブにあります。

  表7.1.13.2-1

  設定名	パラメータ
  	既定値	最大値
  マルチプロセス数	5	1000

  最大マルチプロセス数の制限により多重度を増やせない場合は、以下のメッセージが出力されます。

  "OTX20220012 プロセスグループxxxの多重度が不足していますが、最大マルチプロセス数を超えるためプロセス数をaに変更できません。"
  "OTX20220012 The multiplicity of process group xxx is insufficient. But the count of process cannot be changed to a , because over MaxMultiProcess."
  

多重度を減少させるかの判断基準を示す設定には、以下のものがあります。

• 多重度最適化支援:多重度過剰と見なす間隔
  プロセス数を減らしてもオペレーション実行に影響を与えない期間がこの時間を超えた場合、多重度を減少させるべきと判断されます。 必要なくなったと思われるプロセスをどのくらいの期間残しておくかをここで設定してください。
• 多重度最適化支援:予備プロセス数
  障害回避の観点で余分に確保しておきたいプロセス数を設定してください。 ここで設定された予備プロセス数分はプロセス数が過剰であっても、多重度を減少させるべきとは判断されません。

以下の設定を変更することにより、そのときのシステム稼働状況に応じて動的に多重度を変更することができます。

• 多重度最適化支援
  「自動変更」を選択した場合、情報採取間隔が経過するごとに多重度の適正をチェックし、必要に応じてプロセス数を動的に変更します。 上に挙げた各種の設定が妥当かどうか十分に検証した上で、「自動変更」機能をご利用ください。

7.1.13.3. 実行時間上限の適正値算出

実行時間上限の適正値算出機能に関する設定について以下に説明します。 実行時間上限とは、実行時間上限を超えるオペレーションが検出し異常状態とみなされたプロセスを再起動させる、ストール障害自律復旧のための設定です。

運用アシスタントが算出した実行時間上限の推奨値は、以下に表示されます。

• 実行時間上限推奨値
  オペレーションのノードの「オペレーション制御」タブ内の「実行時間上限推奨値」に、運用アシスタントが算出した実行時間上限の推奨値が表示されます。 すぐ上に表示される「実行時間上限」が現在実際に設定されている値です。 実行時間上限の推奨値は、該当オペレーションの実行回数が30回以上になるまでは算出されません。 この場合、「実行時間上限推奨値」には-1（設定なし）が表示されます。

運用アシスタントが算出した実行時間上限の推奨値を実際に設定するには、以下の操作を実行します。

• 実行時間上限に推奨値を設定
  運用アシスタントが算出した実行時間上限の推奨値を実際に設定します。 この操作は通常「TPシステム」のノードを右クリックして実行します。 この場合、全オペレーションに対して一括設定されます。 細かい単位で設定したい場合は、統合運用管理ツールの左上のメニュー「システム」−「システム設定」をクリックし、画面表示の「操作の表示レベル」を「詳細レベルの情報を表示」に変更してください。 設定負荷低減のため、推奨値が設定値の90%〜100%であるような微小な減少では値は設定されません。 実行時間上限推奨値の一覧はotxadminコマンドで確認することができます。

  get *.rcmdExeMax
  

  このコマンドで、設定される値を確認した上で一括設定を実行するようにしてください。

必要に応じて以下の設定も確認してください。

• 実行時間上限推奨値を更新する
  実行時間上限推奨値の更新有無を設定します。 「更新する」を設定すると情報採取間隔(「TPシステム」-「情報採取間隔」）ごとに推奨値が更新されます。 推奨値の妥当性を検証したい場合など、推奨値の更新を止めることもできます。
• 実行時間上限推奨値を提示する
  実行時間上限推奨値の提示有無を設定します。 推奨値を提示しない場合は実行時間上限自動設定機能・一括設定機能も働きません。
• 実行時間上限値 推奨基準
  実行時間上限値を推奨する基準を設定します。 早期復旧優先を設定した場合は短めの値が、オペレーション継続優先を設定した場合は長めの値が実行時間上限値として推奨されます。 以下のメッセージが統合運用管理ツールに通知、またはイベントログ/syslog,webotx_agent.logに出力された場合は、推奨基準が適切でないことを意味します。 長めの値を設定するように推奨基準を見直してください。 例えば、「ノーマル」状態で以下のメッセージを検出した場合は、推奨基準を「オペレーション継続優先」に変更してください。

  "OTX20310100オペレーションｚｚｚの実行時間が実行時間上限推奨値を超えました。推奨値算定モードを見直してください。 実行時間=aaaa。 ObjectName=yyy"
  "OTX20310100 The execution time of zzz get over the recommended timeout value. Review rcmdExeMaxbase. Excecution Time is xxx. The ObjectName is yyy."
  

  [注] イベントIDがV6.3から変更になりました(OTX20310000 → OTX20310100)
• 実行時間上限推奨値の最小値
  実行時間上限推奨値の最小値を設定します。 この値より小さな値が推奨されても、自動設定・一括設定されません。 実行時間上限推奨値として表示はされます。
• 実行時間上限を自動設定する
  実行時間上限の自動設定を設定します。 「自動設定する」をチェックすると情報採取間隔(「TPシステム」-「情報採取間隔」）ごとに実行時間上限が自動的に更新されます。 設定負荷低減のため、推奨値が設定値の90%〜100%であるような微小な減少では値は設定されません。
  自動設定機能を使用すると、頻繁に設定値が変更されるためプロジェクト側で現在の設定値を把握しづらいというデメリットがあります。 稼働状況の即時反映を最優先する場合をのぞいて、実行時間上限推奨値を確認後に「実行時間上限に推奨値を設定」操作により一括設定する方法を推奨します。
  実行時間上限はこれを超えるオペレーションを検出した場合にプロセスを再起動させるための設定です。 自動設定機能を利用される際は、上に挙げた各種の設定が妥当かどうか十分に検証した上でご利用ください。

7.1.13.4. スローダウン障害の検出

スローダウン障害検出機能のための設定について以下に説明します。

ここでスローダウン障害とは、「従来に比べて総体として遅くなった」状態を指します。 何回かのオペレーション実行がたまたま長いだけではスローダウン障害とは見なしません。 上記に加え、V8.2からは1秒以下でのスローダウンは検出しません。

前回の情報取得までの統計情報と、最新の情報採取分（「情報採取間隔」分）のデータを比較します。 最新の情報取得で得た各オペレーションの実行回数が30回に満たない場合は、スローダウン検出を行わず、次回の情報取得分にマージさせます。 スローダウン障害の疑いがあっても、正常動作の可能性が多く残る場合は、スローダウン障害として検出しません。

スローダウン障害を検出すると以下のメッセージを統合運用管理ツールに通知し、イベントログ/syslog,webotx_agent.log(webotx_tpmmgr.log)に出力します。 このとき、スタックトレースを3秒間隔5回でアプリケーションログに出力し、イベントジャーナルとキュー情報を ${INSTANCE_ROOT}\logs\tpsystem\logcollect\{日付10桁}\配下に出力します。 これらの情報を確認することで障害解析に役立ちます。

"OTX20110100 オペレーションzzzのスローダウンを検出しました。current:平均実行時間=xxx秒。normal:平均実行時間=www秒。プロセスグループ=vvv。 ObjectName=yyy"
"OTX20110100 The Operation zzz get late. Average of current time is xxx s. Average of normal time is www s. The Process Group is vvv. The ObjectName is yyy"

[注] イベントIDがV6.3から変更になりました(OTX20110000 → OTX20110100)

スローダウン障害からの回復を検出すると以下のメッセージを統合運用管理ツールに通知し、イベントログ/syslog,webotx_agent.log(webotx_tpmmgr.log)に出力します。 遅くなったまま長期間状態が落ち着いた場合も以下のメッセージとなります。

"OTX20120100 オペレーションzzzがスローダウン状態からノーマル状態に遷移しました。current:平均実行時間=xxx秒。normal:平均実行時間=www秒。プロセスグループ=vvv, ObjectName=yyy"
"OTX20120100 The Operation zzz transit from slowdown to normal. Average of current time is xxx s. Average of normal time is www s. The Process Group is vvv. The ObjectName is yyy"

[注] イベントIDがV6.3から変更になりました(OTX20120000 → OTX20120100)

スローダウンが検出された場合は、システム運用上重要な問題となっていないか、オペレーションジャーナルや統合運用管理ツールを使用し稼動状態を調査してください。 スローダウン検出機能は、遅くなり始めた状態を検出するものであり、致命的な遅延となる前に自然復旧される場合もあります。 この場合は特に復旧処置は必要ありません。

スローダウン障害が、自然復旧される一時的なものか、オペレータによる対処が必要な恒久的なものかの判断を支援する機能として「長期スローダウン検出機能」があります。 オペレーションのスローダウンを検出してから「スローダウン継続監視時間」を超えてなお、スローダウン状態が継続していると以下のメッセージを統合運用管理ツールに通知し、イベントログ/syslog,webotx_agent.log(webotx_tpmmgr.log)に出力します。

"OTX20110200 オペレーションｚｚｚの長期にわたるスローダウン状態を検出しました。current:平均実行時間=xxx秒。normal:平均実行時間=www秒。スローダウン継続時間=uuu分。プロセスグループ名=vvv, ObjectName=yyy"
"OTX20110200 The Operation zzz is slow for a long time. Average of current time is xxx s. Average of normal time is www s. Duration of slow is uuu m. The Process Group is vvv. The ObjectName is yyy"

「長期にわたるスローダウン状態」を検出すると、メッセージ出力とともに、該当プロセスグループのスタックトレースを採取します。 このAPログに出力されるスタックトレースを参照することで、スローダウンの原因を調査することができます。

「長期にわたるスローダウン状態」が通知される場合、スローダウンが長期化しており、一時的なスローダウンでなく恒久的なスローダウンに陥っている可能性があります。 オペレーションジャーナルやスタックトレース、イベントジャーナルによりスローダウンの原因を調査してください。 必要に応じてプロセスグループの再起動などの復旧に向けた対処を検討してください。 運用管理製品などによりスローダウン障害を監視する場合は、本メッセージを監視することをお奨めします。

スローダウン状態が継続しているか否かは、「情報採取間隔」ごとに監視されます。 「スローダウン継続監視時間」を超えてスローダウン状態が継続していても、次の情報採取までは「長期にわたるスローダウン状態」が検出されません。 前回スローダウン状態か否かを解析してからの該当オペレーションに対する呼び出し回数が30に満たない場合は、スローダウン状態か否かの判断ができないため、「長期にわたるスローダウン」は検出されません（復旧したとも見なされません）。 スローダウン継続時間は、最初にスローダウンを検出した時間を0としてカウントされます。 「長期にわたるスローダウン状態」は同一オペレーションに対して連続して通知されません。

スローダウン障害検出機能のための設定には以下があります。 必要に応じて見直してください。

• スローダウン障害を検出する
  スローダウン障害を検出するかどうか設定します。
• スローダウン障害検出基準
  スローダウン障害を検出する基準を設定します。 スローダウン障害を早期に検出したい場合は「早期検出優先」を設定してください。 正常動作とみなせるオペレーションまでスローダウン障害として検出されてしまう場合は「長め」を設定してください。
• スローダウン継続監視時間
  スローダウンを検出してからの経過時間を分単位で監視します。 この時間を過ぎてもスローダウン状態が解消されない場合は「長期にわたるスローダウン」として警告メッセージを出力します。 スローダウンを検出してからの経過時間は、情報採取間隔ごとにチェックされます。 -1を設定した場合は、スローダウンを検出してからの経過時間を監視しません。
• 長期スローダウン時に自動スタックトレースを採取する
  「長期にわたるスローダウン状態」を検出時に、自動でスタックトレースを採取するかを設定します

スローダウン状態がどのくらい長く継続しているかは、以下で参照できます。

• スローダウン継続時間
  スローダウンを検出してからの経過時間を分単位で表示します。 ノーマル状態の場合は-1が表示されます。 スローダウン継続時間は情報採取間隔ごとに計算されます。

7.1.14. メモリ枯渇監視機能

メモリ枯渇監視機能の設定を以下に示します。

設定方法

メモリ枯渇監視機能の設定の初期値は表3.4.4.3-2のようになっています。機能を使用しない場合は、各閾値を0に設定します。

運用管理ツールからの設定は以下の通りとなります。

• [TPシステム]-[アプリケーショングループ名]-[プロセスグループ名]-[JavaVMオプション]
  • OutOfMemoryErrorの監視を行う
  • メモリ使用量閾値 (Old領域)
  • メモリ使用量閾値 (Permanent領域)
  • メモリ使用量閾値の超過時GCを行う
  • GC後メモリ使用量閾値
  • GC後メモリ使用量閾値の超過時プロセス停止を行う

図7.1.14-1

運用管理コマンドを使用する場合は、以下のMOの属性を変更してください。

• OutOfMemoryErrorの監視を行う
  tpsystem.applicationGroups.<アプリケーショングループ名>.processGroups.<プロセスグループ名>.outOfMemoryMonitoring
• メモリ使用量閾値 (Old領域)
  tpsystem.applicationGroups.<アプリケーショングループ名>.processGroups.<プロセスグループ名>.oldMemoryThreshold
• メモリ使用量閾値 (Permanent領域)
  tpsystem.applicationGroups.<アプリケーショングループ名>.processGroups.<プロセスグループ名>.permMemoryThreshold
• メモリ使用量閾値の超過時GCを行う
  tpsystem.applicationGroups.<アプリケーショングループ名>.processGroups.<プロセスグループ名>.runGCAtMemoryOver
• GC後メモリ使用量閾値
  tpsystem.applicationGroups.<アプリケーショングループ名>.processGroups.<プロセスグループ名>.oldMemoryThresholdAfterGC
• GC後メモリ使用量閾値の超過時プロセス停止を行う
  tpsystem.applicationGroups.<アプリケーショングループ名>.processGroups.<プロセスグループ名>.stopProcessAtMemoryOver

ログ出力

出力されるログは"検出時のメモリ使用量"と"共通情報"、"Fullthreaddump"(GC後のメモリ使用量監視のプロセス停止しない場合のみ)が出力されます。
各監視の"検出時のメモリ使用量"のイメージは以下の通りとなります。
メモリ使用量監視の場合

2009/10/16 16:28:49.080|---: PS Old Gen Memory Threshold Exceeded threshold: used:289794864 max:477233152 init:29884416 committed:351862784

GC後のメモリ使用量監視の場合

2009/10/15 11:00:38.431|---: PS Old Gen Collection Memory Threshold Exceeded threshold: used:475432840 max:477233152 init:29884416 committed:477233152

共通情報は以下のイメージになります。

2009/10/15 11:00:38.431|---: JavaHeap used:496048936 max:517013504 init:33554431 committed:508624896
2009/10/15 11:00:38.431|---: Code Cache used:1098176 max:50331648 init:2359296 committed:2359296
2009/10/15 11:00:38.431|---: PS Eden Space used:20616096 max:58130432 init:3145728 committed:30801920
2009/10/15 11:00:38.431|---: PS Survivor Space used:0 max:589824 init:524288 committed:589824
2009/10/15 11:00:38.431|---: PS Old Gen used:475432840 max:477233152 init:29884416 committed:477233152
2009/10/15 11:00:38.431|---: PS Perm Gen used:9610576 max:67108864 init:16777216 committed:16777216
2009/10/15 11:00:38.431|---: GC Name:PS Scavenge Count:20 Time:247
2009/10/15 11:00:38.431|---: GC Name:PS MarkSweep Count:98 Time:8350

出力されるログは以下の意味となります。

• メモリ情報
  • used : 現在使用中のヒープサイズ
  • max : 最大ヒープサイズ
  • init : 初期ヒープサイズ
  • committed : 確保されたヒープサイズ
• GC情報
  • GC Name : GC名
  • Count : GC回数
  • Time : GC累積時間

7.1.15. 同時受付オペレーション数

TPシステムの同時受付オペレーション数

TPシステムで同時に受け付けるオペレーション数を制限することができます。変更するには、同時受付オペレーション数を変更します。実行中のオペレーションとキューに滞留中のオペレーションの両方を含みます。WebOTX内部で生成され、IIOPリスナを経由して起動されるオペレーションも含まれます。非同期トランザクションは含まれません。

統合運用管理ツールからの設定は以下の通りとなります。

• [TPシステム]-[IIOPリスナ]-[上限設定]-[同時受付オペレーション数]

TPシステムで現在受け付けているオペレーション数は、統合運用管理ツールから参照できます。

• [統計情報]-[ドメイン名]-[TPシステム]-[IIOPリスナ]-[同時受付オペレーション数]

TPシステムで現在受け付けているオペレーション数は、otxadminコマンドからでも参照できます。

otxadmin> get --monitor tpsystem.IIOPListener.simultaneousRequestsCount-Current

プロセスグループの同時受付オペレーション数

IIOPリスナは各プロセスグループにオペレーションを振り分けますが、その際にプロセスグループが同時に受け付けるオペレーション数を指定できます。実行中のオペレーションとキューに滞留中のオペレーションの両方を含みます。WebOTX内部で生成され、IIOPリスナを経由して起動されるオペレーションも含まれます。非同期トランザクションは含まれません。

統合運用管理ツールからの設定は以下の通りとなります。

• プロセスグループの[上限設定]-[同時受付オペレーション数]

プロセスグループで現在受け付けているオペレーション数は、統合運用管理ツールの統計情報から参照できます。

• [統計情報]-[TPシステム]-[アプリケーショングループ]-[プロセスグループ]-[同時受付オペレーション数]

プロセスグループで現在受け付けているオペレーション数は、otxadminコマンドからでも参照できます。

otxadmin> get --monitor tpsystem.applicationGroups.apg_name.processGroups.pg_name.simultaneousRequestsCount-Current

7.2. Object Broker

7.2.1. Object Brokerの運用操作

Object Brokerに関する運用操作法について説明します。なお、各属性の説明については[ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.10. Object Broker > 1.10.1. Object Broker設定項目・設定方法 ]をご参照ください。

7.2.1.1. Object Brokerのオペレーション一覧

ここでは、Object BrokerコンフィグやObject Brokerサービスの各MOで実行可能なオペレーションについて説明します。

7.2.1.2. Object Brokerコンフィグの操作

Dottedname : server.objectbrokerconfig

Object Broker コンフィグ のオペレーションを以下に示します。[ ]内はコマンドで実行する場合のコマンド名です。

1. Object Broker Java プロパティ設定一覧取得 [get-ospi-java-properties]

2. Object Broker Java プロパティ設定値取得 [get-ospi-java-property]

3. Object Broker Java プロパティ設定 [set-ospi-java-property]

4. Object Broker Java プロパティの削除 [delete-ospi-java-property]

5. Object Broker C++プロパティ設定一覧取得 [get-cpp-properties]

6. Object Broker C++プロパティ設定値取得 [get-cpp-property]

7. Object Broker C++プロパティ設定 [set-cpp-property]

8. Object Broker C++プロパティの削除 [delete-cpp-property]

9. Object Broker 共通プロパティ設定一覧取得 [get-ospi-properties]

10. Object Broker 共通プロパティ設定値取得 [get-ospi-property]

11. Object Broker 共通プロパティ設定 [set-ospi-property]

12. Object Broker 共通プロパティの削除 [delete-ospi-property]

7.2.1.3. Object Brokerサービスの操作

Dottedname : server.objectbrokerservice

Object Broker サービス のオペレーションを以下に示します。[ ]内はコマンドで実行する場合のコマンド名です。

1. Object Broker サービスの起動 [start-ospi]

2. Object Broker サービスの停止 [stop-ospi]

Dottedname : server.objectbrokerservice.oad

oad のオペレーションを以下に示します。

1. Oad サービスの起動 [invoke server.objectbrokerservice.oad.start]

2. Oad サービスの停止 [invoke server.objectbrokerservice.oad.stop]

Dottedname : server.objectbrokerservice.namesv

namesv のオペレーションを以下に示します。

1. namesv サービスの起動 [invoke server.objectbrokerservice.namesv.start]

2. namesv サービスの停止 [invoke server.objectbrokerservice.namesv.stop]

Dottedname : server.objectbrokerservice.irsv

irsv のオペレーションを以下に示します。

1. irsv サービスの起動 [invoke server.objectbrokerservice.irsv.start]

2. irsv サービスの停止 [invoke server.objectbrokerservice.irsv.stop]

Dottedname : server.objectbrokerservice.corbaloc

corbaloc のオペレーションを以下に示します。

1. corbaloc サービスの起動 [invoke server.objectbrokerservice.corbaloc.start]

2. corbaloc サービスの停止 [invoke server.objectbrokerservice.corbaloc.stop]

Dottedname : server.objectbrokerservice.cnamesv

cnamesv のオペレーションを以下に示します。

1. cnamesv サービスの起動 [invoke server.objectbrokerservice.cnamesv.start]

2. cnamesv サービスの停止 [invoke server.objectbrokerservice.cnamesv.stop]

Dottedname : server.objectbrokerservice.oadj

oadj のオペレーションを以下に示します。[ ]内はコマンドで実行する場合のコマンド名です。

1. OadJ サービスの起動 [start-oadj]

2. OadJ サービスの停止 [stop-oadj]

3. インプリメンテーションの一覧 [listimpl]

4. インプリメンテーションの登録 [instimpl]

5. インプリメンテーションの削除 [rmimpl]

Dottedname : server.objectbrokerservice.ospprxy

ospprxy のオペレーションを以下に示します。[ ]内はコマンドで実行する場合のコマンド名です。

1. ospprxy サービスの起動 [start-ospprxy]

2. ospprxy サービスの停止 [stop-ospprxy]

7.2.2. 旧互換アプリケーションの運用操作

WebOTX バージョン5 以前に作成したCORBA アプリケーションをStandard, Enterpriseで運用操作する手順について説明します。Object Broker サービスのみを使用するWebOTX CORBA アプリケーションの場合とObjectBroker サービス以外のサービスを使用するWebOTX CORBA アプリケーションの場合で環境の構築方法および運用方法が異なります。

ドメイン内のObject Broker, ドメイン内のTransaction サービスとは、ドメインの起動および停止に連動することができ、${INSTANCE_ROOT}/config に設定ファイルを持ち、統合運用管理ツールや otxadmin コマンドで制御できるプロセスのことです。

ドメイン外のObject Broker, ドメイン外のTransaction サービスとは、WebOTX バージョン5 以前と同様の運用管理方式で、サービスから起動するプロセスのことです。

7.2.2.1. Object Broker サービスのみを使用する WebOTX CORBA アプリケーションの場合

ここでは、Object Broker サービスのみを使用するWebOTX CORBA アプリケーションの場合について説明します。 バージョン5 以前のWebOTX 旧互換ライブラリはドメイン固有の設定を参照することができません。このため、ドメインの設定 のほかに追加で旧互換の設定を行う必要があります。本節ではその手順について説明いたします。

環境構築

1.  ドメインを作成します。

2.  Object Brokerの設定を変更します。

otxadmin> get server.objectbrokerservice.oad.OadPort
otxadmin> get server.objectbrokerservice.namesv.NameServicePort

3.  ドメイン外のObject Broker を起動します。

# /etc/init.d/ObjectSpinner start (HP-UX の場合 /sbin/init.d/ObjectSpinner start)

4.  ドメインを起動します。

otxadmin> start-domain domain_name

5.  アプリケーションの配備・設定をします。

  運用上の注意点は次のとおりです。

• Object Brokerのポート番号を変更する場合は、統合運用管理ツールまたはotxadminで変更する以外に、2. で実施した箇所も同じポート番号に変更する必要があります。

ドメイン起動

otxadmin> start-domain domain_name

ドメイン停止

otxadmin> stop-domain domain_name

7.2.2.2. Object Broker サービス以外のサービスを使用する WebOTX CORBA アプリケーションの場合

以下では、バージョン5 以前に作成したWebOTX CORBA アプリケーションがTransaction サービスと連携する場合について説明します。 Transaction サービスとバージョン5 以前のWebOTX 旧互換ライブラリを動作させるためには、 両者でトランザクション情報などの情報を共有するためTransaction サービスをドメイン外で動作させる必要があります。 それに伴い、起動順序を維持するためObject Broker サービスをドメイン外で動作させる必要があります。 本節ではその手順について説明します。

環境構築

1.  ドメインを作成します。

2.  ドメインを起動します。

otxadmin> start-domain domain_name

3.  Object Brokerの設定を変更します。

otxadmin> set server.objectbrokerservice.oad.OadPort = <設定名OadPort の値(既定値9825)>
otxadmin> set server.objectbrokerservice.corbaloc.CorbalocDefaultPort = <設定名NameServicePort の値(既定値2809)>

otxadmin> set server.internal-lifecycle-module.ObjectBrokerService.state-order=initialization(既定値ready)

4.  ドメイン内のTransaction サービスの設定を変更します。

otxadmin> set server.internal-lifecycle-module.TransactionService.state-order=initialization(既定値ready)

5.  ドメインを停止します。

otxadmin> stop-domain domain_name

6.  ドメイン外のTransactionService(RCD)をサービス登録します。(Windows のみ)

> wotsrcd -a

7.  ドメイン外のTransactionサービスの設定をします。

8.  ドメイン外のObject Broker とTransaction サービスを起動します。

# /etc/init.d/ObjectSpinner start (HP-UX の場合 /sbin/init.d/ObjectSpinner start)
# /etc/init.d/WebOTX_TS start (HP-UX の場合 /sbin/init.d/WebOTX_TS start) 

9.  ドメインを起動します。

otxadmin> start-domain domain_name

10.  アプリケーションの配備・設定をします。

  運用上の注意点は次のとおりです。

ドメイン起動

ドメイン停止

7.3. JMS

JMSに関する運用操作法について説明します。なお、各属性の詳細については[ 7.3.1. JMSサービスの操作 > 7.3.1.2. 属性参照・設定 ]、および[ リファレンス集 運用管理・設定編 > 2. MO定義リファレンス ]を参照してください。

7.3.1. JMSサービスの操作

JMSサービスで管理しているJMSサーバの起動と停止、および、項目の参照と設定の手順について説明します。

7.3.1.1. 起動・停止

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」を選択し、右クリックするか、あるいは、メニューバーの[操作] を選択します。
2. 表示されるメニューから「JMSサーバの起動」を選択するとJMSサーバが起動します。また、「JMSサーバの停止」を選択することでJMSサーバが停止します。
   
   

   
   図7.3.1.1-1

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

1. JMSサーバを起動するには、以下のコマンドを実行します。

   otxadmin> invoke server.jms-service.start

   あるいは

   otxadmin> start-jms

   
   start-jmsコマンドの詳細については運用管理コマンドリファレンスの「start-jms」を参照してください。
   
   
   
2. JMSサーバを停止するには、以下のコマンドを実行します。

   otxadmin> invoke server.jms-service.stop

   あるいは

   otxadmin> stop-jms

   
   stop-jmsコマンドの詳細については、運用管理コマンドリファレンスの「stop-jms」を参照してください。

7.3.1.2. 属性参照・設定

JMSサービスの属性の詳細については、MO定義リファレンスの「jms-service」を参照してください。

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」を選択します(選択すると、リストビューから各属性を参照できます)。
2. リストビューから変更したい属性を選択して変更します。
3. 「更新」ボタンをクリックして変更を反映します。

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

1. 属性に設定している値を参照するには、getコマンドを使用します。
   
   

   例) 1つの項目(ログレベル)を参照する場合

   otxadmin> get server.jms-service.loglevel

   
   

   例) すべての項目を参照する場合 (プロパティが設定されている場合は、プロパティも表示されます)

   otxadmin> get server.jms-service.*

   
   
   
2. 属性の値を設定するには、setコマンドを使用します。
   
   

   例) ログレベルを設定する場合

   otxadmin> set server.jms-service.loglevel=ERROR

   
   

注意 :

以下の属性は、JMSサーバの起動中は変更が動的に反映されます。JMSサーバの停止中は、次回起動するときにその値が有効になります。

表7.3.1.2-1

統合運用管理ツールでの属性名	運用管理コマンドでの属性名(attribute-name)
システム内メッセージ最大数	systemMaxCount
システム内メッセージ最大合計サイズ	systemMaxSize
最大メッセージサイズ	messageMaxSize
ログレベル	loglevel
ログロールオーバーサイズ	logfileRolloverBytes
ログロールオーバー間隔	logfileRolloverSecs
自動トピック作成の許可	autocreateTopic
自動キュー作成の許可	autocreateQueue
自動生成キューに対するアクティブコンシューマの最大数	autocreateMaxNumActiveConsumers
自動生成キューに対するバックアップコンシューマの最大数	autocreateMaxNumBackupConsumers
JMSクライアントメモリ情報採取	enableClientMetrics
メッセージ一覧表示最大件数	displayMessageCount
パケット(メッセージ)情報採取	logPacketMessage
パケット(PING)情報採取	logPacketPing
パケット(運用管理)情報採取	logPacketAdmin
パケット(クラスタ)情報採取	logPacketCluster
パケットログロールオーバーサイズ	logfileRolloverBytesPacket
パケットログロールオーバー間隔	logfileRolloverSecsPacket
運用管理操作履歴採取	logAdmin
運用管理操作履歴ファイルロールオーバーサイズ	logfileRolloverBytesAdmin
運用管理操作履歴ファイルロールオーバー間隔	logfileRolloverSecsAdmin
メッセージライフサイクル情報採取	logMessage
メッセージログロールオーバーサイズ	logfileRolloverBytesMessage
メッセージログロールオーバー間隔	logfileRolloverSecsMessage
エラー情報採取	logError
エラーログロールオーバーサイズ	logfileRolloverBytesError
エラーログロールオーバー間隔	logfileRolloverSecsError

7.3.1.3. プロパティ参照・設定

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
2. プロパティを参照する場合は、メニューから「プロパティ一覧の取得」を選択し、表示されるダイアログで「実行」ボタンをクリックします。
   
   

   
   図7.3.1.3-1

3. プロパティを設定する場合は、メニューから「プロパティの設定」を選択し、表示されるダイアログで設定値を入力して「実行」ボタンをクリックします。
   
   

   
   図7.3.1.3-2

   例) JMSサーバインスタンス識別子を設定する場合は次のように入力します。

   instance-name=jms1

運用管理コマンド(otxadmin)からの操作

属性の参照・設定と同様にgetコマンド、setコマンドを利用します。

7.3.1.4. JMSサーバの一覧の取得

JMSサーバクラスタを構成しているときに、クラスタ内の各JMSサーバの状態を確認する場合に利用します。表示する情報は次のとおりです。
この説明での「ローカルのJMSサーバ」とは、操作を実行したドメイン上のJMSサーバをさします。

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」を選択し、右クリックするか、あるいは、メニューバーの[操作] を選択します。
2. 表示されるメニューから「JMSサーバの一覧の取得」を選択すると、クラスタを構成するJMSサーバの状態を一覧表示します。

   
   図7.3.1.4-1

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

1. JMSサーバクラスタを構成しているときに、クラスタ内の各JMSサーバの状態を確認する場合には、以下のコマンドを実行します。

   otxadmin> list-jms-services

   
   

    
   結果表示例） 
   ---------------------------------------------
   Broker ID Address                 State
   ---------------------------------------------
   BROKER1   SVR1:9900               OPERATING
   BROKER2   SVR2:9700               OPERATING
   Command list-jms-services executed successfully.
   

list-jms-servicesコマンドの詳細については、運用管理コマンドリファレンスの「list-jms-services」を参照してください。

7.3.1.5. コネクション一覧の取得

JMSサーバに接続しているJMSクライアントのコネクションを確認する場合に利用します。表示する情報は次のとおりです。

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」を選択し、右クリックするか、あるいは、メニューバーの[操作] を選択します。
2. 表示されるメニューから「コネクション一覧の取得」を選択し、表示されるダイアログで「表示対象タイプ」と、送信先で絞り込みたい場合は「送信先名」を指定して「実行」ボタンをクリックします。

   
   図7.3.1.5-1

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

1. JMSサーバに接続しているコネクションの情報を表示するには、list-jms-connectionコマンドを使用します。

   otxadmin> list-jms-connections [--wojmsListType <表示対象タイプ>] [--wojmsDestinationName <送信先名>]

   
   

   例) 送信先 MyQueue に接続しているコンシューマが利用しているコネクションを表示する場合

   otxadmin> list-jms-connections --wojmsListType CONSUMERS --wojmsDestinationName MyQueue

    
   結果表示例） 
   ----------------------------------------------------------------------------------------------------------------------
   Connection ID       Client ID  User  Service Producers Consumers Host      Port Max Memory Current Memory Peak Memory
   ----------------------------------------------------------------------------------------------------------------------
   7738908095054457858 JMS_C00010 guest jms     0         1         127.0.0.1 2957 0          0              0
   7738908095054509825 JMS_C00020 guest jms     0         1         127.0.0.1 2977 0          0              0
   7738908095054473986 JMS_C00013 guest jms     0         1         127.0.0.1 2963 0          0              0
   コマンド list-jms-connections は正常に実行されました。
   

   
   list-jms-connectionsコマンドの詳細については、運用管理コマンドリファレンスの「list-jms-connections」を参照してください。

7.3.1.6. コネクションクローズ

JMSサーバから、JMSクライアントのコネクションを強制的にクローズする場合に利用します。

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」を選択し、右クリックするか、あるいは、メニューバーの[操作] を選択します。
2. 表示されるメニューから「コネクションクローズ」を選択し、表示されるダイアログで「クローズ対象タイプ」と、必要な場合は「クローズ対象」を選択して「実行」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

1. コネクションをクローズするには、close-jms-connectionコマンドを使用します。

   otxadmin> close-jms-connection [--wojmsCloseType <クローズ対象タイプ>] [--wojmsDestinationName <送信先名>] [--wojmsConnectionID <コネクションID>]

   
   

   例) 送信先 MyQueue に接続しているすべてのコンシューマが利用しているコネクションをクローズする場合

   otxadmin> close-jms-connection --wojmsListType CONSUMERS --wojmsDestinationName MyQueue

   
   

   例) 特定のコネクションをクローズする場合

   otxadmin> close-jms-connection --wojmsConnectionID 102030494848

   
   close-jms-connectionコマンドの詳細については、運用管理コマンドリファレンスの「close-jms-connection」を参照してください。

7.3.1.7. 送信先の再表示

JMSサーバクラスタを構成しているときに、別のドメインからの伝播により作成した送信先のMOを表示するときに利用します。

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」を選択し、右クリックするか、あるいは、メニューバーの[操作] を選択します。
2. 表示されるメニューから「送信先の再表示」を選択すると、別のドメインで作成された送信先のMOが表示されます。

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

1. JMSサーバクラスタを構成しているときに、別のドメインで作成した送信先のMOを表示するには、以下のコマンドを使用します。

   otxadmin> invoke server.jms-service.updateJmsDestinations

   
   

備考 :

情報が正しく取得できたかどうかは、以下のコマンドで確認できます。

otxadmin> list-jmsdest

7.3.1.8. スレッドダンプの取得

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

1. JMSサーバのスレッドダンプを取得するには、以下のコマンドを使用します。

   otxadmin> invoke server.jms-service.dumpThreads

   
   結果は、${ INSTANCE_ROOT}/logs/wojms/std.logファイルへ出力されます。

注意 :

スレッドダンプ取得操作は、統合運用管理ツールで行うことはできません。上記のコマンドを利用するか、JMSサーバが提供している wojmscmd dump thd コマンドを利用してください。

wojmscmd dump thdコマンドの詳細については、[ リファレンス集 運用管理・設定編 > 4. 運用管理コマンドリファレンス > 4.4. JMS > 4.4.2. wojmscmd > 4.4.2.4. dump thd ] を参照してください。

7.3.2. 送信先の操作

物理的な送信先の作成と削除、および、項目の参照と設定の手順について説明します。

7.3.2.1. 新規作成

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

1. ツリービューより、「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
2. メニューから「送信先作成」を選択します。
3. 表示されるダイアログで、「基本」タブの「送信先名」、「送信先タイプ」を指定し、さらに、必要な属性の値を指定して「実行」ボタンをクリックします。また、「送信先リソースを同時に生成する」をチェックすることで、送信先リソースを同時に作成することができます。
4. 作成が正常終了すると、ツリービューの「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」-「<送信先名>」配下に、指定した送信先名でMOが表示されます。
   
   

   
   図7.3.2.1-1

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

1. 送信先を新規に作成する場合は、create-jmsdestコマンドを使用します。

   otxadmin> create-jmsdest --desttype <送信先タイプ> [オプション]

   
   

   例) トピックと送信先リソースを作成する場合

   otxadmin> create-jmsdest --desttype topic --cascade MyTopic

   この例では、--cascadeオプションにより、物理的な送信先と、送信先リソースを同時に生成しています。送信先リソースのJNDI名は「jms/MyTopic(jms/<物理的な送信先名>)」となります。--jndinameオプションにより、JNDI名を明示的に指定することができます。

   
   

   作成時に、属性や、プロパティを指定することもできます。コマンドの詳細については運用管理コマンドリファレンスの「create-jmsdest」を参照してください。

   
   
   
2. 送信先一覧を表示する場合は、list-jmsdestコマンドを使用します。

   otxadmin> list-jmsdest [--desttype <送信先タイプ>]

   
   

   例) トピックだけを表示する場合

   otxadmin> list-jmsdest --desttype topic

   
   list-jmsdestコマンドの詳細については、運用管理コマンドリファレンスの「list-jmsdest」を参照してください。

7.3.2.2. 削除

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

1. ツリービューより、削除対象の「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」-「送信先名」-「<送信先名>」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
2. メニューから「削除」を選択し、表示されるダイアログで「実行」ボタンをクリックします。「送信先リソースを同時に削除する」をチェックすることで、送信先リソースの送信先名に、削除対象の送信先名が指定されているものをすべて削除することができます。

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

1. 送信先を削除する場合は、delete-jmsdest コマンドを使用します。

   otxadmin> delete-jmsdest <送信先名>

   例) トピックと送信先リソースを削除する場合

   otxadmin> delete-jmsdest --cascade MyTopic

   この例では、--cascadeオプションにより、送信先リソースの送信先名(wojmsDestinationName)に「MyTopic」が指定されているものをすべて削除しています。

   
   delete-jmsdest コマンドの詳細については、運用管理コマンドリファレンスの「delete-jmsdest」を参照してください。

7.3.2.3. 属性参照・設定

物理的な送信先の属性の詳細については、MO定義リファレンスの「jms-physical-destination」を参照してください。

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」-「送信先名」-「<送信先名>」を選択します(選択すると、リストビューから各属性を参照できます)。
2. リストビューから変更したい属性を選択して変更します。
3. 「更新」ボタンをクリックして変更を反映します。

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

1. 属性に設定している値を参照するには、getコマンドを使用します。
   
   

   例) 1つの項目を参照する場合

   otxadmin> get server.jms-service.jms-physical-destination.MyQueue.maxBytesPerMsg

   
   

   例) すべての項目を参照する場合 (プロパティが設定されている場合は、プロパティも表示されます)

   otxadmin> get server.jms-service.jms-physical-destination.MyQueue.*

   
   
   
2. 属性の値を設定するには、setコマンドを使用します。
   
   

   例) maxBytesPerMsgを設定する場合

   otxadmin> set server.jms-service.jms-physical-destination.MyQueue.maxBytesPerMsg=-1

   
   
   

7.3.2.4. プロパティ参照・設定

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」-「送信先名」-「<送信先名>」を選択して右クリックするか、選択した状態でメニューバーの[操作]を選択します。
2. プロパティを参照する場合は、メニューから「プロパティ一覧の取得」を選択し、表示されるダイアログで「実行」ボタンをクリックします。
3. プロパティを設定する場合は、メニューから「プロパティの設定」を選択し、表示されるダイアログで設定値を入力して「実行」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作

属性の参照・設定と同様にgetコマンド、setコマンドを利用します。

7.3.2.5. 情報取得

送信先の動作状況や、その送信先に接続しているプロデューサやコンシューマの情報を確認する場合に利用します。表示する情報は次のとおりです。

• 送信先の情報

  表7.3.2.5-1

  表示名	説明
  Current State	送信先の状態。次の状態が存在します。 RUNNING ： 動作中 CONSUMERS_PAUSED ： コンシューマが停止している状態 PRODUCERS_PAUSED ： プロデューサが停止している状態 PAUSED ： コンシューマ、プロデューサともに停止している状態
  Current Number of Messages	滞留メッセージ数
  Current Total Message Bytes	滞留メッセージバイト数
  Current Number of Producers	プロデューサ数
  Current Number of Active Consumers	コンシューマ数
  Current Number of Backup Consumers	バックアップコンシューマ数(キューの場合のみ)

  
  
• 接続プロデューサの情報

  表7.3.2.5-2

  表示名	説明
  Producer ID	プロデューサID
  Connection ID	コネクションID
  Client ID	クライアントID

  
  
• 接続コンシューマの情報

  表7.3.2.5-3

  表示名	説明
  Consumer ID	プロデューサID
  Connection ID	コネクションID
  Client ID	クライアントID
  Last Ack Time	コンシューマが最後に確認応答(ACKNOWLEDGE)を返した時刻
  Selector	セレクタ

  
  
  

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」-「送信先名」-「<送信先名>」を選択して右クリックするか、選択した状態でメニューバーの[操作]を選択します。
2. 送信先の現時点の状態などを知りたい場合は、メニューから「情報取得」を選択し、表示されるダイアログで「実行」ボタンをクリックします。

   
   図7.3.2.5-1

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

1. 送信先の現時点の状態などを知りたい場合は、get-jmsdest-infoコマンドを使用します。

   otxadmin> get-jmsdest-info <送信先名>

   
   

   例) トピックMyTopicの情報を表示する場合

   otxadmin> get-jmsdest-info MyTopic

    
   結果表示例） 
   Current State                      RUNNING
   Current Number of Messages         8
   Current Total Message Bytes        1192
   Current Number of Producers        2
   Current Number of Active Consumers 1
   Current Number of Backup Consumers 0
   Producers:
   --------------------------------------------------
   Producer ID         Connection ID       Client ID
   --------------------------------------------------
   7458277433419032321 7458277433419020544
   7458277433396530432 7458277433396232704
   Consumers:
   ----------------------------------------------------------------------------------------------
   Consumer ID         Connection ID       Client ID Last Ack Time           Selector
   ----------------------------------------------------------------------------------------------
   7458277433426870528 7458277433426854656           2009/03/04 11:46:12.590 TestProperty IS NULL
   コマンド get-jmsdest-info は正常に実行されました。
   

   get-jmsdest-infoコマンドの詳細については、運用管理コマンドリファレンスの「get-jmsdest-info」を参照してください。

7.3.2.6. 送信先の一時停止・再開

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」-「送信先名」-「<送信先名>」を選択して右クリックするか、選択した状態でメニューバーの[操作]を選択します。
2. 送信先の一時停止をする場合は、メニューから「一時停止」を選択し、表示されるダイアログで「停止タイプ」を選択し、「実行」ボタンをクリックします。その送信先に接続しているコンシューマを停止させたいときは「CONSUMERS」を、プロデューサを停止させたいときは「PRODUCERS」を、コンシューマとプロデューサともに停止させたいときは「ALL」を選択します。

   
   図7.3.2.6-1

3. 一時停止中の送信先を再開する場合は、メニューから「再開」を選択し、表示されるダイアログで「実行」ボタンをクリックします。 「再開」は、どの停止状態（CONSUMERS_PAUSED、PRODUCERS_PAUSED、PAUSED）からでも再開します。

なお、現時点の送信先の停止状態は、「情報取得」で確認することができます。

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

1. 送信先の一時停止をする場合は、以下のコマンドを使用します。

   otxadmin> invoke server.jms-service.jms-physical-destination.<送信先名>.pause <停止タイプ>

   停止タイプには、1から3の数字を指定します。それぞれの数字は、次を意味します。

   表7.3.2.6-1

   停止タイプ	説明
   1	コンシューマを停止（CONSUMERS_PAUSED）
   2	プロデューサを停止（PRODUCERS_PAUSED）
   3	コンシューマ、プロデューサともに停止（PAUSED）

   
   

   例) トピックMyTopicのプロデューサを停止する場合

   otxadmin> invoke server.jms-service.jms-physical-destination.MyTopic.pause 2

   
   

   なお、現時点の送信先の停止状態は、情報取得(get-jmsdest-info)コマンドで確認することができます。
   
   
   
2. 一時停止中の送信先を再開する場合は、以下のコマンドを使用します。

   otxadmin> invoke server.jms-service.jms-physical-destination.<送信先名>.resume

   「再開」は、どの停止状態（CONSUMERS_PAUSED、PRODUCERS_PAUSED、PAUSED）からでも再開します。
   
   

   例） 一時停止状態のトピックMyTopicを再開させる場合

   otxadmin> invoke server.jms-service.jms-physical-destination.MyTopic.resume

   
   
   

7.3.2.7. メッセージ一覧の取得

送信先に滞留している一つ一つのメッセージ情報を確認する場合に利用します。表示する情報は次のとおりです。

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」-「送信先名」-「<送信先名>」を選択して右クリックするか、選択した状態でメニューバーの[操作]を選択します。
2. 送信先の現時点の状態などを知りたい場合は、メニューから「メッセージ一覧の取得」を選択し、表示されるダイアログで「メッセージ一覧開始点」、「メッセージ一覧終了点」、「セレクタ」、「メッセージ本体表示」を指定して、「実行」ボタンをクリックします。

注意 :

メッセージの最大表示件数は、JMSサービスのプロパティ「メッセージ一覧表示最大件数（displayMessageCount）」で制限されています。デフォルトは最大1000件です。

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

1. 送信先に滞留しているメッセージの一覧を表示するには以下のコマンドを使用します。

   otxadmin> list-jmsdest-messages [--fromIndex <表示開始点>] [--toIndex <表示終了点>] [--selector <メッセージセレクタ>] [--messageBody=(true|false)] <送信先名>

   
   

   例) メッセージセレクタを指定して、キューMyQueueのメッセージ一覧を表示する場合

   otxadmin> list-jmsdest-messages --selector "NewsType = 'Sports' OR NewsType = 'Business'" MyQueue

   
   

list-jmsdest-messages コマンドの詳細については、運用管理コマンドリファレンスの「list-jmsdest-messages」を参照してください。

7.3.2.8. 指定メッセージパージ・メッセージ全件パージ

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」-「送信先名」-「<送信先名>」を選択して右クリックするか、選択した状態でメニューバーの[操作]を選択します。
2. ある特定のメッセージをパージする場合は、メニューから「指定メッセージパージ」を選択し、表示されるダイアログで、パージ対象の「メッセージID」を入力して、「実行」ボタンをクリックします。
3. この「メッセージID」は、メッセージ一覧の取得で表示されたメッセージIDを指定します。
4. 送信先に滞留しているすべてのメッセージをパージする場合は、メニューから「メッセージ全件パージ」を選択し、表示されるダイアログで「実行」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

1. ある特定のメッセージをパージする場合は、以下のコマンドを使用します。

   otxadmin> invoke server.jms-service.jms-physical-destination.<送信先名>.purgeMessage <メッセージID>

   
   

   例) キューMyQueueに滞留しているメッセージをパージする場合

   otxadmin> invoke server.jms-service.jms-physical-destination.MyQueue.purgeMessage 6-172.16.254.239(fd:af:ca:bc:90:f6)-2380-1148467078081

   この「メッセージID」は、メッセージ一覧の取得で表示されたメッセージIDを指定します。

   
   
   
2. 送信先に滞留しているすべてのメッセージをパージする場合は、以下のコマンドを使用します。

   otxadmin> invoke server.jms-service.jms-physical-destination.<送信先名>.purge

   
   

   例) キューMyQueueに滞留しているメッセージをパージする場合

   otxadmin> invoke server.jms-service.jms-physical-destination.MyQueue.purge

   この「メッセージID」は、メッセージ一覧の取得で表示されたメッセージIDを指定します。

   
   
   

7.3.2.9. 永続サブスクリプションの操作(トピックのみ)

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」-「送信先名」-「<送信先名>」を選択して右クリックするか、選択した状態でメニューバーの[操作]を選択します。
2. トピックに対する永続サブスクリプションの一覧を表示するには、メニューから「永続サブスクリプションの一覧表示」を選択し、表示されるダイアログで「実行」ボタンをクリックします。表示する情報は、左から順に、永続サブスクリプション名、クライアントID、メッセージ数、状態（true：アクティブ／false：非アクティブ）です。

   
   図7.3.2.9-1

3. 永続サブスクリプションのメッセージをパージするには、メニューから「永続サブスクリプションのメッセージのパージ」を選択し、表示されるダイアログで、パージ対象の「永続サブスクリプション名」と、「クライアントID」を入力して、「実行」ボタンをクリックします。この「永続サブスクリプション名」や、「クライアントID」には、2の一覧表示で表示されたものを指定します。
4. 永続サブスクリプションを削除するには、メニューから「永続サブスクリプションの削除」を選択し、表示されるダイアログで、削除対象の「永続サブスクリプション名」と、「クライアントID」を入力して、「実行」ボタンをクリックします。この「永続サブスクリプション名」や、「クライアントID」には、2の一覧表示で表示されたものを指定します。

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

1. トピックに対する永続サブスクリプションの一覧を表示するには、list-jmsdest-durコマンドを使用します。

   otxadmin> list-jmsdest-dur <トピック名>

   
   

   例) トピックMyTopicに対する永続サブスクリプションの一覧を表示する場合

   otxadmin> list-jmsdest-dur MyTopic

    
   結果表示例） 
   -------------------------------------------------------------------
   Durable Sub. Name Client ID Number of Messages Durable Sub. State
   -------------------------------------------------------------------
   subscription      client1   92                 false
   subscription      client2   0                  true
   Command list-jmsdest-dur executed successfully.
   

   表示する情報は、左から順に、永続サブスクリプション名、クライアントID、メッセージ数、状態（true：アクティブ／false：非アクティブ）です。

   
   

   list-jmsdest-durコマンドの詳細については、運用管理コマンドリファレンスの「list-jmsdest-dur」を参照してください。

   
   
   
2. 永続サブスクリプションのメッセージをパージするには、以下のコマンドを使用します。

   otxadmin> invoke server.jms-service.jms-physical-destination.<送信先名>.purgeDur <永続サブスクリプション名> <クライアントID>

   
   

   例) トピックMyTopicの永続サブスクリプション（永続サブスクリプション名：subscription、クライアントID：clinet2）のメッセージをパージする場合

   otxadmin> invoke server.jms-service.jms-physical-destination.MyTopic.purgeDur subscription client2

   
   この「永続サブスクリプション名」や、「クライアントID」には、1の一覧表示で表示されたものを指定します。
   
   
   
3. 永続サブスクリプションを削除するには、以下のコマンドを使用します。

   otxadmin> invoke server.jms-service.jms-physical-destination.<送信先名>.deleteDur <永続サブスクリプション名> <クライアントID>

   
   

   例) トピックMyTopicの永続サブスクリプション（永続サブスクリプション名：subscription、クライアントID：clinet2）を削除する場合

   otxadmin> invoke server.jms-service.jms-physical-destination.MyTopic.deleteDur subscription client2

   
   この「永続サブスクリプション名」や、「クライアントID」には、1の一覧表示で表示されたものを指定します。

7.3.2.10. JMSメッセージの送信

環境構築時の確認や、コンシューマアプリケーションの受信動作確認など、簡単なメッセージ送信に利用できます。1回のメッセージ送信操作で送信できるメッセージは、1件です。

送信メッセージに設定できる項目と既定値は、次のとおりです。設定項目の()内の記述は、対応するヘッダフィールド名を示します。

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」-「送信先名」-「<送信先名>」を選択して右クリックするか、選択した状態でメニューバーの[操作]を選択します。
2. メニューから「JMSメッセージの送信」を選択し、表示されるダイアログで必要な項目を設定して「実行」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

1. JMSメッセージを送信するには以下のコマンドを使用します。

   otxadmin> send-jms-message [--msgtype <メッセージタイプ>] [--msgbodytype <メッセージボディの指定方法>] [--msgbody <メッセージボディ>] [--msgpersistent <配信モード>] [--msgexpiration <有効期限>] [--msgpriority <優先順位>] [--msgcorrelationid <相関ID>] [--msgreplyto <応答用送信先>] [--msgreplytotype <応答用送信先タイプ>] [--msgjmstype <タイプ>] [--msgdelaytime <配信遅延時間>] [--property <メッセージプロパティ>] <送信先名>

   send-jms-message コマンドの詳細については、運用管理コマンドリファレンスの「send-jms-message」を参照してください。

7.3.2.11. メッセージ移動

送信先に滞留している通常メッセージや、不達メッセージ(再配信回数の上限を超えたメッセージ)を別の送信先に移動する場合に利用します。移動後のメッセージはメッセージIDなどが変わります。移動によるメッセージヘッダや、プロパティの変更内容は次のとおりです。

備考 :

• メッセージ移動に関する注意事項などは、[ 注意制限事項 > 9. JMS > 9.13. メッセージ移動について ]を参照してください。
• 「不達メッセージ転送先」へ転送された不達メッセージのメッセージヘッダや、プロパティの変更内容については、[ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.7. JMS > 1.7.3. その他の設定項目・設定方法 > 1.7.3.12. 破棄メッセージの転送に関する設定 ]を参照してください。

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

1. 移動元と、移動先の送信先を、ALL(コンシューマ、プロデューサともに停止)で一時停止します。送信先の一時停止方法は、「送信先の一時停止・再開」を参照して下さい。
2. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」-「送信先名」-「<(移動元の)送信先名>」を選択して右クリックするか、選択した状態でメニューバーの[操作]を選択します。
3. メニューから「メッセージ移動」を選択し、表示されるダイアログで、移動元の送信先のタイプに応じて必要な項目を指定し、「実行」ボタンをクリックします。

   キューの場合：

   「移動対象」、「移動先の送信先名」、移動メッセージの条件を絞りたい場合は「メッセージセレクタ」を指定します。

   トピックの場合：

   「永続サブスクリプション名」、「クライアントID」、「移動先の送信先名」を指定します。

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

1. 移動元と、移動先の送信先を、ALL(コンシューマ、プロデューサともに停止)で一時停止します。送信先の一時停止方法は、「送信先の一時停止・再開」を参照して下さい。
2. JMSメッセージを移動するには以下のコマンドを使用します。移動元の送信先のタイプに応じて指定するオプションが異なります。

   キューの場合：

   otxadmin> move-jmsdest-messages --msgmovetype move_type [--selector selector] <移動元の送信先名> <移動先の送信先名>

   トピックの場合：

   otxadmin> move-jmsdest-messages --msgmovedur durable_name --msgmovecid client_id <移動元の送信先名> <移動先の送信先名>

   例) キュー DMQ に転送された不達メッセージを元のキュー MyQueue へ戻す場合

   otxadmin> move-jmsdest-messages --msgmovetype redeliver DMQ MyQueue

   
   

   例) トピック MyTopic の永続サブスクリプション Sub1 からキュー MyQueue へ移動する場合

   otxadmin> move-jmsdest-messages --msgmovedur Sub1 --msgmovecid Client1 MyTopic MyQueue

   
   
   

move-jmsdest-messages コマンドの詳細については、運用管理コマンドリファレンスの「move-jmsdest-messages」を参照してください。

7.3.2.12. 滞留メッセージの優先順位変更

送信先に滞留しているメッセージの優先順位を、運用操作により変更する場合に利用します。

備考 :

• 滞留メッセージの優先順位変更に関する注意事項などは、[ 注意制限事項 > 9. JMS > 9.15. 滞留メッセージの優先順位変更について ]を参照してください。

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」-「送信先名」-「<送信先名>」を選択して右クリックするか、選択した状態でメニューバーの[操作]を選択します。
2. メニューから「メッセージ優先順位変更」を選択し、表示されるダイアログで、変更対象の「メッセージID」を入力して、「実行」ボタンをクリックします。
3. この「メッセージID」は、メッセージ一覧の取得で表示されたメッセージIDを指定します。

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

1. ある特定のメッセージの優先順位を変更する場合は、以下のコマンドを使用します。

   otxadmin> update-jms-message [--msgpriority <優先順位>] <送信先名> <メッセージID>

   
   

   例) キュー MyQueue に滞留しているメッセージの優先順位を 9 に変更する場合

   otxadmin> update-jms-message --msgpriority 9 MyQueue 6-172.16.254.239(fd:af:ca:bc:90:f6)-2380-1148467078081

   この「メッセージID」は、メッセージ一覧の取得で表示されたメッセージIDを指定します。

   
   
   

7.3.3. JMSリソースの操作

JMSリソース(コネクションファクトリリソース、送信先リソース)の作成と削除、および、項目の参照と設定の手順について説明します。

7.3.3.1. 新規作成

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

1. ツリービューより、「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「リソース」-「JMSリソース」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。

   
   図7.3.3.1-1

2. メニューから、作成するリソースに応じて、以下を選択します。
   • コネクションファクトリリソース ： 「コネクションファクトリリソースの作成」
   • 送信先リソース ： 「送信先リソースの作成」
3. 表示されるダイアログで、「一般」タブの「JNDI名」、「リソースタイプ」を指定し、さらに、必要な属性の値を指定して「実行」ボタンをクリックします。
4. 作成が正常終了すると、ツリービューにそれぞれ以下のMOが表示されます。
   
   

   コネクションファクトリリソース ：

   「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「リソース」-「JMSリソース」-「コネクションファクトリリソース」-「<JNDI名>」
   
   コネクションファクトリリソース作成時には、以下のMOも自動的に作成して表示します。
   「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「リソース」-「コネクタコネクションプール」-「<JNDI名>」
   「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「リソース」-「コネクターリソース」-「<JNDI名>」
   「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「リソース参照」-「<JNDI名>」
   

   
   

   送信先リソース ：

   「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「リソース」-「JMSリソース」-「送信先リソース」-「<JNDI名>」
   
   送信先リソース作成時には、以下のMOも自動的に作成して表示します。
   「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「リソース」-「admin-object-resource」-「<JNDI名>」
   「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「リソース参照」-「<JNDI名>」
   
   

   備考 ：

   送信先リソース作成時に、「物理的な送信先を同時に生成する」をチェックすることで、「送信先名」に指定した物理的な送信先を同時に作成することができます。
   
   

   
   

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

1. JMSリソースを新規に作成する場合は、create-jms-resourceコマンドを使用します。

   otxadmin> create-jms-resource --restype <リソースタイプ> [オプション] <JNDI名>

   
   

   例) 送信先リソースを作成する場合

   otxadmin> create-jms-resource --restype javax.jms.Topic --wojmsDestinationName MyTopic jms/MyTopic

   
   

注意 ：

送信先リソースを作成する場合、物理的な送信先名(--wojmsDestinationName)の指定は必須です。

作成時に、属性や、プロパティを指定することもできます。また、送信先リソースの場合、--cascadeオプションを付加することによって、送信先名に指定した物理的な送信先を同時に作成することも可能です。コマンドの詳細については、運用管理コマンドリファレンスの「create-jms-resource」を参照してください。

7.3.3.2. 削除

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

1. 対象のリソースに応じて、それぞれ以下を選択して右クリックするか、選択した状態でメニューバーの[操作]を選択します。
   
   

   コネクションファクトリリソース ：

   「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「リソース」-「JMSリソース」-「コネクションファクトリリソース」-「<JNDI名>」

   送信先リソース ：

   「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「リソース」-「JMSリソース」-「送信先リソース」-「<JNDI名>」

   
   
   
2. メニューから「削除」を選択し、表示されるダイアログで「実行」ボタンをクリックします。

   
   図7.3.3.2-1

   備考 ：

   送信先リソース削除時に、「物理的な送信先を同時に削除する」をチェックすることで、「送信先名」に指定した物理的な送信先を同時に削除することができます。
   
   

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

1. JMSリソースを削除する場合は、delete-jms-resourceコマンドを使用します。

   otxadmin> delete-jms-resource <JNDI名>

   
   

   例) 送信先リソースを削除する場合

   otxadmin> delete-jms-resource jms/MyTopic

   
   
   

送信先リソースの場合、--cascadeオプションを付加することによって、送信先名に指定した物理的な送信先を同時に削除することも可能です。delete-jms-resourceコマンドの詳細については、運用管理コマンドリファレンスの「delete-jms-resource」を参照してください。

7.3.3.3. 属性参照・設定

JMSリソース(コネクションファクトリリソース、送信先リソース)の属性の詳細については、MO定義リファレンスの「jms-connection-factory」、および、「jms-logical-destination」を参照してください。

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

1. 対象のリソースに応じて、それぞれ以下を選択します(選択すると、リストビューから各属性を参照できます)。
   
   

   コネクションファクトリリソース ：

   「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「リソース」-「JMSリソース」-「コネクションファクトリリソース」-「<JNDI名>」

   送信先リソース ：

   「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「リソース」-「JMSリソース」-「送信先リソース」-「<JNDI名>」

   
   
2. リストビューから変更したい属性を選択して変更します。
3. 「更新」ボタンをクリックして変更を反映します。

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

1. 項目に設定している値を参照するには、getコマンドを使用します。
   
   

   例) 1つの項目を参照する場合

   otxadmin> get server.resources.jms-resource.jms-connection-factory.jms/MyQueueFactory.wojmsConnectionType

   
   

   例) すべての項目を参照する場合(プロパティが設定されている場合は、プロパティも表示されます)

   otxadmin> get server.resources.jms-resource.jms-connection-factory.jms/MyQueueFactory.*

   
   
2. 項目の値を設定するには、setコマンドを使用します。
   
   

   例) コネクションタイプを設定する場合

   otxadmin> set server.resources.jms-resource.jms-connection-factory.jms/MyQueueFactory.wojmsConnectionType=TCP

   
   
   

7.3.3.4. プロパティ参照・設定

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

1. 対象のリソースに応じてそれぞれ以下を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
   
   

   コネクションファクトリリソース ：

   「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「リソース」-「JMSリソース」-「コネクションファクトリリソース」-「<JNDI名>」

   送信先リソース ：

   「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「リソース」-「JMSリソース」-「送信先リソース」-「<JNDI名>」

   
   
2. プロパティを参照する場合は、メニューから「プロパティ一覧の取得」を選択し、表示されるダイアログで「実行」ボタンをクリックします。
3. プロパティを設定する場合は、メニューから「プロパティの設定」を選択し、表示されるダイアログで設定値を入力して「実行」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作

属性の参照・設定と同様にgetコマンド、setコマンドを利用します。

例) すべてのプロパティを参照する場合

otxadmin> get server.resources.jms-resource.jms-connection-factory.jms/MyQueueFactory.property.*

7.3.4. JMSサービスの統計情報取得

JMSサービスに関する統計情報の採取、および、取得方法について説明します。統計情報の取得に関する詳細は、 [ ドメイン構築・基本設定ガイド > 9. モニタリング ] を参照してください。

統合運用管理ツールからの操作

あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

1. 統合運用管理ツールよりドメインと接続します。
2. ツリービューより、「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「モニタリングサービス」-「モジュールモニタリングレベル」を選択します。
3. リストビューの「JMSサービス」属性に「ON」を設定し、「更新」ボタンをクリックします。この設定を行うことで、JMSサービスに関する統計情報の表示が可能になります。

   
   図7.3.4-1

4. ツリービューより、「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「統計情報」-「<ドメイン名>」-「JMSサービス」を選択します。リストビューの「統計属性」で統計情報を参照できます。
5. 物理的な送信先を登録している場合は、「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「統計情報」-「<ドメイン名>」-「JMSサービス」-「送信先名」-「<送信先名>」を選択することで、送信先に関する情報も参照できます。
6. 4の状態で、「統計情報採取開始」の操作を選択することにより、統計情報のグラフ表示を行うことができます。

   
   図7.3.4-2

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

1. otxadmin コマンドを起動し、ドメインにログインします。
2. 次のコマンドで、JMSサービスに関する統計情報の採取を開始します。

   otxadmin> set server.monitoring-service.module-monitoring-levels.jms-service=ON

3. 統計情報を参照するには、getコマンドに--monitor=trueオプションをつけて実行します。
   
   

   例) JMSサービスの統計情報を参照する場合

   otxadmin> get --monitor=true server.jms-service.*

   
   

   例) 送信先の統計情報を参照する場合

   otxadmin> get --monitor=true server.jms-service.jms-physical-destination.MyTopic.*

   
   

備考 ：

表示される情報の詳細については、[ リファレンス集 運用管理・設定編 > 3. モニタリング > 3.2. 採取可能なパフォーマンス情報 > JMSServiceStats 、JMSPhysicalDestinationStats ]を参照してください。

7.4. Transactionサービス

Transactionサービスに関する運用操作法について説明します。なお、各属性の説明については[ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.9. Transactionサービス > 1.9.3. Transactionサービスに関する設定 ]をご参照ください。

7.4.1. Transactionサービスの起動・停止

Transactionサービスの起動、および停止処理の手順について説明します。

7.4.1.1. 統合運用管理ツールから操作

1.  統合運用管理ツールよりドメインと接続します。

2.  ツリービューより「<ドメイン名>」−「アプリケーションサーバ」−「Transactionサービス」を選択し右クリックします。

3.  「Transactionの開始」を選ぶとTransactionサービスを開始します。逆に「Transactionサービスの停止」を選ぶとTransactionサービスを停止します。

図7.4.1.1-1

7.4.1.2. コマンドから操作

1.  otxadmin コマンドを起動し、ドメインにログインします。

2.  Transactionサービスを開始する場合は次のコマンドを実行します。

3.  逆にTransactionサービスを停止する場合は次のコマンドを実行します。

7.4.2. リソースの登録・削除

２フェーズコミットの途中で障害が発生した場合、Transactionサービスは、トランザクションのリカバリ処理を実行します。リカバリ処理で使用するデータベースやコネクタリソースの情報を、Transactionサービスのリソースとして定義します。ここでは、そのリソースの登録・削除操作の手順について説明します。

7.4.2.1. 統合運用管理ツールからリソース登録・削除

JDBCリソース、JCAリソース、C++ XAリソースの登録・削除を行う場合は、次の手順で操作を行ってください。JDBCリソースは、「JDBCデータソースのテスト」操作を行った時や、トランザクション実行時に自動的に生成されます。そのため、登録作業を省略することができます。

1.   統合運用管理ツールよりドメインと接続します。

2.   ツリービューより「<ドメイン名>」−「アプリケーションサーバ」−「Transactionサービス」−「リソース」を選択します。

3.   右クリックメニューより次のいずれかのオペレーションを実行します。

4.   表示された画面で、生成、または、削除するリソースの名前と、必要な情報を設定してください。設定内容の詳細は、[ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.9. Transactionサービス > 1.9.3. Transactionサービスに関する設定 ]を参照してください。

5.   自動生成されたJDBCリソースを表示するためには、「リソース」の「リソースの再表示」オペレーションを実行します。

また、AP用C++ XAリソースの登録・削除を行う場合は、次の手順で操作を行ってください。TransactionサービスとAPで同じC++ XAリソースを使用する場合は、AP用C++ XAリソースの登録作業を行う必要はありません。

1.  ツリービューより「<ドメイン名>」−「アプリケーションサーバ」−「Ｔｒａｎｓａｃｔｉｏｎサービス」−「リソース」−「cppxa-resource」−「C++XAリソース名」を選択します。

2.   右クリックメニューより次のいずれかのオペレーションを実行します。

3.   表示された画面で、生成、または、削除するリソースの名前と、必要な情報を設定してください。設定内容の詳細は、[ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.9. Transactionサービス > 1.9.3. Transactionサービスに関する設定 ]を参照してください。

7.4.2.2. コマンドからリソース登録・削除

1.   otxadmin コマンドを起動し、ドメインにログインします。

2.   リソースの登録、または、リソースの削除コマンドを実行します。

3.   自動生成されたリソースを表示します。

7.4.3. トランザクション一覧情報の取得操作

稼動中のトランザクション一覧情報を取得するための手順について説明します。

WebOTXでは、業務アプリケーションの稼動状態などの統計情報を採取する機能を提供しています。Transactionサービスに関しても、稼動中のトランザクション一覧や数、平均処理時間などの情報を採取し、表示する機能を提供しています。

ただし全ての統計情報を採取すると逆にトランザクション自体の性能劣化につながります。そのためTransactionサービスでは3つの情報採取レベルを用意し、レベルに応じて採取する情報の量を調整できるようにしています。詳しくは、[ リファレンス集 運用管理・設定編 > 3. モニタリング > 3.2. 採取可能なパフォーマンス情報 > JTAStats ]を参照してください。

なお、表示するトランザクション情報もそのレベルに応じて変わります。

7.4.3.1. トランザクション情報採取レベル

Transactionサービスで用意している3つの情報採取レベルにはOFF/LOW/HIGHの3つがあります。それらのレベルに応じて表示する稼動中のトランザクション情報が異なります。障害状態になっているトランザクションなど重要度が高いものについては設定されているレベルが低くても表示されるようになっています。

これらのレベルについては次の手順で参照することができます。

図7.4.3.1-1

統合運用管理ツールを用いたトランザクション情報採取レベルの参照

1.   統合運用管理ツールよりドメインと接続します。

2.   ツリービューより「<ドメイン名>」−「アプリケーションサーバ」−「Transactionサービス」−「Transaction情報」を選択すると右側に表示されます。

コマンドを用いたトランザクション情報採取レベルの参照

1.   otxadmin コマンドを起動し、ドメインにログインします。

2.   次のコマンドを実行します。0〜2の数字が戻り値として表示されます。

なお、「Transaction情報」（tstxlist）からトランザクション情報採取レベルを設定することはできません。設定については上の絵の中に書かれているように「モニタリングサービス」のところから実施する必要があります。詳細は[ リファレンス集 運用管理・設定編 > 3. モニタリング ]を参照してください。ここでは簡単に方法を記載します。

統合運用管理ツールを用いたトランザクション情報採取レベルの操作

1.   統合運用管理ツールよりドメインと接続します。

2.   ツリービューより「<ドメイン名>」−「アプリケーションサーバ」−「モニタリングサービス」−「モジュールモニタリングレベル」を選択します。

3.   右側に表示される項目のうち、「transactionserviceモニタリングレベル」のところにOFF/LOW/HIGHのいずれかを指定します。

コマンドを用いたトランザクション情報採取レベルの参照

1.   otxadmin コマンドを起動し、ドメインにログインします。

2.   次のコマンドのいずれかを実行します。’=’の後に「OFF」「LOW」「HIGH」のいずれかの文字列を指定します。

次に稼動中のトランザクション一覧の取得方法を記載します。

7.4.3.2. 統合運用管理ツールからトランザクション一覧の取得操作

1.   統合運用管理ツールよりドメインと接続します。

2.   ツリービューより「<ドメイン名>」−「アプリケーションサーバ」−「Transactionサービス」−「Transaction情報」を選択し右クリックします。

3.   「Transaction一覧取得」を選ぶとサーバに対して処理要求を実施します。

4.   「Transaction情報」ツリーの下に各トランザクション情報が表示されます。

7.4.3.3. コマンドからトランザクション一覧の取得操作

1.  otxadmin コマンドを起動し、ドメインにログインします。

2.   次のコマンドを実行します。

3.   2.で実行したコマンドはサーバから情報を取得しただけなので、一覧を表示させるにはさらに次のコマンドを実行します。

4.   3.を実行すると次のようにリスト表示されます。

7.4.4. トランザクションの操作

各トランザクションに対して強制的に完了操作を行うことができます。その手順について説明します。

7.4.4.1. 統合運用管理ツールから操作

1.   統合運用管理ツールよりドメインと接続します。

2.   ツリービューより「<ドメイン名>」−「アプリケーションサーバ」−「Transactionサービス」−「Transaction情報」−「<トランザクション識別子>(数字の部分)」を選択し右クリックします。右側にはトランザクションに関する情報が表示されます。

3.   該当するトランザクションに対して行いたい処理に応じてメニューを選択します。ただしトランザクションの状態に応じて実行可能なコマンドの種類は限定されますのでご注意ください。

図7.4.4.1-1

7.4.4.2. コマンドから操作

1.   otxadminコマンドを起動し、ドメインにログインします。

2.   次のコマンドを実施すると稼動中トランザクションの識別子一覧を見ることができます。

3.   次のコマンドを実行してトランザクションの完了処理を行うことができます。<トランザクション識別子>のところには2.のコマンドで指定したstxid相当の数字を指定します。

なお、強制削除を行うとトランザクションの継続処理を全く実施せずにトランザクション情報を削除してしまいますので、場合によってはトランザクション全体としての結果に矛盾が生じる場合があります。慎重に行ってください。

7.4.4.3. statsツリーからのトランザクションの操作

また、トランザクションの操作については、統合運用管理ツールの｢<ドメイン名>｣-｢統計情報」−「domain」−「トランザクションサービス」のところでも実施することができます。詳細については [ ドメイン構築・基本設定ガイド > 3. ドメイン > 3.9. 統計情報の取得 > 3.9.4. Transactionサービス（JTA）統計情報の取得 ] をご参照ください。

7.4.5. リソースの運用操作

登録・削除以外の、リソースの運用操作を行うための手順について説明します。

7.4.5.1. リソースの開始と停止

データベースサーバのメンテナンスを行う場合など、データベースサーバとのコネクションを切断する必要がある場合は、リソースの停止オペレーションを実行します。データベースサーバのメンテナンスが終わった場合は、リソースの開始オペレーションを実行し、トランザクションのリカバリ処理を行うことができる状態に戻します。

7.4.5.2. 統合運用管理ツールからリソースの開始と停止

1.   統合運用管理ツールよりドメインと接続します。

2.   ツリービューより次のいずれかを選択します。

3.   右クリックメニューより次のいずれかのオペレーションを実行します。

7.4.5.3. コマンドからリソースの開始と停止

1.   otxadmin コマンドを起動し、ドメインにログインします。

2.   リソースの開始、または、リソースの停止を実行します。

7.4.5.4. トランザクションの手動リカバリ操作

トランザクションのリカバリ操作は、通常、本マニュアルの[ 3. ドメイン > 3.9. 統計情報の取得 > 3.9.4. Transactionサービス（JTA）統計情報の取得 > 3.9.4.3. トランザクションの操作 ]の説明に従って実行します。ただし、まれにＤＢＭＳ間との状態不一致などによりトランザクションマネージャ側でトランザクションの結果を自動追跡できなくなる場合があります。そういう状態になった場合には、リソース毎にリカバリ操作を実行します。

なお、[ 3. ドメイン > 3.9. 統計情報の取得 > 3.9.4. Transactionサービス（JTA）統計情報の取得 > 3.9.4.3. トランザクションの操作 ]で表示されるトランザクションの情報は、リソース毎の操作では表示されません。

7.4.5.5. 統合運用管理ツールからトランザクションのリカバリ操作

1.   統合運用管理ツールよりドメインと接続します。

2.   ツリービューより次のいずれかを選択します。

3.   右クリックメニューより「トランザクションの一覧表示」オペレーションを実行します。

4.   「トランザクションの一覧表示」で表示された “ShortTxId”を指定して次のいずれかのオペレーションを実行します。

7.4.5.6. コマンドからトランザクションのリカバリ操作

1.   otxadmin コマンドを起動し、ドメインにログインします。

2.   トランザクションの一覧を表示します。

3.   トランザクションのリカバリ処理を実行します。

どの操作を行うかどうかについては、「トランザクションの一覧表示」で表示されたXidをキーにしてデータベース側のトランザクションの状態を確認した上で、決定してください。詳細は、各データベースのオンラインリファレンスを参照してください。

7.4.6. 1フェーズコミット対応リソースの2フェーズコミットへの参加

Transactionサービスは、X/Open分散トランザクション処理にしたがったデータベースへのアクセス、および更新をサポートしており、トランザクションマネージャとリソースマネージャとのやりとりにはXAインタフェースが使われます。

Transactionサービス内のリソースマネージャには、2フェーズコミットメントによるトランザクションの調整をサポートする「2フェーズコミット対応リソース」と、ローカルトランザクションのような1フェーズコミットメント調整だけをサポートする「1フェーズコミット対応リソース」の2種類が存在します。

例えば、ACOS上で管理されるデータベースのような2フェーズコミットメントをサポートしていないものへのアクセスにこの「1フェーズコミット対応リソース」を利用します。Transactionサービスでは、ACOS Access Toolkit(AAT)が提供するJDBCドライバと連携するための「1フェーズコミット対応リソース」を実装しており、それを使用することで、2フェーズコミットメントに対応していないACOS上のトランザクションをWebOTXシステムの2フェーズコミットトランザクションに参加できる機能を提供しています。 つまり同一のトランザクションで、ACOS上のデータベースと、Oracleなどオープンサーバ上のデータベースの同時更新を管理することができます。

7.4.6.1. フェーズコミット対応リソースを参加させるための準備

1フェーズコミット対応リソースをグローバルトランザクションに参加させる場合、JDBCデータソースに関する設定・登録が必要となります。登録の際にデータソースの種別（dataSourceType）に「JDBC API」を指定してください。リソースに対する運用操作については、リソースの種別に関わらず共通です。

JDBCデータソースに関する設定の詳細は、[ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.8. JDBCデータソース > 1.8.1. JDBCデータソース設定項目・設定方法 ]をご参照ください。また、AATとの連携のための準備についてもJDBCデータソースの章で掲載していますが、詳細はAATのマニュアルをご参照ください。

7.4.6.2. リソース混在時の注意事項

本来であれば、1つのグローバルトランザクション内で「2フェーズコミット対応リソース」と「1フェーズコミット対応リソース」を同時に参加させて、データの同時更新を行うことはできません。これは1フェーズコミット対応リソースが2フェーズコミットトランザクションに対応していないため、2フェーズコミットメントの第1段階(プリペア)を実行することができないからです。

WebOTXのTransactionサービスでは、上述のような混在を可能にする形態をサポートしています。ただしトランザクションの同時更新における一貫性を保証する関係上次のような構成上の制限をつけています。

・   1つのグローバルトランザクションに参加できる1フェーズコミット対応リソースは1つのみです。

・   伝播先トランザクションに1フェーズコミット対応リソースが参加している場合、伝播元(上位)のトランザクションに登録されているリソースが存在してはいけません。

（OKの場合その1）

図7.4.6.2-1

（OKの場合その2）

図7.4.6.2-2

（OKの場合その3）

図7.4.6.2-3

（OKの場合その4）

図7.4.6.2-4

（NGの場合その1）

図7.4.6.2-5

（NGの場合その2）

図7.4.6.2-6

（NGの場合その3）

図7.4.6.2-7

このような制限を設ける理由として、例えばApplication間でのトランザクション連携が別ベンダ製品を含む複数アプリケーションサーバをまたがって行われている場合が考えられます。互いのアプリケーションサーバで、それぞれ1フェーズコミット対応リソースが参加していてもそれを互いに認識するためのインタフェースが提供されているとは限らないからです。少なくともWebOTXのTransactionサービスにはそれを通知するための手段は提供していません。

このような構成でトランザクションのコミットを実施しようとすると失敗します。トランザクション全体としてはロールバックしTRANSACTION_ROLLEDBACK例外が返されます。

7.4.6.3. トランザクション完了時の処理の流れ

トランザクションのコミット時には、まず2フェーズコミット対応リソース群に対して第1段階(プリペア)要求を発行します。2フェーズコミット対応リソース群のうち1つでも異常終了した場合は、トランザクション全体をロールバックさせます。

逆に全ての2フェーズコミット対応リソースから正常終了が戻ってきたら1フェーズコミット対応リソースに対して、コミット要求を発行します。プリペア相当は存在しないため、このタイミングですぐにコミット処理となります。AATと連携する場合、ACOS側データベースに対してAATが提供するJDBCドライバを経由してコミット要求を発行します。これが正常に終了するとトランザクション全体はコミットします。すなわち2フェーズコミット対応リソース群に対してコミットを要求します。逆に異常終了すると2フェーズコミット対応リソース群に対してロールバックを発行します。

7.4.6.4. フェーズコミット対応リソースに対するコミット失敗時の流れ

1フェーズコミット対応リソースがグローバルトランザクションに参加するモデルの場合、本来であれば1フェーズコミットメントでの動作を前提としているものを、いわば無理やり2フェーズコミットトランザクションに参加させているため、トランザクション完了処理の際にヒューリスティックとなる可能性が高くなります。つまりトランザクション全体をコミットしていいのかロールバックしていいのかTransactionサービス(トランザクションマネージャ)で判断がつかなくなる状態となります。

例えばACOSとの通信障害、あるいはアプリケーションの異常終了などにより1フェーズコミット対応リソースに対するコミット要求が失敗すると上述のような状態に陥ります。

この場合、ACOS側には処理要求が届いておりデータ更新が正常にコミットされているかもしれません。そうであればトランザクション全体をコミットする必要があります。逆に、処理要求自体がACOS側に到達していない可能性もあります。そうであればトランザクション全体をロールバックして更新を無効にしてあげなければなりません。

その際の復旧処理は次のように行います。

（1）   データベースの更新状況の判断

（2）   該当するトランザクションの検索

（3）   該当するトランザクションへのコマンド発行

なお、トランザクション状態がStatusPreparingのものの一覧を表示させる場合、本マニュアルの[ 7.4.3. トランザクション一覧情報の取得操作 ]にあるように、トランザクションモニタレベルをHIGHにする必要があります。

7.4.7. クライアントアプリケーションの運用操作

クライアントアプリケーションにおいてもトランザクション機能を利用することができます。クライアントアプリケーションで利用するトランザクションを管理するためにProxy Recovery Coordination Server(以下Proxy RCS)、もしくは、リカバリサーバを利用する必要があります。ただし、EJBのクライアントであるアプリケーションクライアントではこれらのサーバは必要ありません。

Proxy RCSは統合運用管理ツールより起動することができます。詳細については、[ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.9. Transactionサービス > 1.9.3. Transactionサービスに関する設定 ]を参照してください。リカバリサーバはTS運用管理ツール、もしくは、サービス等から起動することができます。詳細については、 11.3. Transactionサービス (リカバリサーバ利用時) を参照してください。

なお、トランザクション機能を利用したクライアントアプリケーションのプログラミング方法については、 [ アプリケーション開発ガイド（CORBA） > 1. CORBA アプリケーション > 1.2. プログラミング・開発ガイド > 1.2.3. Transactionサービス ] の節を参照してください。

本節では、Proxy RCS、もしくは、リカバリサーバを利用するためのクライアント側の設定方法、及び、クライアントアプリケーションのトランザクションの動作トレースの採取の方法について説明します。

7.4.7.1. Proxy RCS、リカバリサーバを利用するための設定

Proxy RCS、もしくは、リカバリサーバを利用する際にはクライアントアプリケーション起動時にProxy RCS、もしくは、リカバリサーバのリファレンス(TransactionFactory)を取得する必要があります。このリファレンスは名前サーバに登録されています。このリファレンスを取得するためには以下のように設定します。

7.4.7.2. 設定内容

7.4.7.3. 設定方法

C++クライアントアプリケーションの場合)

Windows版：レジストリ(regeditで更新)\\HKEY_LOCAL_MACHINE\SOFTWARE\NEC\WebOTX_S\Client配下

UNIX版：/etc/WebOTX/TS/WebOTX_TS.confの[Client]セクション配下

Javaクライアントアプリケーションの場合)

クライアントアプリケーション起動時のシステムプロパティで指定する。(-D名前=値)

7.4.7.4. トレースを採取するための設定

クライアントアプリケーションのトランザクションの動作トレースの採取は以下の手順で行なえます。なお、EJBのアプリケーションクライアントに関しても同様の手順で採取できます。

1.   トレース採取方法設定ファイルを作成

2.   トレース採取方法設定ファイルの項目の設定

以下の項目を必要に応じて変更してください。

3.   クライアントアプリケーション起動時にトレース採取方法設定ファイルを指定して実行

なお、採取したトレースを参照するためには以下のツールを利用してください。

7.5. Working Domain Coordinator

Working Domain Coordinator に関する運用操作法について説明します。なお、各属性の説明については、[リファレンス集 運用管理・設定編 > 1.13. Working Domain Coordinator ]を参照してください。

7.5.1. Working Domain Coordinator の起動・停止

Working Domain Coordinator の起動、および停止処理の手順について説明します。

統合運用管理ツールから操作

あらかじめ、統合運用管理ツールより、Working Domain Coordinator の動作するドメインに接続しておきます。

1. ツリービューより「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「ワーキングドメインコーディネータ」を選択し、右クリックします。
2. 表示されるメニューから「Working Domain Coordinator の開始」を実行するとWorking Domain Coordinator を開始します。
   Working Domain Coordinator の開始を行うと、負荷分散制御機能が開始されます。また、制御対象サーバのデフォルトドメイン名が設定されており、かつ、他に起動しているドメインがない場合は、設定したデフォルトドメインが起動されます。
3. 「Working Domain Coordinator の停止」を実行するとWorking Domain Coordinator を停止します。
   Working Domain Coordinator の停止を行うと、負荷分散制御機能が停止されます。起動しているドメインの停止は行われません。

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、Working Domain Coordinator の動作するドメインにログインしておきます。

1. Working Domain Coordinator を開始する場合は次のコマンドを実行します。

   otxadmin> start-working-domain-coordinator

   
   コマンドの詳細については、運用管理コマンドリファレンスの「start-working-domain-coordinator」を参照してください。
   
   
   
2. 逆にWorking Domain Coordinator を停止する場合は次のコマンドを実行します。

   otxadmin> stop-working-domain-coordinator

   
   コマンドの詳細については、運用管理コマンドリファレンスの「stop-working-domain-coordinator」を参照してください。

7.5.2. ビジネスロジックグループの登録・削除

ビジネスロジックグループは、各ドメイン内で稼動し、監視の対象となるビジネスロジック(プロセスグループ)の論理的な集まりです。Working Domain Coordinatorはこのビジネスロジックグループを単位に負荷の監視、およびビジネスロジックの切り替えを行います。
ビジネスロジックグループの登録、および、削除の手順について説明します。

統合運用管理ツールから操作

あらかじめ、統合運用管理ツールより、Working Domain Coordinator の動作するドメインに接続しておきます。

1. ツリービューより「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「ワーキングドメインコーディネータ」-「ビジネスロジックグループ」を選択し、右クリックします。
2. 登録を行う場合は、「ビジネスロジックグループの登録」を選び、表示された画面で、ビジネスロジックグループの名前、および必要な情報を設定してください。設定内容の詳細は、 [ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.13. Working Domain Coordinator ] を参照してください。
3. 削除を行う場合は、ツリービューに表示されている削除対象のビジネスロジックグループを右クリックします。表示された右クリックメニューの「ビジネスロジックグループの削除」を選択してください。また、ツリービューに表示されている「ビジネスロジックグループ」の右クリックメニューの「ビジネスロジックグループの削除」を選び、表示された画面でビジネスロジックグループ名を指定し削除することもできます。

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、Working Domain Coordinator の動作するドメインにログインしておきます。

1. ビジネスロジックグループの登録、または、ビジネスロジックグループの削除コマンドを実行します。
   

   ビジネスロジックグループの登録

   otxadmin> create-wdc-controlled-business-logic-group --maxQueuingRequests キュー滞留数上限値 ビジネスロジックグループ名

   
   コマンドの詳細については、運用管理コマンドリファレンスの「create-wdc-controlled-business-logic-group」を参照してください。
   
   

   ビジネスロジックグループの削除

   otxadmin> delete-wdc-controlled-business-logic-group ビジネスロジックグループ名

   
   コマンドの詳細については、運用管理コマンドリファレンスの「delete-wdc-controlled-business-logic-group」を参照してください。

7.5.3. ビジネスロジックの登録・削除

ビジネスロジックは、業務が動作するプロセスグループが該当します。
ビジネスロジックの登録、および削除の手順について説明します。

統合運用管理ツールから操作

あらかじめ、統合運用管理ツールより、Working Domain Coordinator の動作するドメインに接続しておきます。

1. ツリービューより「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「ワーキングドメインコーディネータ」-「ビジネスロジックグループ」-「<ビジネスロジックグループ名>」-「ビジネスロジック」を選択し、右クリックします。
2. 登録を行う場合は、「ビジネスロジックの登録」を選び、表示された画面で、対象のビジネスロジックの配備されているプロセスグループ名を設定してください。
3. 削除を行う場合は、ツリービューに表示されている削除対象のビジネスロジックを右クリックします。表示された右クリックメニューの「ビジネスロジックの削除」を選択してください。また、ツリービューに表示されている「ビジネスロジック」の右クリックメニューの「ビジネスロジックの削除」を選び、表示された画面でビジネスロジック名を指定し削除することもできます。

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、Working Domain Coordinator の動作するドメインにログインしておきます。

1. ビジネスロジックの登録、または、ビジネスロジックの削除コマンドを実行します。
   

   ビジネスロジックの登録

   otxadmin> create-wdc-controlled-business-logic --businessLogicGroupName ビジネスロジックグループ名 ビジネスロジック名

   
   コマンドの詳細については、運用管理コマンドリファレンスの「create-wdc-controlled-business-logic」を参照してください。
   
   

   ビジネスロジックの削除

   otxadmin> delete-wdc-controlled-business-logic --businessLogicGroupName ビジネスロジックグループ名 ビジネスロジック名

   
   コマンドの詳細については、運用管理コマンドリファレンスの「delete-wdc-controlled-business-logic」を参照してください。

7.5.4. ロードバランサの登録・削除

ロードバランサは、業務の負荷を分散する負荷分散装置を表します。
ロードバランサの登録、および削除の手順について説明します。

統合運用管理ツールから操作

あらかじめ、統合運用管理ツールより、Working Domain Coordinator の動作するドメインに接続しておきます。

1. ツリービューより「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「ワーキングドメインコーディネータ」-「ロードバランサ」を選択し、右クリックします。
2. 登録を行う場合は、「ロードバランサの登録」を選び、表示された画面で、ロードバランサの名前、および必要な情報を設定してください。設定内容の詳細は、 [ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.13. Working Domain Coordinator ] を参照してください。
3. 削除を行う場合は、ツリービューに表示されている削除対象のロードバランサを右クリックします。表示された右クリックメニューの「ロードバランサの削除」を選択してください。また、ツリービューに表示されている「ロードバランサ」の右クリックメニューの「ロードバランサの削除」を選び、表示された画面でロードバランサ名を指定し削除することもできます。

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、Working Domain Coordinator の動作するドメインにログインしておきます。

1. ロードバランサの登録、または、ロードバランサの削除コマンドを実行します。
   

   ロードバランサの登録

   otxadmin> create-wdc-loadbalancer --lbHostName ロードバランサのホスト名 ロードバランサ名

   
   コマンドの詳細については、運用管理コマンドリファレンスの「create-wdc-loadbalancer」を参照してください。
   
   

   ロードバランサの削除

   otxadmin> delete-wdc-loadbalancer ロードバランサ名

   
   コマンドの詳細については、運用管理コマンドリファレンスの「delete-wdc-loadbalancer」を参照してください。

7.5.5. 制御対象サーバの登録・削除

制御対象サーバは、WebOTX ASが稼動しているサーバのうち、Working Domain Coordinatorの負荷分散制御の対象となるサーバを表します。
制御対象サーバの登録、および削除の手順について説明します。

統合運用管理ツールから操作

あらかじめ、統合運用管理ツールより、Working Domain Coordinator の動作するドメインに接続しておきます。

1. ツリービューより「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「ワーキングドメインコーディネータ」-「制御対象サーバ」を選択し、右クリックします。
2. 登録を行う場合は、「制御対象サーバの登録」を選び、表示された画面で、制御対象サーバの名前、および必要な情報を設定してください。設定内容の詳細は、 [ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.13. Working Domain Coordinator ] を参照してください。
3. 削除を行う場合は、ツリービューに表示されている削除対象の制御対象サーバを右クリックします。表示された右クリックメニューの「制御対象サーバの削除」を選択してください。また、ツリービューに表示されている「制御対象サーバ」の右クリックメニューの「制御対象サーバの削除」を選び、表示された画面で制御対象サーバ名を指定し削除することもできます。

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、Working Domain Coordinator の動作するドメインにログインしておきます。

1. 制御対象サーバの登録、または、制御対象サーバの削除コマンドを実行します。
   

   制御対象サーバの登録

   otxadmin> create-wdc-controlled-server --jmxAdminRemoteURL 管理ドメインのJMX Remote URL 制御対象サーバ名

   
   コマンドの詳細については、運用管理コマンドリファレンスの「create-wdc-controlled-server」を参照してください。
   
   

   制御対象サーバの削除

   otxadmin> delete-wdc-controlled-server 制御対象サーバ名

   
   コマンドの詳細については、運用管理コマンドリファレンスの「delete-wdc-controlled-server」を参照してください。

7.5.6. 制御対象ドメインの登録・削除

制御対象ドメインは、WebOTX ASが稼動しているサーバのドメインのうち、Working Domain Coordinatorの負荷分散制御の対象となるドメインを表します。
制御対象ドメインの登録、および削除の手順について説明します。

統合運用管理ツールから操作

あらかじめ、統合運用管理ツールより、Working Domain Coordinator の動作するドメインに接続しておきます。

1. ツリービューより「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「ワーキングドメインコーディネータ」-「制御対象サーバ」-「<制御対象サーバ名>」-「制御対象ドメイン」を選択し、右クリックします。
2. 登録を行う場合は、「制御対象ドメインの登録」を選び、表示された画面で、制御対象ドメインの名前、および必要な情報を設定してください。設定内容の詳細は、 [ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.13. Working Domain Coordinator ] を参照してください。
3. 削除を行う場合は、ツリービューに表示されている削除対象の制御対象ドメインを右クリックします。表示された右クリックメニューの「制御対象ドメインの削除」を選択してください。また、ツリービューに表示されている「制御対象ドメイン」の右クリックメニューの「制御対象ドメインの削除」を選び、表示された画面で制御対象ドメイン名を指定し削除することもできます。

運用管理コマンド(otxadmin)からの操作

あらかじめ、otxadminコマンドを起動し、Working Domain Coordinator の動作するドメインにログインしておきます。

1. 制御対象ドメインの登録、または、制御対象ドメインの削除コマンドを実行します。
   

   制御対象ドメインの登録

   otxadmin> create-wdc-controlled-domain --controlledServerName 制御対象サーバ名 --jmxRemoteURL 制御対象ドメインのJMX Remote URL --businessLogicGroupName ビジネスロジックグループ名 制御対象ドメイン名

   
   コマンドの詳細については、運用管理コマンドリファレンスの「create-wdc-controlled-domain」を参照してください。
   
   

   制御対象ドメインの削除

   otxadmin> delete-wdc-controlled-domain --controlledServerName 制御対象サーバ名 制御対象ドメイン名

   
   コマンドの詳細については、運用管理コマンドリファレンスの「delete-wdc-controlled-domain」を参照してください。