7. WebOTXの内部サービス

7.1. TPシステム

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

表7.1-1
メニュー V6.3以降 V5
起動 CTRL+S F7
停止 CTRL+T Shift+F7
強制停止 CTRL+F -
削除 DEL Del
モジュールの活性化 CTRL+E -
モジュールの閉塞 CTRL+D -
新規作成 CTRL+N Ctrl+N

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

7.1.1.1. 設定の変更

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

PropertyChange
図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.2-1
タブ表記 新項目名(V9) 旧項目名(V8) 説明 新既定値(V9) 旧既定値(V8)
システムパラメータ/静的情報 最大オペレーション数
TPシステムで作成できるオペレーション数の最大値を設定をします。この設定の変更はTPシステム起動時に行うとエラーになります。 既に作成してあるオペレーションの数よりも少ない値にする事はできません。 この数値はファクトリオペレーションとWebOTX Application Server内部オペレーション(1システムで5+プロセスグループ×7)も含んだ数にする必要があります。

10000 Standard:200, Enterprise:1000
システムパラメータ/静的情報 最大コンポーネント数
TPシステムに登録できるコンポーネント数の最大値を設定します。この設定の変更はTPシステム起動時に行うとエラーになります。

1000 Standard:200, Enterprise:1000
システムパラメータ/静的情報 最大インターフェース数
TPシステムで登録できるインターフェース数の最大値を設定をします。この設定の変更はTPシステム起動時に行うとエラーになります。

2000 Standard:200, Enterprise:1000
システムパラメータ/動的情報 最大プロセス数
TPシステムで作成できるプロセス数の最大値を設定をします。この設定の変更はTPシステム起動時に行うとエラーになります。 既に作成してあるプロセスの数よりも少ない値にする事はできません。

100 Standard:20, Enterprise:100
システムパラメータ/動的情報 最大スレッド数
TPシステムで作成できるスレッド数の最大値を設定します。この設定の変更はTPシステム起動時に行うとエラーになります。 既に設定してあるスレッドの数よりも少ない値にする事はできません。また、TPシステム内の全プロセスグループの合計スレッド数よりも大きな値を設定する必要があります。 プロセスグループの各プロセスではスレッド数の設定で指定したスレッドの他にWebOTX Application Serverが内部で使用する3つのスレッドが動作するため、 1つのプロセスグループで動作するスレッドの総数は、プロセス数*(スレッド数+予備スレッド数+3)となることに注意してください。

300 200
システムパラメータ/動的情報 送受信用共有メモリサイズ メモリプールサイズ
送受信用共有メモリのサイズを設定します。この設定は同時に実行できるリクエスト数や電文のサイズに影響し、不足すると全てのリクエスト処理がエラーとなります。 この設定の変更はTPシステム起動時に行うとエラーになります。

Windows(x86):32MB, それ以外:128MB
上限設定 プロセス障害時の再起動回数
例外などでプロセスが異常終了したとき、自動的にプロセスを再起動させる回数を1〜55000の整数で指定します。 1を設定の場合、再起動は行わずすぐにプロセスグループが停止します。 全てのプロセスグループに対してこの設定は有効となります。

5回
上限設定 プロセスを正常と仮定する間隔
プロセス正常と仮定しプロセス再起動回数をリセットするための間隔を秒単位で指定します。 この時間内にプロセスの異常終了が起こらなかった場合、そのプロセスは正常とみなされ、再起動回数はクリアされます。 -1を指定した場合は、間隔は無制限とします。 上記再起動回数だけ再起動を終えるとプロセス再起動は行いません。 全てのプロセスグループに対してこの設定は有効となります。

3600秒
上限設定 オペレーションの再試行回数 オペレーション再試行回数
オペレーションの再試行回数を設定します。データベースのデッドロックの発生など、再試行が可能な障害が発生した場合に、APIを通してプロセスグループから再試行の指示があると、 この設定で指定した回数を上限としてオペレーションを再試行します。-1を指定すると無限に再試行します。 再試行回数がこの設定値を超えた場合は、オペレーションの実行は失敗します。

-1
上限設定 プロセスのストール監視間隔
プロセスの初期化処理または終了処理のタイムアウト時間を設定します。プロセスの初期化・停止処理に長時間かかる場合、もしくはプロセスの初期化・停止処理に無応答となる異常を検知したい場合は、この設定を変更してください。この設定の変更はTPシステム起動時に行うとエラーになります。プロセスグループの属性"スレッドの初期化時間の上限"で設定した時間はこの時間に含まれません。設定値がTPシステムの属性"プロセスを正常と仮定する間隔"より長い場合、TPシステムの属性で指定した"プロセス障害時の再起動回数"に関係なく無限ループします。また、オペレーションが通常でも長時間の場合(DBアクセス等)は、APループの値を極端に短くすると意図せずオペレーションが中断します。

600秒
上限設定 送受信用共有メモリ使用量の閾値 メモリプールサイズの閾値
送受信用共有メモリ使用量を監視し、警告を出す閾値を設定します。送受信用共有メモリ使用量が設定した閾値を超えた場合、イベントログ・シスログにWARNINGレベルで警告メッセージを出力します。0を指定した場合はメッセージを出力しません。この設定の変更はTPシステム起動時に行うとエラーになります。

90%
上限設定 送受信用共有メモリサイズの閾値を超えてから次の警告を出すまでの時間 メモリプールサイズの閾値を超えてから次の警告を出すまでの時間 送受信用共有メモリサイズの閾値を超えてから次の警告を出すまでの時間を設定します。この設定の変更はTPシステム起動時に行うとエラーになります。 3600秒
クライアント制御 TCPレイヤーのアライブチェックを行う TCPレベルでのアライブチェックを行う
OSのkeepaliveの機能を使って、TCPレイヤーでクライアントのアライブチェックを行う機能を有効にするかどうかを設定します。この機能はクライアントのアボートにより無効となってしまったセッションをクリアする場合に利用します。特に連続運用をする場合は設定が必要です。この機能はOSに依存した機能のため、keepaliveの間隔はOSで設定した値が適用されます。WebOTX Application ServerがWebサーバと通信を行う構成の場合は、本説明中のクライアントはWebサーバになることに注意してください。運用管理コマンド(otxadmin)では「TCPレイヤーのアライブチェックを行う/行わない」をtrue/falseで設定します。

アライブチェックを行う(true)
システム情報 接続サーバ名
クライアント(Webサーバ)がWebOTXに接続するときに利用するサーバ名を127文字以内で指定します。 サーバ名にはホスト名、IPアドレス、ドメイン付きホスト名のどれかを指定してください。 クライアント側で実際にこの名前を用いてセッションの接続を行います。Javaアプリケーションでは、プロセスグループ起動時のJavaシステムプロパティ ExternalHostNameのホスト名としても利用します。 よってクライアント側で認識できる名前を指定してください。

自ホスト名
システム情報 システム名
TPシステムの名前です。 ドメイン作成時に設定した名前は変更することはできません。

-
システム情報 システムID
システムIDを設定します。システムIDはドメイン間で一意になるように設定してください。この設定の変更はTPシステム起動時に行うとエラーになります。 この設定値は共有メモリの識別やラウンドロビン設定時のIDに使用されます。

-
システム情報 名前サーバのホスト名 名前サーバホスト名
オブジェクトリファレンスを登録する名前サーバのホスト名を127文字以内で指定します。ホスト名、IPアドレス、またはドメイン付きホスト名のいずれかで指定してください。 別のサーバに構築した名前サーバを使用する場合に設定を変更します。 アプリケーションで名前サーバへ登録を実行すると、ここで指定した名前サーバにオブジェクトリファレンスを登録します。

自ホスト名
システム情報 名前サーバのポート番号 名前サーバポート番号
オブジェクトリファレンスを登録する名前サーバのポート番号を設定します。異なるドメインまたはサーバに構築した名前サーバを使用する場合に設定を変更します。 0を指定した場合は、本ドメインで定義している名前サーバのポート番号を使用します。

0
システム情報 CORBAエラーの詳細化を行う CORBAエラーの詳細化
クライアントに返却するCORBAのエラーを詳細形式にするかどうかを設定します。運用管理コマンド(otxadmin)では「CORBAエラーの詳細化を行う/行わない」をtrue/falseで設定します。

詳細にする(true)
システム情報 IPv6優先
IPv6を優先的に使用します。この設定の変更はTPシステムの再起動が必要になり、プロセスグループ起動時の動作も連動して変わります。ドメインのIPv6の設定(IPv6優先:ipv6-enable)と連動します。

IPv4優先(false)
システム情報 10MB以上の電文を使用する 10MB以上の電文を利用する
10MB以上の電文を使用するかどうかを指定します。有効にした場合は、メモリプールサイズの値の調整が必要です。この設定の変更はTPシステム起動時に行うとエラーになります。運用管理コマンド(otxadmin)では「10MB以上の電文を使用する/しない」をtrue/falseで設定します。

使用する(true)
システム情報 デフォルトWebモジュールの管理名
デフォルトWebモジュールの管理名を設定します。配備したWebアプリケーションのコンテキストルートが「/」に設定されている場合に、 この値を統計情報やアプリケーションの構成情報を変更する際に使用する管理名として使用します。 変更を反映するには該当Webアプリケーションを再配備する必要があります。

otx-default-web-module
システム情報 オペレーション実行中の停止操作をエラーとする オペレーション実行中の停止をエラーとする
オペレーション実行中はモジュールの停止や配備解除など停止を伴う操作をエラーにするかどうかを指定します。配備解除など停止を伴う動作時と平行してオペレーションが実行される環境や、 すぐに完了するオペレーションを連続実行する環境では設定を有効にしないでください。 運用管理コマンド(otxadmin)では「オペレーション実行中の停止操作をエラーとする/しない」をtrue/falseで設定します。

エラーにしない(false)
システム情報 Coreファイルの出力先 -
Unixの場合に、Coreの出力先をAgentプロセスと異なるディレクトリにするかを指定します。 Windowsでは本設定の値にかかわらず、OSの指定した出力先に固定されます。 Unixでは設定を有効にしている場合、以下のディレクトリにcoreファイルが出力されます。
${Instanceroot}/logs/tpsystem
運用管理コマンド(otxadmin)では「Coreファイルの出力先をAgentプロセスと異なるディレクトリにする/しない」をtrue/falseで設定します。

する(true) -
システム情報 TPモニタのログを採取する -
TPモニタのログを採取するかどうかを指定します。 ログは以下のパスに固定で出力されます。
${Instanceroot}/logs/tpsystem/tpmonitor.trc
運用管理コマンド(otxadmin)では「TPモニタのログを採取する/しない」をtrue/falseで設定します。

ログを採取しない(false) -
システム情報 TPAのログを採取する -
TPAのログを採取するかどうかを指定します。 ログは以下のパスに固定で出力されます。
${Instanceroot}/logs/tpsystem/tpadmd.trc
運用管理コマンド(otxadmin)では「TPAのログを採取する/しない」をtrue/falseで設定します。

ログを採取しない(false) -
システム情報 TPA受信タイムアウト -
TPAからの応答を受信する際のタイムアウト時間を指定します。 TPA受信、停止時のタイムアウト値を1以上の整数で設定してください。指定した時間以内に応答ない場合、エラーが出力されます。

120秒 -
システム情報 TPモニタのログの最大ライン数 -
TPモニタのログの最大行数を指定します。この設定の変更はTPシステム起動時に行うとエラーになります。ログが指定ラインに達したら再帰出力を行います。

100000行 -
システム情報 TPAのログの最大ライン数 -
TPAのログの最大行数を指定します。この設定の変更はTPシステム起動時に行うとエラーになります。ログが指定ラインに達したら再帰出力を行います。

100000行 -
オペレーション制御 重み付けオペレーション優先度制御
重み付けラウンドロビン方式でオペレーションの優先度制御を行います。 0-5の範囲で指定します。省略時の既定値は0となります。 重みは同じ優先度のオペレーションの繰返し数で指定します。 ある優先度のオペレーションが指定回数実行されていれば、まだ同じ優先度のオペレーションが存在しても次の優先度のオペレーションを実行します。 このような制御を各優先度に対して順番に繰返します。 数が大きいほうが、優先度の高いオペレーションを多く実行します。 0が指定された場合、重み付けラウンドロビン方式での制御を行いません。ある優先度のオペレーションの滞留が全て無くなってから、次の優先度のオペレーションを実行します。

0
オペレーション制御 オペレーションの統計情報を採取しない
オペレーションの統計情報を採取するかどうかを指定します。オペレーションの統計情報を採取することで、統計情報の表示、監視や運用アシスタントによるオペレーションの監視を行うことができます。 採取する場合は無効(false)、採取しない場合は有効(true)を設定してください。 統計情報を採取しない場合は、コマンドもしくはツールで運用アシスタントを使用しないようにTPシステムのプロパティを変更して下さい。 これにより運用アシスタントの機能を使用できなくなります。変更はドメイン再起動後に有効になります。 運用管理コマンド(otxadmin)では「オペレーションの統計情報を採取しない/する」をtrue/falseで設定します。

採取する(false)
オペレーション制御 例外時のダンプ採取 -
例外発生時にダンプを採取するかどうかを指定します。「採取する」指定時、例外ハンドルの指定に関係なく、例外時のダンプファイル採取が可能です。運用管理コマンド(otxadmin)では「例外時のダンプ採取をする/しない」をtrue/falseで設定します。

採取する(true) -
オペレーション制御 例外時のダンプ出力世代数 -
例外発生時に出力するダンプファイルの世代数を指定します。-1を指定した場合、無制限となります。

10 -
起動/停止 起動タイムアウト
システム起動タイムアウトの設定を秒単位で指定します。 指定した時間以内に起動要求が完了しない場合、起動要求はタイムアウトします。 ただし起動処理はタイムアウトした後も行いますのでタイムアウトした後に起動が完了する場合があります。 タイムアウトした場合は状態を確認してください。

120秒
起動/停止 停止タイムアウト
システム停止タイムアウトの設定を秒単位で指定します。 指定した時間以内に停止要求が完了しない場合、停止要求はタイムアウトします。 ただし停止処理はタイムアウトした後も行いますのでタイムアウトした後に停止が完了する場合があります。 タイムアウトした場合は状態を確認してください。

120秒
起動/停止 プロセス停止時の終了処理を行う プロセスを即時停止する
プロセスの停止時に停止処理を行わずに即時停止するかどうかを指定します。 プロセスグループの後処理ではログ採取を行っているため、即時停止すると障害解析が困難になる可能性がありますのでご注意下さい。 この設定の変更はTPシステム起動時に行うとエラーになります。 プロセスを即時停止する場合、アプリケーショングループ、プロセスグループ、アプリケーション停止時の後処理をおこなわないため、停止時間が短縮されます。 運用管理コマンド(otxadmin)では「プロセス停止時の終了処理を行う/行わない」をtrue/falseで設定します。

即時停止しない(false)
起動/停止 アプリケーショングループの起動間隔
アプリケーショングループの起動間隔を指定します。 複数アプリケーションが同時に起動することにより、一時的なリソース不足になる場合は、本指定で起動間隔の調整を行ってください。自動起動時は<アプリケーショングループ数>*<設定された間隔>で起動されます。合計値が「起動タイムアウト」に設定されている値より上回る値を設定しないでください。

0秒
イベントジャーナル イベントジャーナルの採取機能を有効にする イベントジャーナルを採取する
障害解析に有効な内部情報(イベントジャーナル)を採取するかどうかを設定します。この設定の変更はTPシステム起動時に行うとエラーになります。 オペレーションの実行の過程で起きる障害については、イベントジャーナルを追っていくことで、どこで障害が発生しているか調べることができます。 また、イベントジャーナルではクライアントからの受信開始から応答の送信終了までを確認できるため、障害箇所がサーバ側なのかそうではないのか(ネットワークやクライアント側なのか)を切り分けることができます。 運用管理コマンド(otxadmin)では「イベントジャーナルの採取機能を有効にする/無効にする」をtrue/falseで設定します。

有効にする(true)
イベントジャーナル イベントジャーナルの詳細化を行う イベントジャーナルの簡易採取を行う
イベントジャーナルで採取する情報を詳細形式にするかどうかを設定します。イベントジャーナルの採取時間やCPU使用率を減らしたい場合は本機能を無効にしてください。 運用管理コマンド(otxadmin)では「イベントジャーナルの詳細化を行う/行わない」をtrue/falseで設定します。

詳細にしない(false)
イベントジャーナル ファイルサイズ
イベントジャーナルの採取情報を保存するファイルのサイズを2以上の整数で設定します。イベントジャーナルを多く採取したい場合はこのサイズを増やしてください。 この設定の変更はTPシステム起動時に行うとエラーになります。 イベントジャーナルはこのファイルサイズで上書き保存されます。

10MB
イベントジャーナル バックアップファイル数
イベントジャーナルの採取情報を保存するファイルのバックアップ数を0以上の整数で設定します。0を指定した場合は、同一のファイルにファイルサイズ以内で上書きで保存します。 この設定の変更はTPシステム起動時に行うとエラーになります。イベントジャーナルはこのファイル数で上書き保存されます。

0
イベントジャーナル 出力ファイルの最大行数
イベントジャーナルを出力するファイルの行数の上限を7〜2147483647の整数で設定します。 イベントジャーナルは[採取したイベントジャーナルの編集(editEventJournal)]オペレーションを実行すると、この行数を上限として複数のファイルに分割されて出力されます。 出力ファイル名は(システム名)_woejout(数字).logとなります。

30000行
ジャーナルの設定 ジャーナルの採取機能を有効にする ジャーナルを採取する
性能および統計情報(ジャーナル)を採取するかどうかを設定します。この設定の変更はTPシステム起動時に行うとエラーになります。 ジャーナルはWebOTXの稼働状況を評価するための性能及び統計情報を各種レポートとして提供します。 運用管理コマンド(otxadmin)では「ジャーナルの採取機能を有効にする/無効にする」をtrue/falseで設定します。

有効にする(true)
ジャーナルの設定 ファイルサイズ
ジャーナルの採取情報を保存するファイルのサイズを1〜1000の整数で設定します。 ジャーナルはこのファイルサイズで上書き保存されます。 この設定の変更はTPシステム起動時であっても行えますが、反映するためにはシステムを再起動する必要があります。

10MB
例外ハンドル WebOTXで例外処理を行う 例外ハンドルを行う
例外発生時(OSからのシグナル受信時)に、WebOTXで例外処理を行うかどうかを設定します。OSのデバック情報(Windows環境でのワトソンログやUNIX環境でのcoreファイル)を出力させる場合は無効にします。 この設定は、言語がJava以外のプロセスグループのみ有効です。運用管理コマンド(otxadmin)では「例外処理を行う/行わない」をtrue/falseで設定します。

例外処理を行う(true)
WatchServer WatchServerを使用する
WatchServerを使用するかどうかの設定を行います。有効にした場合、「名前サーバのホスト名」で設定したサーバのWatchServerに対してオブジェクトリファレンスの登録・削除処理を行います。 運用管理コマンド(otxadmin)では「WatchServer を使用する/しない」をtrue/falseで設定します。

使用しない(false)
WatchServer WatchServerホスト名 -
WatchServerが動作するホスト名を指定します。省略した場合は、名前サーバのホスト名と同じ値で動作します。

-
WatchServer WatchServerポート番号 -
WatchServerのポート番号を指定します。

5190 -
状態 状態
TPシステムの起動状態です。
システムの状態を表示します。 状態と数値は以下の通りに対応します。
0:起動処理中
1:起動中
2:停止処理中
3:停止中
4:起動/停止処理失敗

-
状態 TPシステムを監視する アライブチェックモニタの自動登録を行う TPシステムを定期的に監視するかどうかを設定します。運用管理コマンド(otxadmin)では「TPシステムを監視する/しない」をtrue/falseで設定します。
監視する(true)
状態 TPシステムの監視間隔 監視間隔
TPシステムを監視する間隔を設定します。

30000ミリ秒
状態 非アライブ状態の際にイベントを発生させる間隔 イベントを連続発生させる間隔
監視対象リソースがアライブ中でない状態が続く場合にイベントを発生させる間隔を設定します。0を設定した場合イベントを発生しません。

0ミリ秒
状態 現在の総コンポーネント数 現在のコンポーネント数
現在のコンポーネントの総数を表示します。

-
状態 現在の総インタフェース数 現在のインターフェース数
現在のインタフェースの総数を表示します。

-
状態 現在の総オペレーション数 現在のオペレーション数
システムに登録されているオペレーション数を表示します。 この数値はファクトリオペレーションとWebOTX Application Server内部オペレーション(1システムで5+プロセスグループ×6(プロセスグループの種類がJ2EE、CORBA Javaの場合7))を含みます。

-
状態 現在の総プロセス数 現在のプロセス数
現在のプロセスの総数を表示します。

-
状態 現在の総スレッド数 現在のスレッド数
現在のスレッドの総数を表示します。 プロセスグループ内のプロセスごとにWebOTX Application Server内部で使用するスレッドが3つあるため、各プロセスグループで使用するスレッド数は設定したスレッド数+予備スレッド数+3×プロセス数となります。

-
運用アシスタント 最終情報採取時刻
運用アシスタント機能が最後にTPシステムの稼動情報を採取した時間を表示します。

-
運用アシスタント 稼働情報の採取と設定更新の間隔 情報採取間隔
TPシステムの稼働情報採取と、設定値の自動更新の間隔を設定します。ここで設定した時間を経過するたびにTPシステムの情報を採取し、自動更新の設定に応じて多重度や実行時間の上限の推奨値算出および設定を行います。ここで設定された値はオペレーションジャーナルの最小編集単位となります。

5分
運用アシスタント 実行時間の上限の推奨値の最小値 実行時間上限推奨値の最小値 実行時間の上限として運用アシスタントが算出する推奨値の最小値を設定します。ここで設定した値より小さな値が算出された場合、推奨値には設定されません。 60秒
運用アシスタント 多重度最適化支援機能で動的変更するプロセス数の最大値 最大マルチプロセス数
多重度最適化支援機能で変更するプロセス数の最大値を設定します。運用アシスタントは、この値を超えてプロセスグループのプロセス多重度を設定することはありません。

5
運用アシスタント スローダウン監視機能 -
スローダウンを監視する機能を選択します。 WebOTXversion8.xとの互換を設定する場合、「運用アシスタント機能を使用する」を選択してください。
0: フェイルセーフ機能を使用する
1: 運用アシスタント機能を使用する(V8互換機能)
2: スローダウンを監視しない

フェイルセーフ機能を使用する -
運用アシスタント スタックトレース採取回数 -
スローダウン、長期スローダウン発生時にスタックトレースを採取する回数を設定します。

3回 -
システムパラメータ history.actの1ファイルあたりの最大行数 history.actの最大ライン数
history.actの1ファイルあたりの最大行数を設定します。この設定の変更はTPシステム起動時に行うとエラーになります。ログが指定行数に達すると上書きで出力を行います。世代数を2以上の値に設定している場合は、世代数が設定値に達すると古いファイルから上書き出力が行われます。

10000行
システムパラメータ history.actのバックアップ世代数 history.actの世代数
history.actのバックアップの世代数を設定します。この設定の変更はTPシステム起動時に行うとエラーになります。history.actの出力が指定行数に到達するかTPシステムが起動した時にバックアップが作成され、設定値まで世代切り替えを行います。

10
システムパラメータ sysmsg.trcの1ファイルあたりの最大行数 sysmsg.trcの最大ライン数
sysmsg.trcの1ファイルあたりの最大行数を設定します。この設定の変更はTPシステム起動時に行うとエラーになります。ログが指定行数に達すると上書きで出力を行います。世代数を2以上の値に設定している場合は、世代数が設定値に達すると古いファイルから上書き出力が行われます。

10000行
システムパラメータ sysmsg.trcのバックアップ世代数 sysmsg.trcの世代数
sysmsg.trcのバックアップの世代数を設定します。この設定の変更はTPシステム起動時に行うとエラーになります。sysmsg.trcの出力が指定行数に到達するかTPシステムが起動した時にバックアップが作成され、設定値まで世代切り替えを行います。

10
システムパラメータ トレースファイルの保存期間
プロセスグループのトレースファイルの保存期間を設定します。ドメイン起動中にトレースファイルが指定した保存期間を超過すると、トレースファイルは削除されます。トレースファイルを削除しない場合は-1を指定してください。

30日
システムパラメータ トレースファイル名を固定する ログファイル名の固定化
トレースファイル名に固定IDを使用し、プロセスIDに関係なく固定するかどうかを指定します。外部のシステムでトレースファイルを監視する場合などにこの機能を使用できます。この設定が有効の場合、トレースファイル名は"プロセスグループ名.固定ID"になります。 この設定が無効の場合、トレースファイル名は"プロセスグループ名.PID"になります。運用管理コマンド(otxadmin)では「トレースファイル名を固定する/しない」をtrue/falseで設定します。
注意事項)
ログファイル名の固定化を有効にしている場合、動的設定変更、動的多重度変更の実行は推奨しません。動的設定変更、動的多重度変更を行った場合、プロセス異常終了を含むプロセス再起動後に設定される固定IDは不定です。

固定しない(false)
名前サーバへの登録 CORBAアプリケーションの配備時に自動でリファレンスを登録する CORBA自動名前登録
CORBAアプリケーションのオブジェクトリファレンスを配備時に自動で登録するかどうかを指定します。この設定が有効の場合、WebOTXが既定値としているオブジェクト名で名前登録が行われます。この設定は次の配備から反映されます。運用管理コマンド(otxadmin)では「自動登録する/しない」をtrue/falseで設定します。

自動で登録しない(false)

7.1.1.3. 起動・停止

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

SystemStart
図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システム)の状態について説明します。

表7.1.1.4-1
状態 アイコンの色 説明
起動処理中 黄色
起動処理中状態です。 起動処理中状態から状態が遷移しない場合は停止を行なってください。 それでも状態が変更しない場合はサービスの再起動を行なってください。

起動中 緑色
起動中状態です。 システムを停止させるときは停止処理により停止することができます。

停止処理中 橙色
停止処理中状態です。 停止処理中状態から遷移しない場合は、もう一度停止を行なってください。 それでも状態が変更しない場合はサービスの再起動を行なってください。

停止 赤色
停止状態です。 システムを起動させるときは起動処理により起動することができます。

起動停止処理失敗 赤色に×印 起動・停止処理に失敗しました。 復旧させるにはサービスの再起動を行なってください。
注意事項

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

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

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

7.1.2.1. 作成・削除

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

APGSakusei
図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. リストビューより変更したい項目を選択し、変更します。

APGPropertyChange
図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.3-1
タブ表記 新項目名(V9) 旧項目名(V8) 説明 新既定値(V9) 旧既定値(V8)
自動起動 アプリケーショングループを自動起動する システム起動時、アプリケーショングループを自動起動する
システム起動時にアプリケーショングループを自動で起動するかどうかを指定します。多数のアプリケーショングループやプロセスグループを動作させる場合は、システムの起動に時間がかかる原因となるため、本設定を「自動起動しない」にしてください。

運用管理コマンド(otxadmin)では「自動起動する/しない」をtrue/falseで設定します。

自動起動する(true)
初期プロセス 初期プロセスを使用する アプリケーション初期プロセスを使用する
初期プロセスを使用するかどうかを指定します。初期プロセスはアプリケーショングループ開始前に実行されます。
初期プロセスを使用する場合は以下の項目を設定する必要があります。
・アプリケーションの種類
・アプリケーションのWebOTX AS のバージョン
・共有コンポーネント名
・アプリケーションのクラス名(Java言語(J2SE)のみ指定)
初期プロセスを含めてアプリケーショングループの起動に時間がかかる場合、タイムアウトで起動に失敗することがあります。
この監視時間を変更するにはシステムTPPの設定を変更します。

運用管理コマンド(otxadmin)では「初期プロセスを使用する/しない」をtrue/falseで設定します。

初期プロセスを使用しない(false)
初期プロセス アプリケーションの種類 利用言語
初期プロセスで実行するアプリケーションの種類を指定します。「初期プロセスを使用する」を指定した場合必ず設定してください。
Javaは、全OSで選択可能です。
C++ (UNIX)は、Windows 以外のOSで選択してください。
Visual C++ 2012は、バージョン9以上選択時、OSがWindows (x64)のみ選択可能です。
Visual C++ 2010は、バージョン8以上選択時、OSがWindows (x64)のみ選択可能です。
Visual C++ 2008は、バージョン8以上選択時、OSがWindows (x86/x64)で選択可能です。
Visual C++ 2005は、バージョン6以上選択時、OSがWindows (x86)のみ選択可能です。
Visual C++ .NET 2003は、バージョン6以上選択時、OSがWindows (x86)のみ選択可能です。
Windows SDKは、OSがWindows (x64)のみ選択可能です。 Platform SDKは、OSがWindows (x64)のみ選択可能です。

Java
初期プロセス アプリケーションのWebOTX AS のバージョン WebOTX AS バージョン
初期プロセスで実行するアプリケーションがリンクしているWebOTX ASライブラリのバージョンを選択します。"初期プロセスを使用する"を指定した場合必ず選択してください。
・OSがWindows (x86)の場合はバージョン6以上選択可能です。ただし、アプリケーションの種類により選択可能バージョンが変わります。詳細は"アプリケーションの種類"のヘルプを参照してください。
・OSがHP-UX (IPF)、Linux (x86)、Windows (x64)の場合はバージョン6以上が選択可能です。
・OSがLinux (x64)の場合はバージョン7以上が選択可能です。

9 8
初期プロセス 共有コンポーネント名 ライブラリファイル名
初期プロセスで実行するアプリケーションが含まれるライブラリの共有コンポーネントを選択します。"初期プロセスを使用する"を指定した場合必ず選択してください。共有コンポーネントに登録されているものがリスト表示されますので、指定するコンポーネントを共有コンポーネントとしてあらかじめ登録しておく必要があります。
"アプリケーションの種類"を変更すると、選択可能なライブラリファイルの一覧が対応したものに更新されます。

-
初期プロセス アプリケーションのクラス名 クラス名
初期プロセスとして実行するアプリケーションのクラス名を指定します。"初期プロセスを使用する"を選択し、"アプリケーションの種類"に「Java」を選択した場合は、必ず指定してください。
"アプリケーションの種類"が「Java」以外の場合は必要はありません。

-
初期プロセス コマンドライン引数 アプリケーション引数
初期プロセスとして実行するアプリケーションに渡すコマンドライン引数を511文字以内で指定します。初期プロセスのアプリケーションで引数が必要な場合は指定してください。

-
初期プロセス その他の引数 -
初期プロセスの起動時にJavaVMオプションに設定する引数を2550文字以内で指定します。引数を空白で区切って設定してください。ダブルクォーテーションで括られた文字列は一つの文字列とみなします。引数中に区切り以外で空白を用いる場合(パス名など)はダブルクォーテーションで括ってください。また、\に続くダブルクォーテーションや\はそのまま文字として表現されます。

-
起動/停止 起動タイムアウト
起動タイムアウト値(秒)を設定します。 指定した時間以内に起動要求が完了しない場合、起動要求はタイムアウトします。 ただし起動処理はタイムアウトした後も行いますのでタイムアウトした後に起動が完了する場合があります。 タイムアウトした場合は状態を確認してください。

120秒
起動/停止 停止タイムアウト
停止タイムアウト値(秒)を設定します。 指定した時間以内に停止要求が完了しない場合、停止要求はタイムアウトします。 ただし停止処理はタイムアウトした後も行いますのでタイムアウトした後に停止が完了する場合があります。 タイムアウトした場合は状態を確認してください。

120秒
状態 状態
アプリケーショングループの起動状態です。状態と数値は以下の通りに対応します。
0:起動処理中
1:起動中
2:停止処理中
3:停止中
4:起動/停止処理失敗
10:クライアント接続中

-

7.1.2.4. 起動・停止

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

APGKidou
図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.2.5-1
状態 アイコンの色 説明
起動処理中 黄色
起動処理中状態です。 起動処理中状態から状態が遷移しない場合は停止を行なってください。 それでも状態が変更しない場合は強制停止を行なってください。

起動中 緑色
起動中状態です。 アプリケーショングループを停止させるときは停止処理により停止することができます。 起動中状態であるアプリケーショングループについては、強制停止をできるだけ行なわないでください。 強制停止を行ないますと正常に終了処理が行なわれない場合があります。

停止処理中 橙色
停止処理中状態です。 停止処理中状態から遷移しない場合は、もう一度停止を行なってください。 それでも状態が変更しない場合は強制停止を行なってください。

停止 赤色
停止状態です。 アプリケーショングループを起動させるときは起動処理により起動することができます。

起動停止処理失敗 赤色に×印 起動・停止処理に失敗しました。 復旧させるには強制停止を行なってください。
クライアント接続中 水色
起動中状態であり、クライアントがそのアプリケーショングループに接続しています。 アプリケーショングループを停止させるときは停止処理により停止することができます。 停止した場合、接続しているクライアントにはエラーが返却されます。 起動中状態であるアプリケーショングループについては、強制停止をできるだけ行なわないでください。 強制停止を行ないますと正常に終了処理が行なわれない場合があります。

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

7.1.3.1. 作成・削除

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

PGSakusei
図7.1.3.1-1

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

表7.1.3.1-1
アプリケーションの種類 コマンド指定時文字列 説明
Java EE javaee
Java EEアプリケーションを配備する場合に作成します。 バージョン9選択時のみ作成可能です。

CORBA Java corbajava
CORBA Javaアプリケーションを配備する場合に作成します。 バージョン7以上選択時に作成可能です。

CORBA C++ cpp
CORBA C++アプリケーションを配備する場合に作成します。
  • OSがHP-UX (IPF64) の場合
    バージョン6以上選択時のみ作成可能です。
  • OSがWindows (x64) の場合
    バージョン6,7,8選択時のみ作成可能です。
  • OSがLinux (x86/x64)の場合
    バージョン9選択時のみ作成可能です。
Windows (x64)にて、Platform SDK for Windows Server 2003 R2を用いて作成したCORBA C++アプリケーションを配備する場合はこちらを指定してください。

CORBA VC++ 2012 vc2012
Microsoft Visual C++ 2012を用いて作成した CORBA C++アプリケーションを配備する場合に作成します。 OSがWindows (x86/x64)のみ、バージョン9選択時に作成可能です。

CORBA VC++ 2010 vc2010
Microsoft Visual C++ 2010を用いて作成した CORBA C++アプリケーションを配備する場合に作成します。 OSがWindows (x86/x64)のみ、バージョン8以上選択時に作成可能です。

CORBA VC++ 2008 vc2008
Windows SDK for Windows Server 2008、Microsoft Visual C++ 2008を用いて作成した CORBA C++アプリケーションを配備する場合に作成します。 OSがWindows (x86/x64)のみ、バージョン8以上選択時に作成可能です。

CORBA VC++ 2005 vc2005
Microsoft Visual C++ 2005を用いて作成した CORBA C++アプリケーションを配備する場合に作成します。 OSがWindows (x86)の場合は全バージョン、OSがWindows (x64)の場合はバージョン8以上選択時に作成可能です。

CORBA VC++ .NET 2003 vc2003
Microsoft Visual C++ .NET 2003 を用いて作成した CORBA C++アプリケーションを配備する場合に作成します。 OSがWindows (x86)のみ、バージョン8以下選択時に作成可能です。

統合運用管理ツールから削除
  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. リストビューより変更したい項目を選択し、変更します。

PGPropertyChange
図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.3-1
タブ表記 新項目名(V9) 旧項目名(V8) 説明 新既定値(V9) 旧既定値(V8)
基本設定 アプリケーションの種類 モジュールの種類
動作するアプリケーションの種類です。プロセスグループ作成後に変更することはできません。

-
基本設定 WebOTX AS バージョン
アプリケーションのWebOTX ASのバージョンです。プロセスグループ作成後に変更することはできません。

-
基本設定 アプリケーショングループ起動時に起動する アプリケーショングループ起動時、プロセスグループを起動する。
アプリケーショングループ起動時に起動するかどうかを指定します。複数のプロセスグループを一斉に起動するなどプロセスの起動処理に長い時間がかかる場合は、起動処理がタイムアウトする可能性があるため、本機能を無効にしてください。

運用管理コマンド(otxadmin)では、有効・無効をtrue/falseで設定します。

起動する(true)
Java非同期メッセージ 非MDBのJava非同期メッセージを使用する 非MDBのJava非同期メッセージを使用します。 非MDBのJava非同期メッセージを使用します。

運用管理コマンド(otxadmin)では、有効・無効をtrue/falseで設定します。

使用しない(false)
トレース設定 トレースレベル
ログ出力の制御に使用するトレースレベルを指定します。J2EEアプリケーションのAPI(TPSUserTrace)とWebOTXの内部処理のログ出力に影響があります。トレースレベルを7にすると性能に影響を及ぼす場合があります。
トレースレベルは以下の意味になります。
0 パニック状態
1 データベースが壊れているなど即時に訂正すべきである状態
2 ハードウェア、デバイスエラーのような致命的なエラー
3 一般的なエラー
4 警告メッセージ
5 通知メッセージ
6 運用履歴を確認するための情報メッセージ
7 障害を解析するためのデバッグメッセージ
-1 トレースを採取しない

5.通知メッセージ
トレース設定 トレースファイルのローテーション方式 -
トレースファイルのローテーションのさせ方について指定します。0を指定した場合は、従来から提供している方式で動作します。
トレースファイルのローテーション方式は以下の3つの中から選ぶことができます。
■ファイルサイズ指定による単一バックアップ: 指定したサイズに達すると、1世代のみバックアップファイルを作成します。バックアップ後のファイル名は拡張子「.bak」に変わります。
■ファイルサイズ単位で指定:指定したサイズに達すると、指定した[最大バックアップ数]までバックアップします。バックアップ後のファイル名は拡張子「.<数字(世代数)>」に変わります。
■実行する間隔を秒単位で指定: 指定した[ローテーション間隔]で定期的にファイルを[最大バックアップ数]までバックアップします。例えば、24時間ごとのローテーションにより、日単位でバックアップをとることができます。また、ローテーションの起点となる時刻を指定することができ、トレースファイル名にはローテーションの開始日時が付与されます。

ローテーションされたトレースファイルは、バックアップファイルとしてトレースファイルと同じディレクトリに退避されます。プロセスグループ内で稼働中のアプリケーションプロセスが停止すると、そのプロセスが作成したバックアップファイルはsaveディレクトリに退避されます。 設定を反映させるにはプロセスグループを再起動する必要があります。

0.ファイルサイズ指定による単一バックアップ -
トレース設定 トレースファイルの最大サイズ トレースファイル最大サイズ
サーバアプリケーションログのトレースファイルの最大サイズを指定します。最大サイズを超えると、既存の情報はバックアップ(トレースファイル名).bakに待避し、新規にトレースファイルを作成します。(単位:KB)

1024KB
トレース設定 システムトレースファイルの最大サイズ システムトレースファイル最大サイズ
サーバアプリケーションログのシステムトレースファイルの最大サイズを指定します。最大サイズを超えると、既存の情報はバックアップ(トレースファイル名).bakに待避し、新規にシステムトレースファイルを作成します。(単位:KB)

1024KB
トレース設定 最大バックアップ数 -
ローテーション実行後に保存するトレースファイルの最大個数を指定します。過去のローテーションによってバックアップされたファイルの数がこの設定値を超えると、最も古いバックアップファイルが削除されます。0を指定した場合、バックアップファイルを作成しません。
トレースファイルのローテーション方式として[0:ファイルサイズ指定による単一バックアップ]以外を指定した場合に有効です。バックアップファイル数がこの値を超えると、最も古いファイルが削除されます。0を指定した場合、バックアップファイルを作成しません。

1 -
トレース設定 ローテーション起点時刻 -
ローテーションする起点時刻を00時00分からの分単位で指定します。0を指定した場合は、00時00分が起点時刻となります。(単位: 分)
トレースファイルのローテーション方式として[2: 実行する間隔を秒単位で指定]を指定した場合に有効となります。 指定可能な値は0から1439の間で、例えば、1350を指定した場合、22時30分を起点としてローテーションを実施します。 設定を反映させるには、プロセスグループを再起動する必要があります。

0 -
トレース設定 ローテーション間隔 -
指定した秒間隔毎にトレースファイルをバックアップファイルとして退避します。退避するタイミングは、指定された時間間隔に達した後、最初のログ出力時になります。(単位: 秒)
トレースファイルのローテーション方式として[2: 実行する間隔を秒単位で指定]を指定した場合に有効となります。ローテーションされたトレースファイルは、バックアップファイルとしてトレースファイルと同じディレクトリに退避されます。 設定を反映させるには、プロセスグループを再起動する必要があります。

86400 -
トレース設定 トレースファイルに標準出力も出力する 標準出力の出力先
アプリケーションの標準出力をトレースファイルに出力するかどうかを指定します。

トレースに統合する
トレース設定 トレースファイルに標準エラー出力も出力する 標準エラー出力の出力先
アプリケーションの標準エラーをトレースファイルに出力するかどうかを指定します。

トレースに統合する
プロセス制御 プロセス数
マルチプロセスで動作させるプロセス数を指定します。プロセスを分割することにより、プロセス障害が発生したときの障害の影響範囲をそのプロセスが使用しているクライアントだけに限定することができます。動的多重度変更時のプロセス上限値でもあります。(既定値:1)

1
プロセス制御 プロセスの優先度
プロセスの優先度を指定します。プロセスを優先順位制御(固定優先度制御、Linuxのみ変動優先度制御)の対象とするときに指定します。未指定を指定した場合は、プロセス優先度制御を使用しません。LOW、BELOW、MIDDLE、ABOVE、HIGHの順に優先度が高くなります。
Solaris、HP-UX、Linuxは、OSの制限によりスーパーユーザでないとプロセスの優先度を変更できません。本機能の利用には、スーパーユーザによるWebOTX Application Serverの起動が必要となります。
Windowsでは、障害発生時にタスクマネージャからプロセスが強制終了できなくなるため、優先度をHIGH以上に設定できません。
各プラットフォームのプロセス優先度値のマッピングは以下の通りです。
Windows:ABOVE 10、MIDDLE 8、BELOW 6、LOW 4
Solaris:HIGH 60、ABOVE 45、MIDDLE 30、BELOW 15、LOW 0
HP-UX:HIGH 178、ABOVE 198、MIDDLE 217、BELOW 236、LOW 255
Linux:HIGH -20、ABOVE -10、MIDDLE 0、BELOW 10、LOW 19

未指定
プロセス制御 動的設定変更時初期化待ち時間
動的設定変更時の初期化待ち時間を指定します。(単位:秒)

600秒
プロセス制御 動的設定変更時終了待ち時間
動的設定変更時の終了待ち時間を指定します。(単位:秒)

600秒
プロセス制御 リカバリプロセスを起動する
リカバリプロセスはプロセスが異常終了した場合に終了処理が完了できなかった資源を解放するために起動するプロセスです。設定を有効にすることでプロセスの異常終了時に名前サーバに一時的に扱うの設定で登録されたオブジェクトリファレンスを削除します。配備したアプリケーションとオブジェクトリファレンスのポリシを確認して適切な設定を行ってください。
Webアプリケーションの場合、またはEJBアプリケーションでオブジェクトリファレンスのポリシを永続的としている場合、「起動しない」に設定することを推奨します。EJBアプリケーションでオブジェクトリファレンスのポリシを一時的としている場合、必ず「起動する」に設定してください。

運用管理コマンド(otxadmin)では、有効・無効をtrue/falseで設定します。

起動する(true)
スレッド制御 スレッド数
スレッド数を指定します。この値と予備スレッド数を足した値が動的多重度変更時のスレッド上限値になります。
Java EEプロセスグループの場合、Webコンテナの動作モードによって既定値が変わります。 アドバンスドモード(Webコンテナがプロセスグループ上で動作する):3 スタンダードモード(旧互換、Webコンテナがエージェント上で動作する):1 指定したスレッド数の他に、WebOTX Application Server内部で使用するスレッド3つが動作します。 そのため、プロセスグループで動作する全スレッドは、プロセス数*(スレッド数+予備スレッド数+3)となります。 TPシステム内の全プロセスグループの合計スレッド数(WebOTX Application Server内部で使用するスレッド含む)が、TPシステムの属性【システムパラメータ】の最大スレッド数を超えない範囲で設定可能です。

アドバンスドモード 3
スタンダードモード(旧互換) 1
スレッド制御 スレッドのスタックサイズ スレッドスタックサイズ
スレッド1つあたりのスタックサイズを指定します。スタックサイズの不足が原因でプロセスが異常終了する場合には、スタックサイズを増やしてください。(単位:KB)

1000KB
スレッド制御 スレッドの初期化時間の上限 スレッド初期化時間
スレッド初期化処理の応答時間を秒単位で1以上を指定します。
この時間以内にアプリケーションの初期化処理が完了しない場合は、プロセス起動に失敗します。 マルチスレッドの場合は各スレッドの初期処理を順番に行うため、アプリケーションの初期化処理時間は全スレッドでかかった時間の総計になります。
また、この時間以内にアプリケーションの終了処理が完了しない場合は、スレッドの終了処理を打ち切って終了します。 マルチスレッドの場合は各スレッドの終了処理を順番に行うため、アプリケーションの終了処理時間は全スレッドでかかった時間の総計になります。

600秒
スレッド制御 オペレーションを異常終了時に閉塞させる オペレーション異常終了時にオペレーションを閉塞させる
オペレーション実行中に例外が発生した場合、自動的にそのオペレーションを閉塞状態にするかどうかを指定します。閉塞状態にすることにより、WebOTX Application Serverサービス全体を停止することなく、障害の影響が拡大することを防ぐことができます。

運用管理コマンド(otxadmin)では、有効・無効をtrue/falseで設定します。

しない(false)
スレッド制御 予備スレッド数
予備スレッド数を指定します。この値とスレッド数を足した値が動的多重度変更時のスレッド上限値になります。予備スレッドを使用する場合は、動的多重度変更を行って下さい。

0
非同期オペレーション呼び出し プロセスグループ間で非同期オペレーション呼び出しを行う 非同期オペレーション呼び出しを行う
このプロセスグループから他のプロセスグループへトランザクション型VDを用いた非同期オペレーション呼び出しを行うかどうかを指定します。詳細は [ 7.1.7.6. 非同期トランザクション ] を参照してください。

運用管理コマンド(otxadmin)では、有効・無効をtrue/falseで設定します。

行わない(false)
キューの最大数 リクエストキューのサイズ キューの最大数
プロセスグループのリクエストキューのサイズを設定します。TPシステムはここで指定した値以上の要求が来るとエラーを返します。この設定により待ち要求の数を制限して、高負荷による無応答を回避できます。-1を指定すると無制限になります。ここで指定した値はシステムの設定より優先されます。

-1
Transaction Service Transaction Service連携を行う
Transaction Service連携を行うかどうかを指定します。 詳細は [ 7.1.7.7. Transactionサービス連携 ] を参照してください。

運用管理コマンド(otxadmin)では、有効・無効をtrue/falseで設定します。

JavaEEコンポーネント:行う(true),その他:行わない(false)
Transaction Service トランザクションの制御
Transaction Service連携のトランザクション制御方式を選択します。 Recovery Coordination Server:Recovery Coordination Server を使用してアプリケーションと同一のプロセス空間でトランザクション処理を実行する

Recovery Coordination Server
Transaction Service OTSポリシ
Transaction Service連携のOTSポリシの選択をします。
ADAPTS: オブジェクトはトランザクション内でもトランザクション外でも動作できる
REQUIRES: オブジェクトは必ずトランザクション内で動作する必要がある
FORBIDS: オブジェクトは必ずトランザクション外で動作する必要がある

ADAPTS
ESB ESB JBIコンテナの起動
インストール時にWebコンテナをアドバンスドモードの動作モードにした構成で、ESB JBIコンテナを起動するかどうかを指定します。 有効にすると、プロセスグループ起動時にJBIコンテナも起動します。スタンダードモード(旧互換モード)では指定できません。

運用管理コマンド(otxadmin)では「ESB JBIコンテナを起動する/しない」をtrue/falseで設定します。

行わない(false)
起動/停止 起動タイムアウト
起動タイムアウト値(秒)を設定します。 指定した時間以内に起動要求が完了しない場合、起動要求はタイムアウトします。 ただし起動処理はタイムアウトした後も行いますのでタイムアウトした後に起動が完了する場合があります。 タイムアウトした場合は状態を確認してください。

120秒
起動/停止 停止タイムアウト
停止タイムアウト値(秒)を設定します。 指定した時間以内に停止要求が完了しない場合、停止要求はタイムアウトします。 ただし停止処理はタイムアウトした後も行いますのでタイムアウトした後に停止が完了する場合があります。 タイムアウトした場合は状態を確認してください。

120秒
WatchServer オブジェクトリファレンスの多重度 登録するオブジェクトの多重度
WatchServer使用時登録する多重度を設定します。
WatchServerを使用する場合、名前サーバに登録するオブジェクトの多重度を1-10の間で設定します。多重度に合わせてそのシステムの負荷が分散されます。

1
コマンドライン引数 コマンドライン引数
プロセスに渡すコマンドライン引数を指定します。先頭に'#',';'は使用できません。コマンドライン引数
例えば、プロセスグループからデータベースに直接接続する場合に、"SID"、"ユーザ名"、"パスワード"などを指定して、プロセスグループで使用する事ができます。

<アプリケーショングループ名>-<プロセスグループ名>
JavaVMオプション 最大ヒープサイズ
最大ヒープサイズを2メガバイト以上のバイト数で指定します。"最大ヒープサイズの単位"で「バイト(-)」を選択した場合には、1024の倍数を指定してください。-1を指定すると、JavaVMの既定値になります。

Windows x86の場合 128/それ以外の場合 -1
JavaVMオプション 最大ヒープサイズの単位
最大ヒープサイズの単位を指定します。単位は、キロバイトなら‘k’、メガバイトなら‘m’、バイトなら‘-’で指定してください。指定しないときはJavaVMの既定値(JavaVMに依存)になります。

m
JavaVMオプション 初期ヒープサイズ
初期ヒープサイズを1メガバイト以上のバイト数で指定します。"初期ヒープサイズの単位"で「バイト(-)」を選択した場合には、1024の倍数を指定してください。-1を指定するとJavaVMの既定値になります。

32
JavaVMオプション 初期ヒープサイズの単位
初期ヒープサイズの単位を指定します。 単位は、キロバイトなら‘k’、メガバイトなら‘m’、バイトなら‘-’で指定してください。 指定しないときはJavaVMの既定値(JavaVMに依存)になります。

m
JavaVMオプション スレッドのネイティブスタックサイズ
スレッドのネイティブスタックサイズを指定します。-1を指定するとJavaVMの既定値になります。

-1
JavaVMオプション スレッドのネイティブスタックサイズの単位
スレッドのネイティブスタックサイズの単位を指定します。 単位は、キロバイトなら‘k’、メガバイトなら‘m’、バイトなら‘-’で指定してください。指定しないときはJavaVMの既定値(JavaVMに依存)になります。

k
JavaVMオプション クラスのガベージコレクションをオフにする
クラスのガベージコレクションをオフにするかどうかを指定します。有効にするとクラスのガベージコレクションが行われなくなりますので、明示的に行う必要があります。

運用管理コマンド(otxadmin)では、有効・無効をtrue/falseで設定します。

オフにしない(false)
JavaVMオプション スタックトレース採取時にJavaヒープの情報を採取する
アプリケーションプロセスでOutOfMemoryErrorが発生しスタックトレースを採取した際に、Javaヒープの情報を採取するかどうかを指定します。また、Ctrl+Break,SIGQUIT受信時にもJavaヒープの情報を採取します。
Javaヒープの情報にはクラス名やオブジェクトサイズ合計、オブジェクト数などが含まれ、クラスごとのオブジェクトサイズの合計の降順でソートされて標準出力に出力されます。(トレース設定の既定値では、標準出力はプロセスグループのトレースに統合されて出力される)

運用管理コマンド(otxadmin)では、採取する・採取しないをtrue/falseで設定します。

採取する(true)
JavaVMオプション Javaヒープの情報採取時に何位の情報まで出力するか
Javaヒープの情報を採取するとき、何位の情報までを出力するかを設定します。

20
JavaVMオプション その他の引数
上記以外の引数を2550文字以内で指定します。引数を空白で区切って設定してください。ダブルクォーテーションで括られた文字列は一つの文字列とみなします。引数中に区切り以外で空白を用いる場合(パス名など)はダブルクォーテーションで括ってください。また、\に続くダブルクォーテーションや\はそのまま文字として表現されます。
-XbootclasspathはWebOTX Application Serverで内部的に使用しているので設定できません。また、-Xdebugはサポートしていません。

-
JavaVMオプション プロセスごとに指定する プロセス固有指定を行う
プロセスごとにJavaVMオプションを設定するかどうかを指定します。

運用管理コマンド(otxadmin)では、「プロセスごとにJavaVMオプションを設定する/しない」をtrue/falseで設定します。

固有指定しない(false)
JavaVMオプション プロセスごとの引数 プロセス固有の引数
プロセス毎に引数を1023文字以内で指定します。引数を空白で区切って設定してください。ダブルクォーテーションで括られた文字列は一つの文字列とみなします。引数中に区切り以外で空白を用いる場合(パス名など)はダブルクォーテーションで括ってください。また、\に続くダブルクォーテーションや\はそのまま文字として表現されます。
-XbootclasspathはWebOTX Application Serverで内部的に使用しているので設定できません。また、-Xdebugはサポートしていません。

-
リソース 使用するデータソース 使用するデータソースリスト
使用するデータソースを指定します。プロセスグループで使用するデータソースのJNDI名を選択してください。

-
リソース 使用するコネクタリソース 使用するコネクタリソースリスト
プロセスグループの起動時にロードするコネクタリソースを指定します。プロセスグループ上で動作するEJBが使用するコネクタリソースのJNDI名を指定してください。

-
リソース 使用するリソースアダプタ 使用するリソースアダプタリスト
プロセスグループの起動時にロードするリソースアダプタを指定します。そのプロセスグループ上で動作するEJBが使用するリソースアダプタの名前を指定してください。

-
データソース 使用するデータソース 使用するデータソースリスト
使用するデータソースを指定します。プロセスグループで使用するデータソースのプロパティファイル名を選択してください。

-
データベースプロセス定義 データベース(ORACLE)を使用する
データベース連携機能を使用するかどうかの設定を行います。使用する場合、本設定を有効にして以下の項目の設定を行ってください。

運用管理コマンド(otxadmin)では、「データベース(ORACLE)を使用する/しない」をtrue/falseで設定します。

利用しない(false)
データベースプロセス定義 SID
プロセスグループ起動時にデータベース連携機能で自動接続するORACLEデータベースのSID名を指定します。

-
データベースプロセス定義 ユーザ名
データベース連携機能でORACLEデータベースの接続に使用するユーザ名を指定します。

-
データベースプロセス定義 パスワード
データベース連携機能でORACLEデータベースの接続に使用するパスワードを指定します。

-
データベースプロセス定義 Oracle Netの使用 SQL Netを使用する
データベース連携機能でOracle Net経由でデータベースを使用するかどうかを指定します。

運用管理コマンド(otxadmin)では、「Oracle Net経由でデータベースを使用する/しない」をtrue/falseで設定します。

しない(false)
データベースコネクションプーリング コネクションプーリングの使用 コネクションプーリングを行う
ODBCドライバVersion 3.0以上を使用してデータベースをアクセスするときにコネクションプーリングの機能を使用するかどうか指定します。
有効にするとWebOTX Application Serverは自動的にコネクションプーリング機能を使用します。

運用管理コマンド(otxadmin)では「コネクションプーリングを使用する/しない」をtrue/falseで設定します。

使用しない(false)
常駐オブジェクト 常駐オブジェクトを使用する
常駐オブジェクトを使用するかどうかを指定します。 詳細は [ 7.1.7.2. 常駐オブジェクト ] を参照してください。

運用管理コマンド(otxadmin)では、「常駐オブジェクトを使用する/しない」をtrue/falseで設定します。

しない(false)
Javaシステムプロパティ 既定Javaシステムプロパティ -
プロセスグループ作成時に既定で設定されるJavaシステムプロパティが表示されます。
Javaシステムプロパティ、その他引数に同名のプロパティが設定されている場合、ここで設定される値は上書きされます。

-
Javaシステムプロパティ Javaシステムプロパティ
Javaシステムプロパティを指定します。プロパティに空白は使用できません。 java.class.path, org.omg.CORBA.ORBClass, org.omg.CORBA.ORBSingletonClassはWebOTX Application Server内部で使用しているため設定できません。
既定値として以下の設定がありますが、統合運用管理ツールの既定値ボタンを押したときは再設定されません。手動で設定しなおす必要があります。 変数=値 log4otx.configuration=file://WebOTXインストールディレクトリ/domains/ドメイン名/config/tpsystem/logconf/アプリケーショングループ名-プロセスグループ名/log4otx.xml (Windowsの場合は値が file:///... となります) java.endorsed.dirs=WebOTXインストールディレクトリ/lib/endorsed java.security.policy=WebOTXインストールディレクトリ/domains/ドメイン名/config/server.policy Webコンテナをマルチプロセスで利用する場合は、以下の設定も追加されます。 log4j.configuration=file://WebOTXインストールディレクトリ/domains/ドメイン名/config/tpsystem/logconf/アプリケーショングループ名-プロセスグループ名/log4j.xml (Windowsの場合は値が file:///... となります) com.nec.webotx.enterprise.taglibs=wosv-jstl.jar,jsf-impl.jar

-
環境変数 環境変数
環境変数を1008文字以内で指定します。変数に空白は使用できません。TPM_ 、WOTX_ から始まる変数はWebOTX Application Server内部で使用しているため設定できません。登録できる環境変数の種類は50個までです。
変数を展開後の文字数が4044文字を超えるとエラーとなります。

-
上限設定 キュー滞留時間監視タイマ
アプリケーションの応答を監視する間隔(キュー滞留時間監視タイマ)を指定します。-1を指定した場合は、IIOPリスナの応答監視設定にあわせます。

-1
上限設定 同時受付オペレーション数
プロセスグループで同時に受け付けるオペレーション数を指定します。オペレーション数には実行中のオペレーション、キューに滞留中のリクエストのオペレーション、WebOTX内部で生成されるオペレーションを含みます。-1を指定した場合は無制限となります。

-1
アプリケーションリスト 登録されているアプリケーション プロセスグループに登録されているアプリケーションリストです。 -
動作情報 スレッド情報
プロセスグループの現在のスレッドの情報です。WebOTX Application Server内部で利用するメインスレッド(MAIN)、受信スレッド(RECV)、送信スレッド(SEND)も表示します。
pid:プロセスID
tid:スレッドID
thno:論理スレッド番号
状態:スレッドの動作状態
モジュール:オペレーション実行中の場合、モジュール名を表示
インタフェース:オペレーション実行中の場合、インタフェース名を表示
オペレーション:オペレーション実行中の場合、オペレーション名を表示
経過時間:オペレーション実行中の場合、その経過時間を表示
クライアント:オペレーション実行中の場合、クライアントIPアドレスを表示
ユーザCPU時間:スレッドのユーザモードCPU時間を表示(ミリ秒)
システムCPU時間:スレッドのシステムモードCPU時間を表示(ミリ秒)
CPU使用率:現在のCPU使用率(%)
稼働情報の採取と設定更新の間隔:スレッド情報の採取間隔(ミリ秒)

-
動作情報 プロセス情報
プロセスグループの現在のプロセス情報です。
pid:プロセスID
CPU使用率:現在のCPU使用率(%)
CPU時間:現在までのトータルCPU時間(ミリ秒)
ユーザCPU時間:現在までのトータルユーザCPU時間(ミリ秒)
システムCPU時間:現在までのトータルシステムCPU時間(ミリ秒)

コンテナ状態:コンテナの次の状態をとります。
APINIT:プロセス起動処理中
CONFREAD:設定ファイル読み込み中
CREJVM:JavaVM起動処理中
LOAD:コンポーネント読み込み中
ORBINIT:ORB初期化中
OBJCRE:サーバオブジェクト作成中
APINIT_E:スレッド起動処理準備中
THINIT:スレッド起動処理中
RESICRE:常駐オブジェクト作成中
ACT:起動状態
THTERM:スレッド停止処理中
RESIDEL:常駐オブジェクト削除中
OBJDEL:サーバオブジェクト削除中
THTERM_E:スレッド停止処理中
APTERM:プロセス停止処理中
UNLOAD:コンポーネントアンロード中
DESJVM:JavaVM終了処理中
TERM:停止状態


仮想メモリ使用量:Windowsの場合はページングファイル使用サイズ、HP-UXの場合はプロセス全体の仮想メモリの合計、Linuxの場合はVmSizeとなります(KB)。Solarisは対応していません。 物理メモリ使用量:Windowsの場合はワーキングセットサイズ、HP-UXの場合は常駐メモリサイズ、Linuxの場合はVmRSSとなります(KB)。Solarisは対応していません。

-
状態 状態
プロセスグループの起動状態です。
状態と数値は以下の通りに対応します。
0:起動処理中
1:起動中
2:停止処理中
3:停止中
4:起動/停止処理失敗
11:プロセス稼動中
12:リカバリ実行中

-
状態 プロセスグループアイドル時間
プロセスグループに登録されたアプリケーションのアイドル時間のうち最小のものを表示します。アプリケーションが登録されていない場合は0が表示されます。(単位:秒)

-
状態 動的設定変更状態
動的設定変更状態です。

-
運用アシスタント 現在までの学習時間
情報採取開始から現在までの学習時間です。(単位:分)

-
運用アシスタント スローダウン継続時間
プロセスグループ内のオペレーションのスローダウン継続時間の最大値を表示します。全てのオペレーションが正常状態の場合は-1が表示されます。表示は"稼働情報の採取と設定更新の間隔"ごとに更新されます。(単位:分)

-
運用アシスタント スローダウン時に自動スタックトレースを採取する スローダウン検出時に、自動でスタックトレースを採取するかを設定します。

運用管理コマンド(otxadmin)では、「採取する/採取しない」をtrue/falseで設定します。
採取する(true)
運用アシスタント 多重度最適化支援
多重度最適化支援機能の設定を行います。
「通知のみ」を選択した場合、稼働情報の採取と設定更新の間隔(「TPシステム」-"稼働情報の採取と設定更新の間隔")が経過するごとに多重度の適正をチェックし、 多重度設定が不適切だと判断すると、その旨をイベントログ出力し、統合運用管理ツールに通知します。実際の多重度変更はオペレータ判断になります。 「設定を変更する」を選択した場合、稼働情報の採取と設定更新の間隔(「TPシステム」-"稼働情報の採取と設定更新の間隔")が経過するごとに多重度の適正をチェックし、 必要に応じてプロセス数を動的に変更します。 「動作しない」を選択すると、多重度の適正をチェックしません。

通知のみ 推奨通知
運用アシスタント 多重度最適化支援:目標応答時間(秒)
多重度最適化支援機能の目標応答時間設定を行います。 現在キューの最後尾で待機しているリクエストが目標応答時間を越える可能性があると予測される場合、 運用アシスタント機能は多重度が不足していると判断します。 リクエストの応答時間の予測は、オペレーションの優先度が同一である場合が想定されています。 目標応答時間は秒単位で設定してください。旧表記は「多重度最適化支援:応答期限(秒)」です。

600秒
運用アシスタント 多重度最適化支援:アイドルCPU使用率(%)
確保すべきアイドルCPU使用率を設定します。 多重度が不足と判断されても、多重度を増加させた場合にアイドルCPU使用率がこの基準を下回ることが予測されるならば、 多重度変更の推奨/自動設定を行いません。 アイドルCPU使用率は%単位で設定してください。

30%
運用アシスタント 多重度最適化支援:多重度を過剰と見なす間隔(分)
多重度最適化支援機能の多重度を過剰と見なす間隔の設定を行います。 プロセス数を減らしてもオペレーション実行に影響を与えない期間がこの時間を超えた場合、 多重度が過剰だと判断されます。旧表記は「多重度最適化支援:多重度過剰期限(分)」です。

1440分
運用アシスタント 多重度過剰期間
現在の多重度過剰期間です。

-
運用アシスタント 多重度最適化支援:予備プロセス数
多重度最適化支援機能の予備プロセス数設定を行います。 ここで設定された予備プロセス数分はプロセス数が過剰であっても、多重度過剰とは判断されません。 障害回避の観点でプロセス数を多めに用意している場合は、こちらを設定してください。

1
統計レポート 統計レポート出力 -
統計レポートが有効化されている時、このプロセスグループをレポート出力対象にします。

運用管理コマンド(otxadmin)では、「出力対象にする/出力対象にしない」をtrue/falseで設定します。

対象にする(true) -
モジュールログレベル Admin Adminモジュールのログレベルを設定します。 CONFIG
モジュールログレベル Apache Commons Apache Commonsモジュールのログレベルを設定します。 CONFIG
モジュールログレベル JNDI Service JNDI Serviceモジュールのログレベルを設定します。 CONFIG
モジュールログレベル Security Securityモジュールのログレベルを設定します。 CONFIG
モジュールログレベル Server Core Server Coreモジュールのログレベルを設定します。 CONFIG
モジュールログレベル Catalina Calalinaモジュールのログレベルを設定します。 CONFIG
モジュールログレベル Http Listener Http Listenerモジュールのログレベルを設定します。 CONFIG
モジュールログレベル JSP JSPモジュールのログレベルを設定します。 CONFIG
モジュールログレベル Web Container Web Containerモジュールのログレベルを設定します。 INFO
モジュールログレベル EJB Container EJB Containerモジュールのログレベルを設定します。 INFO
モジュールログレベル JDBC DataSource JDBC DataSourceモジュールのログレベルを設定します。 CONFIG
モジュールログレベル JDBC Driver JDBC Driverモジュールのログレベルを設定します。 WARN
モジュールログレベル JTA JTAモジュールのログレベルを設定します CONFIG
モジュールログレベル JMS JMSモジュールのログレベルを設定します。 CONFIG
モジュールログレベル Object Broker Java Library Object Broker Java Libraryモジュールのログレベルを設定します。 CONFIG
モジュールログレベル Object Broker Java Message Object Broker Java Messageモジュールのログレベルを設定します。 CONFIG
モジュールログレベル Web Service Web Serviceモジュールのログレベルを設定します。 CONFIG
モジュールログレベル JPA JPAモジュールのログレベルを設定します。 CONFIG
モジュールログレベル Webotx Cache Impl WebOTXにおけるデータグリッド実装のログレベルを設定します。 CONFIG
モジュールログレベル Coherence Coherenceのログレベルを設定します。 CONFIG
モジュールログレベル Infinispan Infinispanのログレベルを設定します。 CONFIG

7.1.3.4. 起動・停止

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

PGKidou
図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.3.5-1
状態 アイコンの色 説明
起動処理中 黄色
起動処理中状態です。 起動処理中状態から状態が遷移しない場合は停止を行なってください。 それでも状態が変更しない場合は強制停止を行なってください。

起動中 緑色
起動中状態です。 プロセスグループを停止させるときは停止処理により停止することができます。 起動中状態であるアプリケーショングループについては、強制停止をできるだけ行なわないでください。 強制停止を行ないますと正常に終了処理が行なわれない場合があります。

停止処理中 橙色
停止処理中状態です。 停止処理中状態から遷移しない場合は、もう一度停止を行なってください。 それでも状態が変更しない場合は強制停止を行なってください。

停止 赤色
停止状態です。 プロセスグループを起動させるときは起動処理により起動することができます。

プロセス稼働中 水色
起動中状態であり、クライアントがそのプロセスグループのオペレーションを実行しています。 プロセスグループを停止させるときは停止処理により停止することができます。 停止した場合、接続しているクライアントにはエラーが返却されます。 起動中状態であるプロセスグループについては、強制停止をできるだけ行なわないでください。 強制停止を行ないますと正常に終了処理が行なわれない場合があります。

リカバリ実行中 橙色
プロセスが例外や実行時間の上限オーバにより異常終了した場合、また強制停止を行い、プロセスが停止要求に応答しない場合にリソースを解放するために行なうリカバリ実行中状態です。 リカバリ実行中状態では60秒経過すると停止状態となります。

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

7.1.4.1. 設定の変更

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

ModulePropertyChange
図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.2-1
タブ表記 新項目名(V9) 旧項目名(V8) 説明 新既定値(V9) 旧既定値(V8)
コンポーネント初期化関数 コンポーネント初期化関数 コンポーネント初期化関数(Javaの場合は初期化クラス)を1023文字以内で指定します。IDLコンパイラ(woi2j,woigenxx)でソースを自動生成した場合、指定の必要はありません。 -
基本設定 ifファイル CORBAサーバアプリケーションのifファイル名を指定します。 共有コンポーネントとして配備されているifファイルを指定して配備することもできます。 -
基本設定 更新日時 サーバアプリケーションの更新日時です。 -
基本設定 サイズ サーバアプリケーションのファイルサイズ(単位:Byte)です。 -
基本設定 自動起動設定 プロセスグループ起動時にモジュールを起動するかどうかを指定します。 運用管理コマンド(otxadmin)では、「プロセスグループ起動時にモジュールを起動する/しない」をtrue/falseで設定します。 する(true)
基本設定 共有コンポーネントのifファイルを参照する 共有コンポーネントの使用 共有コンポーネントのifファイルを使用するかどうかを指定します。 運用管理コマンド(otxadmin)では、「共有コンポーネントのifファイルを使用する/しない」をtrue/falseで設定します。 -
基本設定 アプリケーションの種類 モジュールの種類 動作するアプリケーションの種類です。プロセスグループ作成後に変更することはできません。 -
共有コンポーネント 使用する共有コンポーネント モジュールが使用する共有コンポーネントを指定します。配備済みの共有コンポーネントの中から、アプリケーションで利用する言語にあった共有コンポーネントを指定してください。 -
状態 状態 モジュールの起動状態です。状態と数値は以下の通りに対応します。
0:起動処理中
1:起動中
2:停止処理中
3:停止中
4:起動/停止処理失敗
3
状態 モジュールアイドル時間 モジュール配下のオペレーションが最後に呼ばれた時刻からの経過時間を示します。(単位:秒) -
状態 アクティブオブジェクト数 モジュールアクティブオブジェクト数 モジュール内のアクティブオブジェクト数を表示します。ステートフルの場合、この値が0となっている時は利用しているクライアントが無いことを意味します。 -

7.1.4.3. 活性化・閉塞

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

ModuleKassei
図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.4.4-1
状態 アイコンの色 説明
起動処理中 黄色
起動処理中状態です。 起動処理中状態から状態が遷移しない場合はアプリケーショングループもしくはプロセスグループの停止を行なってください。 それでも状態が変更しない場合はアプリケーショングループもしくはプロセスグループの強制停止を行なってください。

起動中 緑色
起動中状態です。モジュールを停止させるときは停止処理により停止することができます。

停止処理中 橙色
停止処理中状態です。 停止処理中状態から遷移しない場合は、アプリケーショングループもしくはプロセスグループの停止を行なってください。 それでも状態が変更しない場合はアプリケーショングループもしくはプロセスグループの強制停止を行なってください。

停止 赤色
停止状態です。 モジュールをも起動させるときは起動処理により起動することができます。

起動停止処理失敗 赤色に×印
起動・停止処理に失敗しました。 復旧させるにはアプリケーショングループもしくはプロセスグループの停止を行なってください。 それでも状態が変更しない場合はアプリケーショングループもしくはプロセスグループの強制停止を行なってください。

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

7.1.5.1. 設定の変更

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

InterfacePropertyChange
図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.5.2-1
タブ表記 新項目名(V9) 旧項目名(V8) 説明 新既定値(V9) 旧既定値(V8)
事前生成オブジェクト オペレーションコールのモード オブジェクトに登録されているオペレーションをステートフルで動作させるかステートレスで動作させるかを指定します。 ステートレス
事前生成オブジェクト スレッディングモデル オブジェクトのスレッディングモデルを指定します。
ステートレスの場合は以下のApartment、Freeから指定します。ステートフルの場合はFreeで固定となります。
Apartment: オブジェクトをスレッド毎に生成
Free: オブジェクトとは独立して生成
Apartment
事前生成オブジェクト 事前生成するオブジェクト数 事前生成オブジェクト数 事前生成するオブジェクト数を指定します。
0を設定した場合、事前にオブジェクトは生成しません。
ステートレスかつApartmentモデルの場合:プロセスグループのスレッド数が設定されます。変更する場合はプロセスグループのスレッド数から変更してください。
ステートレスかつFreeモデルの場合:プロセスグループのスレッド数が設定されます。アプリケーション単位で個別に設定することもできます。
ステートフルかつApartmentモデルの場合:オブジェクトを生成できないため設定できません。
ステートフルかつFreeモデルの場合:事前にオブジェクトを生成できないため設定できません。
-
事前生成オブジェクト 生成可能な最大オブジェクト数 最大生成オブジェクト数
生成可能な最大オブジェクト数を設定します。
ステートフルの場合:1つの業務で一定数以上のオブジェクトを生成させたくない場合に、生成可能なオブジェクト数の上限を指定します。この上限を越えてオブジェクトを生成しようとすると、オブジェクト生成が失敗します。上限チェックを行わない場合は0を指定します。"事前生成するオブジェクト数"以上の値を指定してください。
ステートレスの場合:Freeスレッディングモデルのときは"事前生成するオブジェクト数"?スレッド数の範囲で指定してください。

-
事前生成オブジェクト コネクション制御ポリシ
Object Brokerにおけるオペレーション呼び出し毎のコネクション制御ポリシを設定します。ロードバランサ使用時には、このポリシを変えることにより、サーバ側のどの単位で負荷分散を行うかを指定できます。ステートレスの場合に設定可能です。ステートフルでは設定できません。
ホスト単位:同一ホストに対するコネクションを再利用する。コネクションが切断されるまでは同一のホストへ送信する。
オブジェクト単位:リファレンス単位にコネクションを再利用する。
コネクションを再利用しない:コネクションを再利用しない。オペレーション呼び出し毎にコネクションを接続する。

ホスト単位
名前サーバへの登録 名前サーバへ登録する 名前サーバへの登録設定 名前サーバへの登録を行うかどうかを設定します。登録する場合、別途名前サーバへのIOR登録URL等の指定が可能になります。
登録する
名前サーバへの登録 登録するURL 名前サーバ登録名のリスト
名前サーバへオブジェクトリファレンスを登録する際のURLをcorbaname形式で1023文字以内で指定します。既定値はIDLファイルのモジュール名、インタフェース名から構築されたURLです。

-
名前サーバへの登録 オブジェクトリファレンスのポリシ 名前サーバへの登録
名前サーバへオブジェクトリファレンスを登録するポリシを設定します。
永続的に扱うを選択した場合、名前サーバへのオブジェクトリファレンスの登録はアプリケーションプロセスの状態に関係なく行えます。このため、一時的に扱うを選択した場合に比べてアプリケーションプロセス起動時の名前サーバへのアクセス負荷を軽減することができます。
一時的に扱うを選択した場合、アプリケーションプロセスの起動時にオブジェクトリファレンスを名前サーバへ登録します。この設定は名前サーバのラウンドロビン機能を有効にしたときにも使用します。

永続的に扱う
名前サーバへの登録 マルチサーバのサーバグループ名 複数サーバシステムグループ名 このアプリケーションを使用するマルチサーバのサーバグループを選択します。名前サーバへリファレンスの登録時に、選択したサーバグループ内で定義されている全てのサーバ情報が登録されます。マルチサーバを使用しない場合は「使用しない」を選択してください。
使用しない
名前サーバへの登録 オブジェクトリファレンスのラウンドロビンを行う ラウンドロビン機能を使用する 同一のサーバアプリケーションが登録されたTPシステム間で名前サーバを使ってオブジェクトリファレンスのラウンドロビンを行うかどうかを設定します。有効にした場合、ObjectBrokerの設定でも名前サーバのラウンドロビン機能を設定する必要があります。
運用管理コマンド(otxadmin)では「ラウンドロビンを行う/行わない」をtrue/falseで設定します。

ラウンドロビンを行わない 使用する
名前サーバへの登録 種別 インタフェースの種別です。 -

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

7.1.6.1. 設定の変更

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

OperationPropertyChange
図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.2-1
タブ表記 新項目名(V9) 旧項目名(V8) 説明 新既定値(V9) 旧既定値(V8)
オペレーション制御 アプリケーショングループ起動時、オペレーションを自動活性する アプリケーショングループ起動時にオペレーションのサービスを開始するかどうかの選択をします。
運用管理コマンド(otxadmin)では、「オペレーションを自動活性する/しない」をtrue/falseで設定します。
自動活性する
オペレーション制御 オペレーションの優先度 オペレーションの優先度を設定します。数字の小さい方が優先度は高くなります。 2
オペレーション制御 実行時間の上限 実行時間上限
オペレーションの実行時間の上限を設定します。オペレーションが指定時間を過ぎてもレスポンスを返却しない場合にオペレーション処理を中断します。-1を設定すると上限を設定しません。
この設定を変更した場合、運用アシスタントの"実行時間の上限に推奨値を自動設定する"設定は、「自動設定しない」に変更されます。運用アシスタントに実行時間の上限を自動設定させたい場合は、「自動設定する」に変更し直してください。
スローダウン監視機能の指定により、以下のように既定値が異なります。
  • フェイルセーフ機能を使用する
    • アプリケーションの種類がJava EEもしくはCORBA Javaの場合、既定値は-1(上限を設定しない)となります。
    • CORBA C++(CORBA VC++ <バージョン番号>を含む)の場合、既定値は600秒となります。
  • 運用アシスタント機能を使用する、またはスローダウンを監視しない
    • アプリケーションの種類にかかわらず既定値は600秒となります。
説明欄参照 600
オペレーション制御 実行時間の上限超過時にプロセスを強制停止する プロセスを強制停止する
オペレーションが実行時間の上限を超過した時(WebOTX内部の精度は最大10秒の遅れがあります)にプロセスを強制停止するかどうかを指定します。オペレーションの実行時間が上限を超えたスレッド以外のスレッドでは現在処理中のオペレーションの完了を待ちあわせ、全てのスレッドでオペレーションが完了するか待ち合わせ時間を経過したらスレッドの終了処理を行います。オペレーション完了待ち合わせ時間は調整可能で、既定値は600秒です。この設定は、詳細内容を参照し十分に理解した上で変更して下さい。

また、オペレーションの実行時間の上限は運用アシスタントにより推奨値が自動設定されている場合があります。プロセスを強制停止する場合は、実行時間の上限の設定値が問題ないかを検討して下さい。

プロセスを強制停止する設定に変更した場合、予期しない時間で強制停止されることを防ぐために、運用アシスタントの「実行時間の上限に推奨値を自動設定する」設定は、「自動設定しない」に変更されます。運用アシスタントに実行時間の上限を自動設定させたい場合は、「自動設定する」に変更し直してください。

運用管理コマンド(otxadmin)では有効・無効をtrue/falseで設定します。
強制停止しない
オペレーション制御 実行時間の上限の推奨値 実行時間上限推奨値 現在までの実行履歴の統計情報をもとに算出された実行時間の上限の推奨値を表示します。 -
データベースの設定 データベース入出力時のエラー処理 データベース連携機能を利用中にデータベース入出力エラーが発生した場合の処理を設定します。 実行中のオペレーションをキャンセルし以後このオペレーションは閉塞
データベースの設定 オペレーション終了時にデータベースの自動コミット/ロールバックを行う データベース連携機能を利用時に、オペレーション終了時のステータスによってデータベースの自動コミット/ロールバックを行うかどうかを指定します。
運用管理コマンド(otxadmin)では、「オペレーション終了時にデータベースの自動コミット/ロールバックを行う/行わない」をtrue/falseで設定します。
指定しない
状態 状態
オペレーションの起動状態です。

-
運用アシスタント 学習期間 学習期間を設定します。
学習期間内は実行時間の上限や多重度の自動設定・一括設定を行いません。学習期間には各サービスのデータが十分に採取できる時間を設定してください。たとえば、週末は負荷が高いサービスであれば、学習期間には1週間以上を設定してください。
1440分
運用アシスタント 実行時間の上限の推奨値を提示する 実行時間上限推奨値を提示する
実行時間の上限の推奨値を提示するかどうか設定します。
推奨値を提示しない場合は実行時間の上限の自動設定機能も働きません。
スローダウン監視機能の指定により、以下のように既定値が異なります。
  • フェイルセーフ機能を使用する
    • アプリケーションの種類がJava EEもしくはCORBA Javaの場合、既定値はfalseとなります。
    • CORBA C++(CORBA VC++ <バージョン番号>を含む)の場合、既定値はtrueとなります。
  • 運用アシスタント機能を使用する、またはスローダウンを監視しない
    • アプリケーションの種類にかかわらず既定値はtrueとなります。
説明欄参照 する
運用アシスタント 実行時間の上限の推奨値を更新する 実行時間上限推奨値を更新する
実行時間の上限の推奨値を更新するかどうか設定します。
「更新する」を設定すると稼働情報の採取と設定更新の間隔(「TPシステム」-"稼働情報の採取と設定更新の間隔")ごとに推奨値が更新されます。推奨値の妥当性を検証したい場合など、推奨値の更新を止めることもできます。
スローダウン監視機能の指定により、以下のように既定値が異なります。
  • フェイルセーフ機能を使用する
    • アプリケーションの種類がJava EEもしくはCORBA Javaの場合、既定値はfalseとなります。
    • CORBA C++(CORBA VC++ <バージョン番号>を含む)の場合、既定値はtrueとなります。
  • 運用アシスタント機能を使用する、またはスローダウンを監視しない
    • アプリケーションの種類にかかわらず既定値はtrueとなります。
説明欄参照 する
運用アシスタント 実行時間の上限値の推奨基準 実行時間上限値 推奨基準
実行時間の上限値の推奨基準を設定します。
早期復旧優先を設定した場合は短めの値が、オペレーション継続優先を設定した場合は長めの値が実行時間の上限値として推奨されます。

ノーマル
運用アシスタント 実行時間の上限に推奨値を自動設定する 実行時間上限を自動設定する オペレーション固有の実行時間の上限に運用アシスタントが算出した推奨値を自動設定するかどうかを設定します。有効にすると稼働情報の採取と設定更新の間隔([TPシステム]-"稼働情報の採取と設定更新の間隔")ごとに実行時間の上限が自動的に更新されます。
推奨値が設定値の90%〜100%であるような微小な減少では値は自動設定されません。推奨値が0以上9以下である場合も自動設定されません。
スローダウン監視機能の指定により、以下のように既定値が異なります。
  • フェイルセーフ機能を使用する
    • アプリケーションの種類がJava EEもしくはCORBA Javaの場合、既定値はfalseとなります。
    • CORBA C++(CORBA VC++ <バージョン番号>を含む)の場合、既定値はtrueとなります。
  • 運用アシスタント機能を使用する、またはスローダウンを監視しない
    • アプリケーションの種類にかかわらず既定値はtrueとなります。
運用管理コマンド(otxadmin)では「実行時間の上限の推奨値を自動設定する/しない」をtrue/falseで設定します。

説明欄参照 する
運用アシスタント スローダウンを監視する スローダウン障害を検出する
スローダウンを監視するかどうかを指定します。
スローダウン障害検出有無を設定します。trueにすると稼働情報の採取と設定更新の間隔([TPシステム]-"稼働情報の採取と設定更新の間隔")が経過するごとにスローダウン障害が発生していないか調べます。スローダウン障害の検出は、稼働情報の採取と設定更新の間隔内に実行された全てのオペレーションの統計から総合的に判断されます。スローダウン障害の疑いがあっても、正常動作の可能性が多く残る場合は、スローダウン障害として検出しません。スローダウン障害を検出すると、イベントログ出力と統合運用管理ツールへの通知が行われます。スローダウンを検出してすぐに、ログの待避ジャーナルの待避・イベントジャーナルの編集を行うと障害解析に役立ちます。
スローダウン監視機能の指定により、以下のように既定値が異なります。
  • フェイルセーフ機能を使用する
    • アプリケーションの種類がJava EEもしくはCORBA Javaの場合、既定値はfalseとなります。
    • CORBA C++(CORBA VC++ <バージョン番号>を含む)の場合、既定値はtrueとなります。
  • 運用アシスタント機能を使用する
    • アプリケーションの種類にかかわらず既定値はtrueとなります。
  • スローダウンを監視しない
    • アプリケーションの種類にかかわらず既定値はfalseとなります。
説明欄参照 する
運用アシスタント スローダウン障害検出基準
スローダウン障害の検出基準を設定します。 スローダウン障害を早期に検出したい場合は「早期検出優先」を設定してください。 正常動作とみなせるオペレーションまでスローダウン障害として検出されてしまう場合は「長め」を設定してください。

ノーマル
運用アシスタント スローダウン継続時間 オペレーションのスローダウン継続時間の最大値を表示します。ノーマル状態の場合は-1が表示されます。表示は"稼働情報の採取と設定更新の間隔"ごとに更新されます。
-
運用アシスタント スローダウンの継続を監視する間隔 スローダウン継続監視時間
スローダウンの継続有無を監視する間隔を設定します。設定した時間を経過してもスローダウン状態が解消されない場合は「長期にわたるスローダウン」として警告メッセージを出力します。-1を設定すると、スローダウンを検出してからの経過時間を監視しません。
スローダウンを検出してからの経過時間は、"稼働情報の採取と設定更新の間隔"ごとにチェックされます。

1200秒 20分
運用アシスタント 現在までの学習時間
情報採取開始から現在までの学習時間です。
-
運用アシスタント スローダウンの判定時間を自動計算する -
運用アシスタントでスローダウンの判定に使用する応答時間について、統計情報から自動計算するかどうかを指定します。判定判定時間を手動で設定する場合は無効にしてください。
自動計算する -
運用アシスタント スローダウンとみなす応答時間 -
スローダウンの判定に使用する応答時間を設定します。「スローダウンの判定時間を自動計算する」を有効にした場合この設定は無視されます。
40秒 -

7.1.6.3. 起動・停止

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

OperationKidou
図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.6.4-1
状態 アイコンの色 説明
起動中 緑色 起動中状態です。 モジュールを停止させるときは停止処理により停止することができます。
停止 赤色
停止状態です。 オペレーションをも起動させるときは起動処理により起動することができます。

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)状態になります。 ただし、つぎのアライブチェック時にセッションを張りなおします。

接続クライアント情報の各項目は以下の通りです。

表7.1.7.1-1
項目名 説明
接続クライアント名
WebOTX Application Server内部で使用しているクライアントの論理識別名

ホスト名
クライアントのホスト名(クライアント情報表示時にホスト名の逆引き処理を行う場合のみ表示)

IPアドレス
クライアントのIPアドレス

接続状態
コネクション接続状態(Not connected/ Now accepting.../ Now connecting.../ Connecting/ Now disconnecting.../ Trouble/ Exit Trouble)

接続時間
コネクション接続時間(秒)

クライアントの強制切断

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

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

常駐オブジェクトの設定

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

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

表7.1.7.2-1
新項目名(V9) 旧項目名(V8) 説明 新既定値(V9) 旧既定値(V8)
オブジェクト識別名
常駐オブジェクトを識別するための識別名を16文字以内の英数字で一意に設定します。 最初の文字は英字で指定してください。 ここでは大文字と小文字は区別されます。

-
共有コンポーネント名 コンポーネント名
常駐オブジェクトに指定する共有コンポーネント名を設定します。 共有コンポーネントに登録されているものがリスト表示されますので、指定するコンポーネントを共有コンポーネントとしてあらかじめ登録しておく必要があります。

-
常駐オブジェクトのクラス名 オブジェクトクラス名
常駐オブジェクトのクラス名を指定します。 例えばpreObjというクラス名を指定するときは、次のように設定します。
Packageありの場合:jp.co.nec.preObj
Packageなしの場合:preObj

-
オペレーション開始時の呼び出しを行う
オペレーション開始時に常駐オブジェクトへの呼び出しを行うかどうかを指定します。 複数常駐オブジェクトの場合のみ指定可能です。
運用管理コマンド(otxadmin)では、「オペレーション開始時の呼び出しを行う/行わない」をtrue/falseで設定します。

行う(true)
オペレーション正常終了時の呼び出しを行う
オペレーション正常終了時に常駐オブジェクトへの呼び出しを行うかどうかを指定します。 複数常駐オブジェクトの場合のみ指定可能です。
運用管理コマンド(otxadmin)では、「オペレーション正常終了時の呼び出しを行う/行わない」をtrue/falseで設定します。

行う(true)
オペレーション異常終了時の呼び出しを行う
オペレーション異常終了時に常駐オブジェクトへの呼び出しを行うかどうかを指定します。 複数常駐オブジェクトの場合のみ指定可能です。
運用管理コマンド(otxadmin)では、「オペレーション異常終了時の呼び出しを行う/行わない」をtrue/falseで設定します。

行う(true)
例外発生時の呼び出しを行う
例外発生時に常駐オブジェクトへの呼び出しを行うかどうかを指定します。 複数常駐オブジェクトの場合のみ指定可能です。
運用管理コマンド(otxadmin)では、「例外発生時の呼び出しを行う/行わない」をtrue/falseで設定します。

行う(true)
ロード順
常駐オブジェクトをロードする順番を設定します。複数の常駐オブジェクトを指定する場合必ず一意となるように設定してください。設定した順番が複数存在する場合は、指定した内容が優先的に設定され、 他の重複していた番号は一意となるように、自動で次の優先順位に順番を振りなおします。

1

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

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

注意事項
表7.1.7.2-2
C++パターン 1 2
オブジェクト識別名 ×
結果 上書 追加
表7.1.7.2-3
Javaパターン 1 2 3 4 5 6 7 8
オブジェクト識別名 × × × ×
オブジェクトファイル名 × × × ×
常駐オブジェクトクラス名 × × × ×
結果 上書 上書 上書 上書 追加 追加 不可 追加
○:一致する
×:一致しない
常駐オブジェクトの削除

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

注意事項

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

7.1.7.3. 共有コンポーネント

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

共有コンポーネントの登録・置換
表7.1.7.3-1
タブ表記 新項目名(V9) 旧項目名(V8) 説明 新既定値(V9) 旧既定値(V8)
共有コンポーネント コンポーネントの名前
共有コンポーネントのファイル名です。

-
共有コンポーネント コンポーネントの種類
共有コンポーネントの種類です。
Java:Java共有コンポーネント
C++:C++共有コンポーネント
ifファイルのみ:ifファイルのみの登録

-
共有コンポーネント ifファイル名
ifファイル名です。
共有コンポーネントのインタフェース情報定義ファイル名です。Ifファイルのみの登録もできます。CORBAアプリケーション配備時にこのifファイルを指定して配備することもできます。

-
共有コンポーネント 更新日時
共有コンポーネントの更新日時です。

-
共有コンポーネント サイズ
共有コンポーネントのファイルサイズです。(単位:Byte)

0
共有コンポーネント 全てのモジュールで使用する
全てのモジュールで使用するかどうか設定します。
trueの場合、全てのモジュールへ該当共有コンポーネントを使用するように設定します。falseの場合は何も行いません(すべてのモジュールからはずす処理は行いません)。

使用しない(false)

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

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

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

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

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

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

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

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

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

注意事項

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

7.1.7.4. 名前サーバへの登録

名前サーバへの登録

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

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

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

サーバアプリケーションのオブジェクトは、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は、名前サーバホスト名の省略はできません。

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

URLを指定できずコマンドも使用できないという場合は、WebOTXAdministratorにインストールされる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
図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. インタフェースの設定
    インタフェースの属性で負荷分散を行う全てのインタフェースについて、[オブジェクトリファレンスのポリシ]を[永続的に扱う]に設定し、[マルチサーバのシステムグループ名]に[マルチサーバ]で作成したシステムグループ名を指定します。
  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. 非同期トランザクション

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

AsyncTX
図7.1.7.6-1

  1. 非同期トランザクションを行うための1stステージ、2ndステージコンポーネントを作成します。
  2. 通常コンポーネント同様非同期トランザクションを行う1stステージ、2ndステージコンポーネントを登録します。
  3. 1stステージコンポーネントを登録したプロセスグループのプロパティにて[非同期オペレーション呼び出し]を選択し、[プロセスグループ間で非同期オペレーション呼び出しを行う]にチェックします。
  4. トランザクション型VDを作成します。 [VDのプロパティ」では1stステージから呼び出される2ndステージのオペレーションとそれが属するアプリケーショングループ、プロセスグループ、モジュール名、インタフェース名を設定します。
  5. トランザクション型VDを起動します。
  6. 1stステージ、2ndステージのアプリケーショングループを起動します。
表7.1.7.6-1
タブ表記 新項目名(V9) 旧項目名(V8) 説明 新既定値(V9) 旧既定値(V8)
VD VDを使用する
VDを使用するかどうかを設定します。設定変更時にはVDの初期化が必要です。VDデータファイルの初期化を行う設定になっていない場合は、TPシステムを停止してVDのクリアを実行してください。この設定の変更はTPシステム起動時に行うとエラーになります。
運用管理コマンド(otxadmin)では、「VDを使用する/しない」をtrue/falseで設定します。

使用する(true)
VD 最大VD数
最大VD数を設定します。この設定の変更はTPシステム起動時に行うとエラーになります。
使用するVDの最大数を1から1000の整数で設定してください。すでに作成されているVD数以上の値を指定してください。 TPシステム起動時に変更するとエラーになります。 設定変更時、VDの初期化が必要です。VDデータファイルの初期化を行う設定になっていない場合は、TPシステムを停止してVDのクリアを実行してください。

10 1
VD VDマスタデータファイルのフラッシュを行う
VDで使用するデータファイルの更新時にディスクへのフラッシュを行うかどうかを設定します。フラッシュを行うとオペレーティングシステムのダウン後もデータファイルを使用できます。設定変更時にはVDの初期化が必要です。VDデータファイルの初期化を行う設定になっていない場合は、TPシステムを停止してVDのクリアを実行してください。
運用管理コマンド(otxadmin)では、有効・無効をtrue/falseで設定します。

フラッシュしない(false)
VD VDマスタデータファイルの初期化を行う
TPシステム起動時にVDマスタデータファイルを初期化するかどうかの設定を行います。 初期化を行うと前回の電文は全て消去され、行わないと前回運用時のVDのメッセージをそのまま使用できます。設定変更時はVDデータファイルの初期化が必要です。初期化を行う設定になっていない場合は、TPシステムを停止してVDのクリアを実行してください。
運用管理コマンド(otxadmin)では、有効・無効をtrue/falseで設定します。

初期化する(true)
VD 呼び出したオペレーション終了待ち合わせ時間
呼び出したオペレーション終了待ち合わせ時間の設定を行います。
トランザクション型VDの場合、呼び出したオペレーションをvdserverが監視しています。その待ち合わせ時間を指定します。0秒を指定すると無限待ちとなります。

30秒
VD 非同期オペレーションの電文サイズ
非同期オペレーションの電文サイズを設定します。9765(KB)以上の値を設定する場合は、TPシステムの「10MByte以上の電文を利用する」設定が有効になっている必要があります。

32KB

以下に、トランザクション型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滞留メッセージのクリア
VDに滞留した不要なメッセージを、オペレーション実行中のデータも含めて強制的に削除します。 オペレーション実行中に以下の操作は行わないでください。
  1. 統合運用管理ツールを起動し、ドメインに接続します。
  2. [VDインフォメーション]配下の該当VDを選択し、[操作]-[VD滞留メッセージのクリア]を実行します。
VDのプロパティ
  1. 統合運用管理ツールを起動し、ドメインに接続します。
  2. [VDインフォメーション]配下の該当VDを選択します。
  3. 設定したい項目を設定します。

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

表7.1.7.6-2
タブ表記 新項目名(V9) 旧項目名(V8) 説明 新既定値(V9) 旧既定値(V8)
基本設定 VDの型
VDの型を設定します。型についてはVD作成時に指定します。作成後、変更することは出来ません。
VDの型を端末型、トランザクション型、間接型(ラウンドロビン)、間接型(滞留数優先)から選択してください。 トランザクション型VDを作成した場合は、非同期オペレーションを選択してください。これによって選択されたオペレーションは非同期オペレーションとなります。このオペレーションが非同期オペレーション呼び出しをする設定にしたプロセスグループからVD経由で呼ばれることになります。 すでに他のVDによって選択されているオペレーションを選択することはできません。 間接型VDはトランザクション型VDがないと作成できません。 間接型VDは次のような機能を持っています。 ラウンドロビン:間接型VDはラウンドロビンで決定した配下のVDへ送信する 滞留数優先:間接型VDは滞留数の最も少ない配下のVDへ送信する 間接型VDを作成した場合は、使用するトランザクション型VDを選択してください。複数選択が可能です。選択されたトランザクション型VDは統合運用管理ツールからは見えなくなります。間接型VDを削除すると再び見えるようになります。

-
基本設定 ドメイン起動時にVDも起動する ドメイン起動時にVDを起動する
ドメイン起動時のVDの状態を指定します。
起動しない:ドメイン起動時にVDを起動しない
起動する:ドメイン起動時にVDを起動する
閉塞状態で起動:ドメイン起動時にVDを共有メモリ上へ展開のみ行う

起動する(true)
基本設定 実行優先度 実行優先順位
VD間の実行優先度を設定します。数字が低いほど優先的に実行されます。実行優先度機能を利用すると、複数のVDに滞留が発生した場合に、どのVDを優先的に処理するかを制御できます。設定変更時にはVDの初期化が必要です。VDデータファイルの初期化を行う設定になっていない場合は、TPシステムを停止してVDのクリアを実行してください。

2
基本設定 VDマスタデータファイルに情報を置かずに個別で持つ
個別にデータファイルを持つかどうかを設定します。データファイルを多数利用するとVDの性能に影響があります。 ファイルを複数利用する必要がない場合はマスタデータファイルのみを利用してください。設定変更時にはVDの初期化が必要です。VDデータファイルの初期化を行う設定になっていない場合は、TPシステムを停止してVDのクリアを実行してください。運用管理コマンド(otxadmin)では、有効・無効をtrue/falseで設定します。

持たない(false)
基本設定 個別VDデータファイルサイズ
VDのメッセージを格納するデータファイルのサイズを設定します。設定変更時にはVDの初期化が必要です。VDデータファイルの初期化を行う設定になっていない場合は、TPシステムを停止してVDのクリアを実行してください。

1MB
基本設定 VDデータファイルのフラッシュを行う 個別VDデータファイルのフラッシュを行う
VDで使用するデータファイルの更新時にディスクへのフラッシュを行うかどうかを設定します。フラッシュを行うとオペレーティングシステムのダウン後もデータファイルを使用できますが、フラッシュのたびにディスクI/Oが発生し、性能が著しく劣化するため、通常はフラッシュを行わないでください。設定変更時にはVDの初期化が必要です。VDデータファイルの初期化を行う設定になっていない場合は、TPシステムを停止してVDのクリアを実行してください。運用管理コマンド(otxadmin)では、有効・無効をtrue/falseで設定します。

しない(false)
基本設定 個別VDデータファイルの初期化を行う
VDサーバ起動時に保存メッセージを消去して初期化するかどうかを設定します。VDに関連するプロパティの変更を行った場合、TPシステムを停止して次のファイルを削除してください。
個別にデータを持つ設定にしている場合:ドメインルート/config/tpsystem/vdf配下
個別に持たない場合:ドメインルート/config/tpsystem/data/vd_master (マスタデータファイル)
設定変更時にはVDの初期化が必要です。VDデータファイルの初期化を行う設定になっていない場合は、TPシステムを停止してVDのクリアを実行してください。

する(true)
基本設定 個別VDデータファイル名
VDで使用するデータファイルの名前を設定します。入力しなかった場合はVD名が個別VDデータファイル名となります。個別VDデータファイルは以下の位置に作成されます。
Windows:[WebOTX AS install directory]\domains\[ドメイン名]\config\tpsystem\vdf\[個別VDデータファイル名]
UNIX:[WebOTX AS install directory]/domains/[ドメイン名]/config/tpsystem/vdf/[個別VDデータファイル名]

VD名
トランザクション型VDのプロパティ アプリケーショングループ名
非同期オペレーションが属するアプリケーショングループ名です。作成時に指定した値を変更しないでください。
トランザクション型VDを作成した場合は、非同期オペレーションが属するアプリケーショングループが表示されます。作成時に指定した値を変更しないでください。

-
トランザクション型VDのプロパティ プロセスグループ名
非同期オペレーションが属するプロセスグループ名です。作成時に指定した値を変更しないでください。
トランザクション型VDを作成した場合は、非同期オペレーションが属するプロセスグループが表示されます。作成時に指定した値を変更しないでください。

-
トランザクション型VDのプロパティ モジュール名
非同期オペレーションが属するモジュール名です。作成時に指定した値を変更しないでください。
トランザクション型VDを作成した場合は、非同期オペレーションが属するモジュールが表示されます。作成時に指定した値を変更しないでください。

-
トランザクション型VDのプロパティ インタフェース名
非同期オペレーションが属するインタフェース名です。作成時に指定した値を変更しないでください。
トランザクション型VDを作成した場合は、非同期オペレーションが属するインタフェースが表示されます。作成時に指定した値を変更しないでください。

-
トランザクション型VDのプロパティ オペレーション名
非同期オペレーション名です。作成時に指定した値を変更しないでください。
トランザクション型VDを作成した場合は、非同期オペレーションが表示されます。作成時に指定した値を変更しないでください。これによって選択されたオペレーションは非同期オペレーションとなります。このオペレーションが非同期オペレーション呼び出しをする設定にしたプロセスグループからVD経由で呼ばれることになります。

-
間接型VDのプロパティ トランザクション型VDリスト
間接型VDが使用するトランザクション型VDのリストを設定します。

-
統計情報 VDの接続状態
VDに接続しているクライアントの有無を表示します。

未接続(false)
状態 VDの起動状態
VDの起動状態です。

-
注意事項

7.1.7.7. Transactionサービス連携

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

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

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

TSRenkei
図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メッセージを抑制する場合にはダウンローダ管理サービスの設定が必要です。 ダウンローダ管理サービスの設定について以下に示します。

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

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

表7.1.7.8-1
タブ表記 新項目名(V9) 旧項目名(V8) 説明 新既定値(V9) 旧既定値(V8)
基本設定 ダウンローダ管理ツールの接続を受け付ける -
ダウンローダ管理ツールからの接続を受け付けるかを指定します。ダウンローダ管理ツールから本サーバに接続する場合、設定を有効にしてください。

無効(false) -
基本設定 ポート番号
利用するポート番号を1〜65535の整数で指定します。 システムで使用する全てのポート番号の中で一意に設定してください。 設定を反映させるにはドメインの再起動が必要です。

5202
基本設定 バッグログサイズ
通信ソケットのバックログサイズを指定します。

50
基本設定 待ち受けタイムアウト値
通信ソケットの待ち受けタイムアウト値を指定します。

5秒
基本設定 受信タイムアウト値 受信タイムアウト値を指定します。 10秒
統合運用管理ツールから設定
  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滞留メッセージのクリア
VDに滞留した不要なメッセージを、オペレーション実行中のデータも含めて強制的に削除します。 オペレーション実行中に以下の操作は行わないでください。
  1. 統合運用管理ツールを起動し、ドメインに接続します。
  2. [VDインフォメーション]配下の該当VDを選択し、[操作]-[VD滞留メッセージのクリア]を実行します。
端末型VDのプロパティ
  1. 統合運用管理ツールを起動し、ドメインに接続します。
  2. [VDインフォメーション]配下の該当VDを選択します。
  3. 設定したい項目を設定します。

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

表7.1.7.9-1
タブ表記 新項目名(V9) 旧項目名(V8) 説明 新既定値(V9) 旧既定値(V8)
基本設定 ドメイン起動時にVDを起動する ドメイン起動時のVDの状態を指定します。
起動しない:ドメイン起動時にVDを起動しない
起動する:ドメイン起動時にVDを起動する
閉塞状態で起動:ドメイン起動時にVDを共有メモリ上へ展開のみ行う
起動する(true)
基本設定 実行優先度 実行優先順位 VD間の実行優先度を設定します。数字が低いほど優先的に実行されます。実行優先度機能を利用すると、複数のVDに滞留が発生した場合に、どのVDを優先的に処理するかを制御できます。設定変更時にはVDの初期化が必要です。VDデータファイルの初期化を行う設定になっていない場合は、TPシステムを停止してVDのクリアを実行してください。 2
基本設定 VDマスタデータファイルに情報を置かずに個別で持つ 個別にデータファイルを持つかどうかを設定します。データファイルを多数利用するとVDの性能に影響があります。 ファイルを複数利用する必要がない場合はマスタデータファイルのみを利用してください。設定変更時にはVDの初期化が必要です。VDデータファイルの初期化を行う設定になっていない場合は、TPシステムを停止してVDのクリアを実行してください。運用管理コマンド(otxadmin)では、有効・無効をtrue/falseで設定します。 持たない(false)
基本設定 個別VDデータファイルサイズ VDのメッセージを格納するデータファイルのサイズを設定します。設定変更時にはVDの初期化が必要です。VDデータファイルの初期化を行う設定になっていない場合は、TPシステムを停止してVDのクリアを実行してください。 1MB
基本設定 VDデータファイルのフラッシュを行う 個別VDデータファイルのフラッシュを行う VDで使用するデータファイルの更新時にディスクへのフラッシュを行うかどうかを設定します。フラッシュを行うとオペレーティングシステムのダウン後もデータファイルを使用できますが、フラッシュのたびにディスクI/Oが発生し、性能が著しく劣化するため、通常はフラッシュを行わないでください。設定変更時にはVDの初期化が必要です。VDデータファイルの初期化を行う設定になっていない場合は、TPシステムを停止してVDのクリアを実行してください。運用管理コマンド(otxadmin)では、有効・無効をtrue/falseで設定します。 しない(false)
基本設定 個別VDデータファイルの初期化を行う VDサーバ起動時に保存メッセージを消去して初期化するかどうかを設定します。VDに関連するプロパティの変更を行った場合、TPシステムを停止して次のファイルを削除してください。
個別にデータを持つ設定にしている場合:ドメインルート/config/tpsystem/vdf配下
個別に持たない場合:ドメインルート/config/tpsystem/data/vd_master (マスタデータファイル)
設定変更時にはVDの初期化が必要です。VDデータファイルの初期化を行う設定になっていない場合は、TPシステムを停止してVDのクリアを実行してください。
する(true)
基本設定 個別VDデータファイル名
VDで使用するデータファイルの名前を設定します。入力しなかった場合はVD名が個別VDデータファイル名となります。個別VDデータファイルは以下の位置に作成されます。
Windows:[WebOTX AS install directory]\domains\[ドメイン名]\config\tpsystem\vdf\[個別VDデータファイル名]
UNIX:[WebOTX AS install directory]/domains/[ドメイン名]/config/tpsystem/vdf/[個別VDデータファイル名]
VD名
端末型VDのプロパティ クライアントの一時的な送信エラー時の後処理 クライアント永久障害発生時の後処理 一時的な送信エラーが発生したときに、VDの切り離しを行うかどうかを指定します。行わない場合は送信をリトライします。運用管理コマンド(otxadmin)では、「VDの切り離しを行う/VDの切り離しを行わず送信リトライする」をtrue/falseで設定します。
VDの切り離しを行わずに送信リトライする(false)
端末型VDのプロパティ 取り出し後のメッセージ 取り出し後のメッセージを保留するかどうかを設定します。設定変更時にはVDの初期化が必要です。VDデータファイルの初期化を行う設定になっていない場合は、TPシステムを停止してVDのクリアを実行してください。運用管理コマンド(otxadmin)では、「メッセージを保留する/しない」をtrue/falseで設定します。
しない(false)
注意事項
OLFTPリスナの設定

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

表7.1.7.9-2
タブ表記 新項目名(V9) 旧項目名(V8) 説明 新既定値(V9) 旧既定値(V8)
リスナ 平文のポート番号 平文ポート番号
OLF/TP通信で使用する平文のポート番号を指定します。全TPシステムで使用する全てのリスナポート番号の中で一意に指定してください。WebOTX 印刷キットなどから接続する場合はこのポート番号を指定します。

-
リスナ OLFTPリスナを起動する
TPシステム起動時にOLF/TPリスナを起動するかどうかを指定します。この設定の変更はTPシステム起動時に行うとエラーになります。運用管理コマンド(otxadmin)では、「OLFTPリスナを起動する/しない」をtrue/falseで設定します。

起動しない(false)
上限設定 最大同時接続クライアント数 利用可能な同時接続クライアント数
OLF/TP通信の最大同時接続クライアント数を指定します。複数のクライアントから同時にWebOTX Application Serverに接続する場合に指定してください。OLF/TPリスナ自身のアライブチェックでも1つ接続するため、その分を考慮した値を指定してください。設定の変更はTPシステム稼働中に行うとエラーになります。ここで指定した数を超えて新たにクライアントからの接続は行えません。

4

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

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

動的変更方法

図7.1.7.10-1
図7.1.7.10-1

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

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

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

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

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

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

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

ログ出力

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

Caution

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

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

図7.1.7.11-1
図7.1.7.11-1

図7.1.7.11-2
図7.1.7.11-2

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

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

Memo
設定を反映するにはアプリケーショングループの再起動が必要です。

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

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

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

となります。

Memo
TPシステム稼働中に設定を変更するとエラーになります。

Caution
プロセス停止時の終了処理を行うを設定し、アプリケーショングループまたはプロセスグループを強制停止した場合、後処理を一切行わず即時停止します。
停止時にログ採取を行わないため、障害解析に支障が出る可能性があります。

7.1.7.13. IIOPリスナ

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

表7.1.7.13-1
タブ表記 新項目名(V9) 旧項目名(V8) 説明 新既定値(V9) 旧既定値(V8)
リスナ 平文のポートを使用する 暗号化しない通信を行う
IIOP通信において平文のポートを使用するかどうかを設定します。SSLを設定できないOS・バージョンでは必ず平文のポートを指定する必要があります。 通常ドメイン作成時に指定します。運用管理コマンド(otxadmin)では、有効・無効をtrue/falseで設定します。

平文のポートを使用する(true)
リスナ 平文のポート番号 平文ポート番号 IIOP通信で使用する平文のポート番号を指定します。全TPシステムで使用する全てのリスナポート番号の中で一意に指定してください。 5151
リスナ 着呼時のIPアドレスの待ち受け指定 着呼時のIPアドレスの待ち受け設定をします。IPv4とIPv6の場合は両方で待ち受けます。 IPv4のみを指定した場合、IPv6の着呼待ちを行いません。また、IPv6のみの場合、IPv4の着呼待ちを行いません。 IPv4とIPv6
リスナ 通信管理部分のログを採取する - IIOPリスナの通信管理部分のログを採取するかどうかを設定します。 ログは以下のパスに固定で出力されます。 ${Instanceroot}/logs/tpsystem/iiopbase.log 詳細な通信ログを採取するため、性能劣化が発生します。トレースの採取が終わりましたら、設定は元に戻してください。 採取しない(false) -
リスナ 通信管理部分のログファイルサイズ - IIOPリスナの通信管理部分のログファイルサイズをキロバイト単位で設定します。ログが指定したサイズに達したら、再帰出力を行います。 10240KB -
リスナ 振り分け部分のログを採取する - IIOPリスナの振り分け部分のログを採取するかどうかを指定します。 ログは以下のパスに固定で出力されます。 ${Instanceroot}/logs/tpsystem/<システム名>_IIOPLsn.log 詳細な通信ログを採取するため、性能劣化が発生します。トレースの採取が終わりましたら、設定は元に戻してください。 採取しない(false) -
リスナ 振り分け部分のログファイルサイズ - IIOPリスナの振り分け部分のログファイルサイズをキロバイト単位で設定します。ログが指定したサイズに達したら、再帰出力を行います。 32KB -
リスナ IIOPAsyncのポート番号 - IIOPAsyncのポート番号を設定します。クライアント管理ライブラリやVBクライアント、CORBA Gatewayを使用している場合、クライアントと通信を行うために使用します。 クライアントとの間で制御的なコネクションを確立し、クライアントのアライブチェックや非同期メッセージ送信を行います。異常終了時はTPシステムの再起動が必要です。 0の場合、5219+(システムID)がポート番号として利用されます。システムIDはTPシステム毎に設定されている一意の値です。統合運用管理ツールを利用した場合、「TPシステム」ノードの「システム情報」でシステムIDの設定値を確認することができます。 - -
上限設定 最大同時接続クライアント数 利用可能な同時接続クライアント数 IIOP通信の最大同時接続クライアント数を指定します。複数のクライアントから同時にWebOTX Application Serverに接続する場合に指定してください。 IIOPリスナ自身のアライブチェックでも1つ接続するため、その分を考慮した値を指定してください。この設定の変更はTPシステム起動時に行うとエラーになります。 ここで指定した数を超えて新たにクライアントからの接続は行えません。 100
上限設定 AP応答監視タイマ AP応答監視タイマを秒単位で指定します。 2147483秒
上限設定 同時受付オペレーション数 IIOPリスナで同時に受け付けるオペレーション数を指定します。実行中のオペレーションとキューに滞留中のオペレーションの両方を含みます。 また、WebOTX内部で生成されるオペレーションも含みます。 -1を指定した場合は無制限となります。 -1
上限設定 更新通知リトライ回数 - IIOPリスナへの更新通知のリトライ回数を設定します。更新通知の送受信に失敗した場合、更新通知リトライ間隔で指定した間隔で、設定値の回数だけリトライを行います。 3回 -
上限設定 更新通知リトライ間隔 - IIOPリスナへの更新通知のリトライ間隔を設定します。更新通知の送受信に失敗した場合、設定値の間隔で、更新通知リトライ回数で指定した回数リトライを行います。 5秒 -
クライアント制御 クライアントとの無通信監視を行う クライアント無通信監視を行う クライアントとの無通信監視を行うかどうかを指定します。監視間隔を過ぎても新たなリクエストがクライアントから来ない場合、接続を切断します。運用管理コマンド(otxadmin)では、有効・無効をtrue/falseで設定します。 しない(false)
クライアント制御 クライアントとの無通信監視間隔 クライアント無通信監視間隔 クライアントからの通信の監視間隔を秒単位で設定します。 600秒
クライアント制御 クライアントのアライブチェックを行う クライアントアライブチェックを行う クライアントに異常が発生していないかどうかのアライブチェックを行うかどうかを指定します。 クライアントに異常が発生していると判断されると、自動的にコネクションの切断とリソースの解放が行われます。 クライアントアライブチェック機能を使うにはクライアントアプリケーションがクライアント管理ライブラリをリンクしている必要があります。 運用管理コマンド(otxadmin)では、有効・無効をtrue/falseで設定します。 しない(false)
クライアント制御 クライアントのアライブチェック間隔 クライアントアライブチェック間隔 クライアントのアライブチェック間隔を秒単位で設定します。 600秒
クライアント制御 送信データ分割サイズ 送信時のデータを分割するサイズをバイト単位の整数で設定します。 32768Bytes 4488Bytes
クライアント制御 接続要求最大保留数 クライアントからの接続要求を保留する数を設定します。この数をこえて同時にクライアントからのセッション接続要求はエラーとなります。 100 5
クライアント制御 1セッションあたりのリクエスト多重度 1プロセス当たりの多重度 1セッション当たりのリクエスト処理同時実行多重度を指定します。マルチスレッド構成のクライアントで1つのセッションから同時にリクエスト処理を行う場合、 この数を超えて同時リクエスト処理は行えません。WebOTX Application Serverの前段にWebサーバがある構成ではWebサーバがクライアントになるため、 この設定がWebサーバの同時リクエスト処理数(ThreadsPerChild)に対応する点に注意する必要があります。 128
SSL SSLを使用する IIOP通信においてSSLを使用するかどうかを指定します。SSLの使用を有効にするには、属性"クライアント認証なしのSSLを利用する"、 "クライアント認証なしのSSLポート番号"もしくは属性"クライアント認証ありのSSLを利用する"、"クライアント認証ありのSSLポート番号"が指定されている必要があります。 この設定の変更はTPシステム起動時に行うとエラーになります。 運用管理コマンド(otxadmin)では、有効・無効をtrue/falseで設定します。 しない(false)
SSL SSLライブラリ 使用するSSLライブラリを設定します。指定する場合は各ライブラリの設定項目も入力してください。 SSLを使用しない場合は[なし]を選択し属性"SSLを使用する"を無効に設定してください。また、この設定の変更はTPシステム起動時に行うとエラーになります。 OpenSSL
SSL クライアント認証なしのSSLを利用する SSLポート番号クライアント認証なし IIOP通信においてSSLポート番号クライアント認証なしのポートを使用するかどうか指定します。 しない(false)
SSL クライアント認証なしのSSLポート番号 SSLポート番号クライアント認証なし IIOP通信におけるSSLポート番号もしくはクライアント認証なし時のポート番号を指定します。全TPシステムで使用する全てのリスナポート番号の中で一意に設定してください。 -
SSL クライアント認証ありのSSLを利用する SSLポート番号クライアント認証あり IIOP通信においてSSLポート番号クライアント認証ありのポートを使用するかどうか指定します。この設定の変更はTPシステム起動時に行うとエラーになります。 しない(false)
SSL クライアント認証ありのSSLポート番号 SSLポート番号クライアント認証あり IIOP通信におけるSSLポート番号クライアント認証あり時のポート番号を指定します。全TPシステムで使用する全てのリスナポート番号の中で一意に設定してください。 -
SSL 認証情報が存在しない場合の接続を許可する 認証情報が存在しない場合の接続可否 SSL通信においてクライアント認証情報が送られない場合に接続を許可するかどうかを設定します。本機能を使用する場合、属性「SSLを使用する」が有効になっている必要があります。 運用管理コマンド(otxadmin)では、有効・無効をtrue/falseで設定します。 しない(false)
OpenSSL 秘密鍵ファイル名 サーバの秘密鍵を格納したファイル名を指定します。OpenSSLを利用する場合は必ず指定してください。証明書ファイル名と同じ名前を指定することもできます。 -
OpenSSL 証明書ファイル名 サーバの証明書を格納したファイル名を指定します。OpenSSLを利用する場合は必ず指定してください。秘密鍵ファイル名と同じ名前を指定することもできます。 -
OpenSSL 信頼するCAの証明書ファイル名 信頼するCAの証明書ファイル名を指定します。OpenSSLを利用する場合は必ず指定してください。 -
OpenSSL 証明書ファイルのパスワード サーバ認証で使用する証明書ファイルのパスワードを指定します。 -
SecureWare 鍵識別子 SecureWare/セキュリティパック の鍵識別子を指定します。SecureWare/セキュリティパック を利用する場合は必ず指定してください。 -
状態 状態 IIOPリスナの起動状態です。 状態と数値は以下の通りに対応します。
0:起動処理中
1:起動中
2:停止処理中
3:停止中
4:起動/停止処理失敗
-
状態 IIOPリスナを監視する アライブチェックモニタの自動登録を行う IIOPリスナを定期的に監視するかどうかを設定します。運用管理コマンド(otxadmin)では「IIOPリスナを監視する/しない」をtrue/falseで設定します。 する(true)
状態 IIOPリスナの監視間隔 監視間隔 IIOPリスナを監視する間隔を設定します。 30000ミリ秒
状態 非アライブ状態の際にイベントを発生させる間隔 イベントを連続発生させる間隔 監視対象リソースがアライブ中でない状態が続く場合にイベントを発生させる間隔を設定します。0を設定した場合イベントを発生しません。 0ミリ秒
状態 アライブチェックの受信待ちタイムアウト時間 受信待ちタイムアウト IIOPリスナへのアライブチェックの受信待ちタイムアウト時間を秒単位で指定します。 この時間が経過しても応答がない場合は、リスナが無応答状態であるとみなします。 平文のポートが有効であるときのみ無応答状態かどうかのアライブチェックが可能で、有効になっていない場合はアライブチェックを行いません。 5秒
状態 アライブチェックの開始時間 アライブチェックの開始時間(秒単位) TPモニタが起動してからIIOPリスナのアライブチェックを開始するまでの時間を設定します。 120秒

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. スレッド情報

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

* Linux版、Solaris版ではCPU時間取得機能を提供していません。
  1. 統合運用管理ツールよりドメインと接続します。
  2. ツリービューよりプロセスグループを選択します。
  3. リストビューより動作情報を選択します。
表7.1.8.1-1
説明
pid プロセスID
tid スレッドID
thno スレッド論理ID
  • MAIN:メインスレッド
  • RECV:内部受信スレッド
  • SEND:内部送信スレッド
  • 番号:ユーザスレッド
状態 スレッドステータス
  • APPROLOG:APプロログ呼び出し中
  • APEPILOG:APエピログ呼び出し中
  • THPROLOG:スレッドプロログ呼び出し中
  • THEPILOG:スレッドエピログ呼び出し中
  • TPPENTRY:TPPエントリ呼び出し中
  • ABORTEXIT:異常終了出口呼び出し中
  • RUNNING:制御スレッド実行中
  • WAIT:イベント待ち
  • STOPPED:スレッド停止
モジュール モジュール名
インタフェース インタフェース名
オペレーション オペレーション名
経過時間 実行時間(ミリ秒)
クライアント 接続クライアントIPアドレス
ユーザCPU時間 該当スレッドが現在までに消費したユーザモードCPU使用時間
ユーザCPU時間 該当スレッドが現在までに消費したユーザモードCPU使用時間
システムCPU時間 該当スレッドが現在までに消費したシステムモード(カーネルモード)CPU使用時間
CPU使用率 該当スレッドのCPU使用率(直近の情報採取間隔時間が対象)
情報採取間隔 前回の情報採取からの経過時間。最初の情報採取の場合は、プロセス起動時からの経過時間

7.1.8.2. プロセス情報

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

* Linux版ではCPU時間取得機能を提供していません。
* Solaris版ではメモリ情報取得機能を提供していません。
  1. 統合運用管理ツールよりドメインと接続します。
  2. ツリービューよりプロセスグループを選択します。
  3. リストビューより動作情報を選択します。
表7.1.8.2-1
説明
pid プロセスID
CPU使用率 該当プロセスの現在のCPU使用率(%)
CPU時間 該当プロセスが現在までに消費したCPU時間(ミリ秒)
ユーザCPU時間 該当プロセスが現在までに消費したユーザCPU時間(ミリ秒)
システムCPU時間 該当プロセスが現在までに消費したシステムCPU時間(ミリ秒)
コンテナ状態 該当プロセスの起動/停止処理がどこまで進んでいるかの状態
仮想メモリ使用量 該当プロセスの仮想メモリ使用量(KB)
物理メモリ使用量 該当プロセスの物理メモリ使用量(KB)

7.1.8.3. キュー情報

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

  1. 統合運用管理ツールよりドメインと接続します。
  2. ツリービューより[キュー]を選択します。
  3. リストビューよりキュー情報を選択します。
表7.1.8.3-1
説明
名前 キュー名
優先度 実行優先度
滞留数 現在のキュー滞留数

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

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

  1. 統合運用管理ツールよりドメインと接続します。
  2. ツリービューより[クライアントセッション]を選択します。
  3. リストビューよりクライアント情報を選択します。
表7.1.8.4-1
説明
クライアントID 論理端末ID
IPアドレス 接続クライアントIPアドレス
ホスト名 接続クライアントホスト名(逆引きをしない設定になっている場合は表示されません)
接続アプリケーショングループ名 接続アプリケーショングループ名
接続状態 接続状態
  • Not connected:未接続
  • Now accepting...:着呼処理中
  • Now connecting...:センタ発呼中
  • Connecting:接続中
  • Now disconnecting...:切断処理中
  • Trouble:トラブル
接続時間 接続経過時間(秒)

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

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


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

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

  2. ジャーナル採取の設定
    ジャーナルの採取は統合運用管理ツールで指定できます。 なお、ここで指定するファイルサイズは以下を目安として下さい。
    SIZE(MB) = 0.084nt + 0.028mt + 0.009gt
    

  3. ジャーナル採取
    WebOTXを再起動するとジャーナルの採取を始めます。 ジャーナル情報を格納したファイル(ジャーナルファイル)はカタログディレクトリ下のjnlディレクトリにjnl000x.logという名前で作られます(xは1〜3)。 ファイルはサイクリックに使用されます。 次のファイルに移る契機は指定された容量に達した時、もしくは、WebOTXを再起動した時です。

  4. ジャーナルの状態表示
    現在のジャーナルの採取状況はjnldispコマンドで確認できます。 コマンドの書式は以下の通りです。
    jnldisp [-C journaldir]
    

    出力例を以下に示します。
    ********** 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:ファイルサイズ(単位Mbyte)
    *** Current Journal File ***
    
    ジャーナルファイルが新しい順に表示されます。 最初に表示されるジャーナルファイルをカレントジャーナルファイルと言います(例ではjnl0002.logのファイル)。

  5. ジャーナルファイルの退避
    ジャーナルファイルはそのままではサイクリックに使用されてしまうため、定期的に退避する必要があります。 退避は単にコピーコマンドを使用するかもしくはjnlsaveコマンドを使用します。 コマンドはWindowsでは${AS_INSTALL}\Trnsv\bin、UNIXでは${AS_INSTALL}/Trnsv/commandにあります。 jnlsaveコマンドを使うと複数のジャーナルファイルを1つにまとめることができます。 また、使用中のカレントジャーナルファイル(ジャーナルが動作中の時のカレントジャーナルファイル)は、jnlsaveコマンドで一旦退避しないと編集できません。
    ジャーナル退避のコマンドの書式は以下の通りです。
    jnlsave -n SystemName [-C journaldir] [-d savefilename] [file_num]
    

  6. ジャーナルファイルの編集
    各種レポートを編集するために、ジャーナル編集コマンド(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]
    

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

  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使用時間(ユーザモード、カーネルモード)をレポート出力します。

* Linux版ではCPU情報出力機能を提供していません。
* HP-UX版ではCPU時間がOSの制限により秒単位で出力されます。

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

ジャーナルに蓄積された各オペレーションの実行時間データは、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種類のテーブルを出力します。

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

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

OperationJournal
図7.1.10.2-1

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

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

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

ProcessJournal
図7.1.10.2-2

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

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

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

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

「TPシステム」-「運用アシスタント」タブ-「稼働情報の採取と設定更新の間隔」

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

7.1.10.4. 補足事項

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

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

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

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

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

表7.1.11-1
コンポーネント 種別 項1 項2 項3 項4 項5 項6 項7 項8 項9 項10 項11 項12
LSN 通信リスナ 01 キューアウト時 キューID

端末ID 受信長

TXシーケンス番号

SPA長
02 キューイン時 キューID 端末ID
TXシーケンス番号



TX名


03 受信完了時 端末ID 受信長
エラーコード







04 送信完了時 端末ID 送信長
エラーコード







05 端末接続時 端末ID IPアドレス









06 端末切断時 端末ID










07 内部情報











08 内部情報











09 内部情報











10 内部情報












表7.1.11-2
コンポーネント 種別 項1 項2 項3 項4 項5 項6 項7 項8 項9 項10 項11
TPLIB サーバAP (ベースライブラリ) 01 OBJMNG呼び出し時(※1) TX名

端末ID/VDID

TXシーケンス番号

リトライカウント
02 API発行時
6 TPSRestart()








7 TPSAbort() abort種別







03 内部情報










04 内部情報










05 Commit/Rollback実行情報(※2) TX名 CANCEL(1)orCOMMIT(0) DBのCOMMIT/ROLLBACKする(1)orしない(0) TX完了時(1)orTXリスタート時(0) TXシーケンス番号





06 キューイン時

TX名 キューID TXシーケンス番号 端末ID




07 キューアウト時

TX名 キューID TXシーケンス番号 端末ID




08 OBJMNG戻り時(※1) TX名

端末ID/VDID TXシーケンス番号 終了コード(※3)





表7.1.11-3
コンポーネント 種別 項1 項2
OBJMNG サーバAP(オブジェクトマネージャ) 01 C++ Factoryオブジェクト TX名 call in
オブジェクト呼び出し時
call out
戻り時
02 C++ ステートレスオブジェクト TX名 call in
オブジェクト呼び出し時
call out
戻り時
03 C++ ステートフルオブジェクト TX名 call in
オブジェクト呼び出し時
call out
戻り時
06 Java Factoryオブジェクト TX名 call in
オブジェクト呼び出し時
call out
戻り時
07 Java ステートレスオブジェクト TX名 call in
オブジェクト呼び出し時
call out
戻り時
08 Java ステートフルオブジェクト TX名 call in
オブジェクト呼び出し時
call out
戻り時

表7.1.11-4
コンポーネント 種別 項1
USER サーバAP(ユーザ実装部) 01〜15 ユーザ指定 ユーザ指定

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

EventJournal
図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

実行例

[コマンドからの実行]

> 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

実行例

[コマンドからの実行]

> 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コマンドを用いてキューの状態を確認できます。

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

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

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

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

結果表示例:

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
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 ****************************************************

7.1.13. 運用アシスタント

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

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

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

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

設定箇所について

統合運用管理ツールから設定する場合の設定箇所は、 「TPシステム」、「アプリケーショングループ」、「プロセスグループ」、「モジュール」、「オペレーション」ノードにある「運用アシスタント」タブになります。

ただしV9.2より既定設定ではオペレーションの監視は診断サービスが行うため、多くの設定項目は既定では表示されていません。 統合運用管理ツールの左上のメニュー「システム」-「システム設定」をクリックし、画面表示の「属性の表示レベル」と「操作の表示レベル」を「詳細レベルの情報を表示」に変更してください。 すると各ノードに「運用アシスタント」タブが表示されます。

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

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

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

7.1.13.2. 多重度の最適化支援

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

多重度最適化支援機能ではシステムの稼働状況を解析し、多重度の増減を推奨、または自動変更します。 多重度の増減が推奨される場合は、以下のメッセージが統合運用管理ツールに通知され、イベントログ/syslog, webotx_agent.log(webotx_tpmmgr.log)に出力されます。 また、多重度不足時にはキューへのリクエスト滞留数とイベントジャーナルを採取します。

"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
[注] OTX20220001のトレースレベルがV9.2から変更になりました(INFO → DEBUG)

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

"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."

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

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

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

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

[注] 多重度最適化支援機能は、各プロセスグループで学習が完了後(プロセスグループ配下の全アプリケーションに属する全オペレーションで、稼働時間が学習期間を超過)に動作する点ご注意ください。

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

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

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

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

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

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

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

ここでスローダウン障害とは、「従来に比べて総体として遅くなった」状態を指します。 何回かのオペレーション実行がたまたま長いだけではスローダウン障害とは見なしません。

V9.2からV8までの統計情報によるスローダウン判定時間の自動設定に加えて、オペレーションごとにスローダウン判定時間を手動設定する機能を追加しました。スローダウン判定時間を切り替えるには、オペレーションのスローダウンの判定時間を自動計算するの設定を変更して下さい。

スローダウン判定時間の自動設定では、前回の情報取得までの統計情報と、最新の情報採取分(「稼働情報の採取と設定更新の間隔」分)のデータを比較します。 最新の情報取得で得た各オペレーションの実行回数が30回に満たない場合は、スローダウン検出を行わず、次回の情報取得分にマージさせます。 スローダウン障害の疑いがあっても、正常動作の可能性が多く残る場合は、スローダウン障害として検出しません。また、V8.2からは1秒以下でのスローダウンは検出しません。

スローダウン判定時間の手動設定では、稼働情報の採取と設定更新の間隔ごとにオペレーションの実行時間の平均を算出し、その時間が手動設定された値より大きい場合にスローダウンと判定します。
スローダウン障害を検出すると以下のメッセージを統合運用管理ツールに通知し、イベントログ/syslog,webotx_agent.log(webotx_tpmmgr.log)に出力します。 このとき、スタックトレースを5秒間隔3回でアプリケーションログに出力し、イベントジャーナルとキュー情報を ${INSTANCE_ROOT}\logs\tpsystem\logcollect\{日付10桁}\配下に出力します。 これらの情報を確認することで障害解析に役立ちます。また、スタックトレースの採取回数はチューニング可能です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

otxadmin> get --monitor tpsystem.IIOPListener.simultaneousRequestsCount-Current
プロセスグループの同時受付オペレーション数

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

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

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

プロセスグループで現在受け付けているオペレーション数は、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]
Object Broker Java ライブラリのプロパティ設定の一覧を取得します。


[実行方法]

ツリー表示で、「Object Broker コンフィグ」 を右クリックして「Java プロパティ設定一覧取得」を実行してください。

「実行」をクリックしてください。



2. Object Broker Java プロパティ設定値取得 [get-ospi-java-property]
Object Broker Java ライブラリのプロパティ設定値を取得します。


[実行方法]

ツリー表示で、「Object Broker コンフィグ」 を右クリックして「Java プロパティ設定値取得」を実行してください。

プロパティ名* :参照したいプロパティの名前を記述してください。

上記の値を入力して「実行」をクリックしてください。

*は入力必須項目です。



3. Object Broker Java プロパティ設定 [set-ospi-java-property]
Object Broker Java ライブラリにプロパティを設定します。設定された属性は以下のファイルに格納されます。

${INSTANCE_ROOT}/config/ObjectBroker/objava.conf


[実行方法]

ツリー表示で、「Object Broker コンフィグ」 を右クリックして「Java プロパティ設定」を実行してください。

プロパティ名* :設定するプロパティの名前を記述してください。

プロパティ値 : 設定するプロパティの値を記述してください。

上記の二つの値を入力して「実行」をクリックしてください。

*は入力必須項目です。

この「Object Broker Javaプロパティ設定」オペレーションで設定可能なプロパティの一覧は、[ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.10. Object Broker > 1.10.2. Object Broker JavaにおけるORBのプロパティ定義 ]を参照してください。



4. Object Broker Java プロパティの削除 [delete-ospi-java-property]
Object Broker Java ライブラリのプロパティを削除します。

ただし、共通タブおよびJava タブで設定可能なプロパティについては、このオペレーションで削除することはできません。


[実行方法]

ツリー表示で、「Object Broker コンフィグ」 を右クリックして「Java プロパティの削除」を実行してください。

プロパティ名* :削除するプロパティの名前を記述してください。

上記の値を入力して「実行」をクリックしてください。

*は入力必須項目です。



5. Object Broker C++プロパティ設定一覧取得 [get-cpp-properties]
Object Broker C++ライブラリのプロパティ設定の一覧を取得します。

ただし、共通タブ、cpp タブおよびObjectBroker MO で設定可能なプロパティについては、このオペレーションで取得することはできません。


[実行方法]

ツリー表示で、「Object Broker コンフィグ」 を右クリックして「C++プロパティ設定一覧取得」を実行してください。

「実行」をクリックしてください。



6. Object Broker C++プロパティ設定値取得 [get-cpp-property]
Object Broker C++ライブラリのプロパティ設定値を取得します。


[実行方法]

ツリー表示で、「Object Broker コンフィグ」 を右クリックして「C++プロパティ設定値取得」を実行してください。

プロパティ名* :参照したいプロパティの名前を記述してください。

上記の値を入力して「実行」をクリックしてください。

*は入力必須項目です。



7. Object Broker C++プロパティ設定 [set-cpp-property]
Object Broker C++ライブラリにプロパティを設定します。設定された属性は以下のファイルに格納されます。

${INSTANCE_ROOT}/config/ObjectBroker/orbconf

ただし、共通タブ、cpp タブおよびObjectBroker MO で設定可能なプロパティについては、このオペレーションで設定することはできません。


[実行方法]

ツリー表示で、「Object Broker コンフィグ」 を右クリックして「C++プロパティ設定」を実行してください。

プロパティ名* : 設定するプロパティの名前を記述してください。

プロパティ値 : 設定するプロパティの値を記述してください。

上記の二つの値を入力して「実行」をクリックしてください。

*は入力必須項目です。

この「Object Broker C++プロパティ設定」オペレーションで設定可能なプロパティの一覧は、[ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.10. Object Broker > 1.10.3. Object Broker C++における環境設定 ]を参照してください。



8. Object Broker C++プロパティの削除 [delete-cpp-property]
Object Broker C++ライブラリのプロパティを削除します。

ただし、共通タブ、cpp タブ、およびObjectBroker MO で設定可能なプロパティについては、このオペレーションで削除することはできません。


[実行方法]

ツリー表示で、「Object Broker コンフィグ」 を右クリックして「C++プロパティの削除」を実行してください。

プロパティ名* : 削除するプロパティの名前を記述してください。

上記の値を入力して「実行」をクリックしてください。

*は入力必須項目です。



9. Object Broker 共通プロパティ設定一覧取得 [get-ospi-properties]
Object Broker ライブラリのプロパティ設定の一覧を取得します。


[実行方法]

ツリー表示で、「Object Broker コンフィグ」 を右クリックして「共通プロパティ設定一覧取得」を実行してください。

「実行」をクリックしてください。



10. Object Broker 共通プロパティ設定値取得 [get-ospi-property]
Object Broker ライブラリのプロパティ設定値を取得します。


[実行方法]

ツリー表示で、「Object Broker コンフィグ」 を右クリックして「共通プロパティ設定値取得」を実行してください。

プロパティ名* :参照したいプロパティの名前を記述してください。

上記の値を入力して「実行」をクリックしてください。

*は入力必須項目です。



11. Object Broker 共通プロパティ設定 [set-ospi-property]
Object Broker ライブラリにプロパティを設定します。設定された属性は以下のファイルに格納されます。

${INSTANCE_ROOT}/config/ObjectBroker/orbconf

${INSTANCE_ROOT}/config/ObjectBroker/objava.conf

ただし、共通タブ、cpp タブおよびObjectBroker MO で設定可能なプロパティについては、このオペレーションで設定することはできません。


[実行方法]

ツリー表示で、「Object Broker コンフィグ」 を右クリックして「共通プロパティ設定」を実行してください。

プロパティ名* : 設定するプロパティの名前を記述してください。

プロパティ値 : 設定するプロパティの値を記述してください。

上記の二つの値を入力して「実行」をクリックしてください。

*は入力必須項目です。

この「Object Broker共通プロパティ設定」オペレーションで設定可能なプロパティの一覧は、[ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.10. Object Broker > 1.10.2. Object Broker JavaにおけるORBのプロパティ定義 ]および[ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.10. Object Broker > 1.10.3. Object Broker C++における環境設定 ]を参照してください。


12. Object Broker 共通プロパティの削除 [delete-ospi-property]
Object Broker ライブラリのプロパティを削除します。

ただし、共通タブ、cpp タブ、およびObjectBroker MO で設定可能なプロパティについては、このオペレーションで削除することはできません。


[実行方法]

ツリー表示で、「Object Broker コンフィグ」 を右クリックして「共通プロパティの削除」を実行してください。

プロパティ名* : 削除するプロパティの名前を記述してください。

上記の値を入力して「実行」をクリックしてください。

*は入力必須項目です。



7.2.1.3. Object Brokerサービスの操作

Dottedname : server.objectbrokerservice

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

1. Object Broker サービスの起動 [start-ospi]
Object Broker サービスを起動します。


[実行方法]

ツリー表示で、「Object Broker サービス」 を右クリックして「Object Broker サービスの起動」を実行してください。

「実行」をクリックしてください。



2. Object Broker サービスの停止 [stop-ospi]
Object Broker サービスを停止します。


[実行方法]

ツリー表示で、「Object Broker サービス」 を右クリックして「Object Broker サービスの停止」を実行してください。

「実行」をクリックしてください。



Dottedname : server.objectbrokerservice.oad

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

1. Oad サービスの起動 [invoke server.objectbrokerservice.oad.start]
Oad サービスを起動します。


[実行方法]

ツリー表示で、oad を右クリックして「Oad 起動」を実行してください。

「実行」をクリックしてください。



2. Oad サービスの停止 [invoke server.objectbrokerservice.oad.stop]
Oad サービスを停止します。


[実行方法]

ツリー表示で、oad を右クリックして「Oad 停止」を実行してください。

「実行」をクリックしてください。



Dottedname : server.objectbrokerservice.namesv

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

1. namesv サービスの起動 [invoke server.objectbrokerservice.namesv.start]
namesv サービスを起動します。


[実行方法]

ツリー表示で、namesv を右クリックして「名前サーバの起動」を実行してください。

「実行」をクリックしてください。



2. namesv サービスの停止 [invoke server.objectbrokerservice.namesv.stop]
namesv サービスを停止します。


[実行方法]

ツリー表示で、namesv を右クリックして「名前サーバの停止」を実行してください。

「実行」をクリックしてください。



Dottedname : server.objectbrokerservice.irsv

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

1. irsv サービスの起動 [invoke server.objectbrokerservice.irsv.start]
irsv サービスを起動します。


[実行方法]

ツリー表示で、irsv を右クリックして「IR サーバの起動」を実行してください。

「実行」をクリックしてください。



2. irsv サービスの停止 [invoke server.objectbrokerservice.irsv.stop]
irsv サービスを停止します。


[実行方法]

ツリー表示で、irsv を右クリックして「IR サーバの停止」を実行してください。

「実行」をクリックしてください。



Dottedname : server.objectbrokerservice.corbaloc

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

1. corbaloc サービスの起動 [invoke server.objectbrokerservice.corbaloc.start]
corbaloc サービスを起動します。


[実行方法]

ツリー表示で、corbaloc を右クリックして「Corbaloc サーバの起動」を実行してください。

「実行」をクリックしてください。



2. corbaloc サービスの停止 [invoke server.objectbrokerservice.corbaloc.stop]
corbaloc サービスを停止します。


[実行方法]

ツリー表示で、corbaloc を右クリックして「Corbaloc サーバの停止」を実行してください。

「実行」をクリックしてください。



Dottedname : server.objectbrokerservice.cnamesv

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

1. cnamesv サービスの起動 [invoke server.objectbrokerservice.cnamesv.start]
cnamesv サービスを起動します。


[実行方法]

ツリー表示で、cnamesv を右クリックして「キャッシュ名前サーバの起動」を実行してください。

「実行」をクリックしてください。



2. cnamesv サービスの停止 [invoke server.objectbrokerservice.cnamesv.stop]
cnamesv サービスを停止します。


[実行方法]

ツリー表示で、cnamesv を右クリックして「キャッシュ名前サーバの停止」を実行してください。

「実行」をクリックしてください。



Dottedname : server.objectbrokerservice.oadj

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

1. OadJ サービスの起動 [start-oadj]
OadJ サービスを起動します。


[実行方法]

ツリー表示で、oadj を右クリックして「OadJ サービスの起動」を実行してください。

「実行」をクリックしてください。



2. OadJ サービスの停止 [stop-oadj]
OadJ サービスを停止します。


[実行方法]

ツリー表示で、oadj を右クリックして「OadJ サービスの停止」を実行してください。

「実行」をクリックしてください。



3. インプリメンテーションの一覧 [listimpl]
サーバのインプリメンテーション一覧を表示します。


[実行方法]

ツリー表示で、oadj を右クリックして「インプリメンテーションの一覧」を実行してください。

「実行」をクリックしてください。



4. インプリメンテーションの登録 [instimpl]
サーバのインプリメンテーションを登録します。


[実行方法]

ツリー表示で、oadj を右クリックして「インプリメンテーションの登録」を実行してください。

インプリメンテーション名* : 登録するインプリメンテーション名を指定します。

コマンドライン* : サーバを起動するときのコマンドラインの文字列を指定します。

例)

java .classpath C:\test\sample.jar sampleServer

サーバの活性化方針* : サーバの活性化方針を以下の三つから選択してください。

上記の三つの値を入力して「実行」をクリックしてください。

*は入力必須項目です。



5. インプリメンテーションの削除 [rmimpl]
サーバのインプリメンテーションを削除します。


[実行方法]

ツリー表示で、oadj を右クリックして「インプリメンテーションの削除」を実行してください。

インプリメンテーション名* : 削除するインプリメンテーション名を指定します。

上記の値を入力して「実行」をクリックしてください。

*は入力必須項目です。



Dottedname : server.objectbrokerservice.ospprxy

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

1. ospprxy サービスの起動 [start-ospprxy]
ospprxy サービスを起動します。


[実行方法]

ツリー表示で、ospprxy を右クリックして「ospprxy サービスの起動」を実行してください。

「実行」をクリックしてください。



2. ospprxy サービスの停止 [stop-ospprxy]
ospprxy サービスを停止します。


[実行方法]

ツリー表示で、ospprxy を右クリックして「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.  ドメインを作成します。

ドメインを新規作成します。既存のドメインも使用できます。
ドメインの作成手順については[ 3. ドメイン > 3.2. ドメインの作成・削除 ]を参照してください。

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

ドメイン外のObject Brokerの設定をドメイン内で動作するObject Brokerを使用するように変更します。
ドメイン内で動作するObject Brokerの設定は次のように確認します。
otxadmin> get server.objectbrokerservice.oad.OadPort
otxadmin> get server.objectbrokerservice.namesv.NameServicePort
server.objectbrokerservice.oad.OadPortの値を設定名”OadPort”に設定します。
server.objectbrokerservice.namesv.NameServicePortの値を設定名”CorbalocDefaultPort”に設定します。

表7.2.2.1-1
設定名 意味
OadPort oad の使用するポート番号を指定します。ORB 通信するすべてのホストで同一のポート番号を使う必要があります。未指定時の既定値は9825 です。運用開始後にoad のポート番号を変更すると、それ以前に作ったオブジェクトを呼び出すことができなくなります。変更するときは、oad やnamesv およびすべてのORB アプリケーションをいったん終了してから変更してください。
CorbalocDefaultPort URL でポート番号を指定しなかったときの値を設定します。未設定時は2809 です。
NameServiceRoundRobin on を設定します。名前サーバのラウンドロビン拡張機能が有効になります。同一の名前でresolve を呼んだ場合、呼び出すたびに別のオブジェクトを返すためのWebOTX Object Broker 独自の機能です。

(注)ドメイン外で名前サーバを動作させて、ドメイン内のアプリケーションと連携させる場合、NameServiceRoundRobinの設定変更(on を設定する)が必要です。ドメイン内では、NameServiceRoundRobin=trueがデフォルトですが、ドメイン外ではNameServiceRoundRobinの指定なし(off)がデフォルトであるためです。
ドメイン外のObject Brokerの設定をドメイン内で動作するObject Brokerを使用するように変更します。
ドメイン内で動作するObject Brokerの設定は次のように確認します。

設定項目の詳細は[ WebOTX Object Broker JavaTM > 運用ガイド > 1. 環境設定について ]を参照してください。

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

root ユーザで以下のコマンドを実行します。
# /etc/init.d/ObjectSpinner start (HP-UX の場合 /sbin/init.d/ObjectSpinner start)
名前サーバ、IRサーバを起動するか否かについては[ WebOTX Object Broker JavaTM > 運用ガイド > 3. Object Brokerの起動/終了について ]を参照してください。

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

WebOTX運用ユーザで実行します。
otxadmin> start-domain domain_name

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

プロセスグループ作成時にWebOTX のバージョンを旧バージョンに変更します。
詳細は [ 7.1. TPシステム > 7.1.3. 操作・状態確認(プロセスグループ) > 7.1.3.1. 作成・削除 ] を参照してください。

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

ドメイン起動
ドメインを起動するためには、通常のドメインと同様にotxadmin コマンドを使用します。
WebOTX 運用ユーザで実行します。
otxadmin> start-domain domain_name
ドメイン停止
ドメインを停止するためには、通常のドメインと同様にotxadmin コマンドを使用します。
WebOTX 運用ユーザで実行します。
otxadmin> stop-domain domain_name

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サーバが停止します。

    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. プロパティを参照する場合は、メニューから「プロパティ一覧の取得」を選択し、表示されるダイアログで「実行」ボタンをクリックします。

    JMSサービスのプロパティ参照
    図7.3.1.3-1

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

    JMSサービスのプロパティ設定
    図7.3.1.3-2

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

運用管理コマンド(otxadmin)からの操作
属性の参照・設定と同様にgetコマンド、setコマンドを利用します。

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

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

表7.3.1.4-1
表示名 説明
Broker ID JMSサーバインスタンス識別子。ローカルのJMSサーバのもののみ表示します。
Address JMSサーバのアドレス。<ホスト名>:<ポート番号>の形式で表示します。
State JMSサーバの状態。
OPERATING : ローカルのJMSサーバの場合は、起動状態であることを示します。リモートのJMSサーバの場合は、通信が確立できていることを示します。
BROKER_DOWN : リモートのJMSサーバが停止しているか、通信が確立できていない状態を示します。


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

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「JMSサービス」を選択し、右クリックするか、あるいは、メニューバーの[操作] を選択します。
  2. 表示されるメニューから「JMSサーバの一覧の取得」を選択すると、クラスタを構成する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クライアントのコネクションを確認する場合に利用します。表示する情報は次のとおりです。

表7.3.1.5-1
表示名 説明
Connection ID コネクションID
Client ID クライアントID
User ユーザ名
Service コネクションサービス名。コネクションサービスには次のものがあります。
jms:JMSのコネクションサービス
ssljms:JMSのSSLコネクションサービス
admin:管理用のコネクションサービス
ssladmin:管理用のSSLコネクションサービス
Producers プロデューサ数
Consumers コンシューマ数
Host ホスト名(IPアドレス)
Port ポート番号
Max Memory 最大メモリサイズ。「JMSクライアントメモリ情報採取(enableClientMetrics)」をtrueにしている場合、通常ユーザのコネクションに対する情報を表示します。
Current Memory 現在のメモリサイズ。「JMSクライアントメモリ情報採取(enableClientMetrics)」をtrueにしている場合、通常ユーザのコネクションに対する情報を表示します。
Peak Memory ピーク時のメモリサイズ。「JMSクライアントメモリ情報採取(enableClientMetrics)」をtrueにしている場合、通常ユーザのコネクションに対する情報を表示します。


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

  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 --wojmsCloseType 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. 送信先の現時点の状態などを知りたい場合は、メニューから「情報取得」を選択し、表示されるダイアログで「実行」ボタンをクリックします。

    送信先の情報取得
    図7.3.2.4-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.5. 送信先の一時停止・再開

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

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

    送信先の一時停止・再開
    図7.3.2.5-1

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

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


運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 送信先の一時停止をする場合は、以下のコマンドを使用します。
    otxadmin> invoke server.jms-service.jms-physical-destination.<送信先名>.pause <停止タイプ>
    停止タイプには、1から3の数字を指定します。それぞれの数字は、次を意味します。
    表7.3.2.5-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.6. メッセージ一覧の取得

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

表7.3.2.6-1
表示名 説明
Timestamp タイムスタンプ。JMSTimestamp ヘッダフィールドの値です。long 値を「yyyy/MM/dd HH:mm:ss.SSS」形式に変換して表示します。
Type メッセージタイプ。次のタイプが存在します。
TEXT_MESSAGE : javax.jms.TextMessage のメッセージ
BYTES_MESSAGE : javax.jms.BytesMessage のメッセージ
MAP_MESSAGE : javax.jms.MapMessage のメッセージ
STREAM_MESSAGE : javax.jms.StreamMessage のメッセージ
OBJECT_MESSAGE : javax.jms.ObjectMessage のメッセージ
MESSAGE : javax.jms.Message のメッセージ
MessageID メッセージID。JMSMessageID ヘッダフィールドの値です。
CorrelationID 相関ID。JMSCorrelationID ヘッダフィールドの値です。
DeliveryMode 配信モード。JMSDeliveryMode ヘッダフィールドの値です。
Expiration 有効期限。JMSExpiration ヘッダフィールドの値です。
State JMSサーバに存在するメッセージの状態。送信先がキューの場合のみ表示します。次の状態が存在します。
INITIAL : 配信対象のコンシューマが決定していない状態
ROUTED : 配信対象のコンシューマが決定した状態
DELIVERED : コンシューマにメッセージを配信した状態
CONSUMED : コンシューマでメッセージを受信した状態
ACKED : コンシューマからの応答確認(ACKNOWLEDGE)が返ってきた状態
DeliveryCount 配信回数。JMSXDeliveryCount プロパティの値です。送信先がキューの場合のみ表示します。
Priority 優先順位。JMSPriority ヘッダフィールドの値です。もっとも低い順位が 0 で、もっとも高い順位が 9 です。
MessageProperty メッセージプロパティ
MessageBody メッセージボディ。指定された場合のみ表示します。表示内容はメッセージタイプに応じて次のようになっています。
TEXT_MESSAGE : javax.jms.TextMessage のメッセージ
BYTES_MESSAGE、MAP_MESSAGE、STREAM_MESSAGE : メッセージボディのサイズのみ表示
OBJECT_MESSAGE : javax.jms.ObjectMessage のメッセージ
MESSAGE : (表示なし)

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

  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.7. 指定メッセージパージ・メッセージ全件パージ

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

  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.8. 永続サブスクリプションの操作(トピックのみ)

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

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

    永続サブスクリプションの操作
    図7.3.2.8-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.9. JMSメッセージの送信

環境構築時の確認や、コンシューマアプリケーションの受信動作確認など、簡単なメッセージ送信に利用できます。1回のメッセージ送信操作で送信できるメッセージは、1件です。

送信メッセージに設定できる項目と既定値は、次のとおりです。設定項目の()内の記述は、対応するヘッダフィールド名を示します。

表7.3.2.9-1
設定項目 説明 既定値
メッセージタイプ 送信するメッセージのタイプ
次のタイプが送信可能。
TextMessage : メッセージボディにStringを含むもの
Message : メッセージボディのない軽量なメッセージ
BytesMessage : メッセージボディにバイト配列を含むもの
TextMessage
メッセージボディの指定方法 メッセージボディの指定方法
text : メッセージボディに指定された文字列をボディそのものとして設定
file : メッセージボディに指定された文字列をファイル名として、指定されたファイルの内容をメッセージボディに設定
text
メッセージボディ メッセージボディ
TextMessageの場合 : メッセージボディタイプのtext、fileをサポート。file を指定した場合、文字コードはプラットフォームのデフォルトエンコーディングなる
Messageの場合 : メッセージボディなし。指定されていても無視
BytesMessageの場合 : メッセージボディタイプはfileのみ有効。指定されたファイルの内容をバイト配列に変換して設定
-
配信モード (JMSDeliveryMode) メッセージを永続化するかどうか
PERSISTENT : 永続化する
NON_PERSISTENT : 永続化しない
PERSISTENT
有効期限 (JMSExpiration) メッセージの有効期限 (ミリ秒)
0 (有効期限なし)
優先順位 (JMSPriority) メッセージの優先順位 (0-9)
4
相関ID (JMSCorrelationID) メッセージを対応付けるための文字列
指定可能な値は、Stringのみ。
-
応答用送信先 (JMSReplyTo) メッセージを受信したコンシューマが返信する送信先
-
応答用送信先のタイプ 応答用送信先のタイプ
queue : キュー
topic : トピック
queue
タイプ (JMSType) 任意の文字列
-
配信遅延時間 配信遅延時間
WebOTX JMS固有の拡張機能で、相対時間(秒)での指定のみ可能。
0 (遅延時間なし)
メッセージプロパティ メッセージプロパティ
設定可能なプロパティ値は、Stringのみ。
-


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

  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.10. メッセージ移動

送信先に滞留している通常メッセージや、不達メッセージ(再配信回数の上限を超えたメッセージ)、有効期限切れメッセージを別の送信先に移動する場合に利用します。移動後のメッセージはメッセージIDなどが変わります。移動によるメッセージヘッダや、プロパティの変更内容は次のとおりです。

表7.3.2.10-1
ヘッダ / プロパティ 移動対象
通常メッセージ / 永続サブスクリプション 不達メッセージ 有効期限切れメッセージ
JMSDestination 移動先の送信先
元の送信先の情報は、WOJMSOriginalDestinationName に設定します。
移動先の送信先
元の送信先の情報は、WOJMSOriginalDestinationName に設定します。
移動先の送信先
元の送信先の情報は、WOJMSOriginalDestinationName に設定します。
JMSDeliveryMode 変更しない WOJMSOriginalPersistentから復元 WOJMSOriginalPersistentから復元
JMSExpiration 変更しない WOJMSOriginalExpirationから復元 クリア(0を設定)
JMSPriority 変更しない 変更しない 変更しない
JMSMessageID 新規メッセージIDに変更
元の情報は、WOJMSOriginalMessageID に設定します。
WOJMSOriginalMessageIDから復元 WOJMSOriginalMessageIDから復元
JMSTimestamp 移動した時刻に変更 WOJMSOriginalTimeStampから復元 WOJMSOriginalTimeStampから復元
JMSCorrelationID 変更しない 変更しない 変更しない
JMSReplyTo 変更しない 変更しない 変更しない
JMSType 変更しない 変更しない 変更しない
JMSRedelivered 変更しない 変更しない 変更しない
WOJMSDelayTime 変更しない WOJMSOriginalDelayTimeから復元 WOJMSOriginalDelayTimeから復元
WOJMSOriginalMessageID 移動前のメッセージID 削除 削除
WOJMSOriginalDestinationName 移動前の送信先名 移動前の送信先名 移動前の送信先名
WOJMSOriginalExpiration - 削除 削除
WOJMSOriginalTransactionID - 削除 削除
WOJMSOriginalPersistent - 削除 削除
WOJMSOriginalTimeStamp - 削除 削除
WOJMSOriginalDelayTime - 削除 削除
WOJMSDeletedReason - 削除 削除
そのほかのメッセージプロパティ 変更しない (すべてのプロパティをそのまま設定) 変更しない (すべてのプロパティをそのまま設定) 変更しない (すべてのプロパティをそのまま設定)

備考 :

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

  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 redelivery DMQ MyQueue

    例) トピック MyTopic の永続サブスクリプション Sub1 からキュー MyQueue へ移動する場合
    otxadmin> move-jmsdest-messages --msgmovedur Sub1 --msgmovecid Client1 MyTopic MyQueue


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


7.3.2.11. 滞留メッセージの優先順位変更

送信先に滞留しているメッセージの優先順位を、運用操作により変更する場合に利用します。

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

  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リソース」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。

    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. メニューから「削除」を選択し、表示されるダイアログで「実行」ボタンをクリックします。

    JMSリソースの削除
    図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サービスに関する統計情報の表示が可能になります。

    JMSサービスの統計情報取得
    図7.3.4-1

  4. ツリービューより、「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「統計情報」-「<ドメイン名>」-「JMSサービス」を選択します。リストビューの「統計属性」で統計情報を参照できます。
  5. 物理的な送信先を登録している場合は、「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「統計情報」-「<ドメイン名>」-「JMSサービス」-「送信先名」-「<送信先名>」を選択することで、送信先に関する情報も参照できます。
  6. 4の状態で、「統計情報採取開始」の操作を選択することにより、統計情報のグラフ表示を行うことができます。

    JMSサービスの統計情報採取開始
    図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. 採取可能なパフォーマンス情報 > JMSServiceStatsJMSPhysicalDestinationStats ]を参照してください。

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サービスを開始する場合は次のコマンドを実行します。

otxadmin> start-transaction-service
あるいは
otxadmin> invoke server.transactionservice.start

3.  逆にTransactionサービスを停止する場合は次のコマンドを実行します。

otxadmin> stop-transaction-service
あるいは
otxadmin> invoke  server.transactionservice.stop

7.4.2. リソースの登録・削除

2フェーズコミットの途中で障害が発生した場合、Transactionサービスは、トランザクションのリカバリ処理を実行します。リカバリ処理で使用するデータベースやコネクタリソースの情報を、Transactionサービスのリソースとして定義します。ここでは、そのリソースの登録・削除操作の手順について説明します。

7.4.2.1. 統合運用管理ツールからリソース登録・削除

JDBCリソース、JCAリソース、C++ XAリソースの登録・削除を行う場合は、次の手順で操作を行ってください。JDBCリソースは、「JDBCデータソースのテスト」操作を行った時や、トランザクション実行時に自動的に生成されます。そのため、登録作業を省略することができます。

1.   統合運用管理ツールよりドメインと接続します。

2.   ツリービューより「<ドメイン名>」−「アプリケーションサーバ」−「Transactionサービス」−「リソース」を選択します。

3.   右クリックメニューより次のいずれかのオペレーションを実行します。

「JDBCリソースの登録」、または、「JDBCリソースの削除」
「JCAリソースの登録」、または、「JCAリソースの削除」
「XAリソースの登録(C++)」、または、「XAリソースの削除」

4.   表示された画面で、生成、または、削除するリソースの名前と、必要な情報を設定してください。設定内容の詳細は、[ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.9. Transactionサービス > 1.9.3. Transactionサービスに関する設定 ]を参照してください。

5.   自動生成されたJDBCリソースを表示するためには、「リソース」の「リソースの再表示」オペレーションを実行します。

また、AP用C++ XAリソースの登録・削除を行う場合は、次の手順で操作を行ってください。TransactionサービスとAPで同じC++ XAリソースを使用する場合は、AP用C++ XAリソースの登録作業を行う必要はありません。

1.  ツリービューより「<ドメイン名>」−「アプリケーションサーバ」−「Transactionサービス」−「リソース」−「cppxa-resource」−「C++XAリソース名」を選択します。

2.   右クリックメニューより次のいずれかのオペレーションを実行します。

「AP用C++XAリソースの登録」、または、「AP用C++XAリソースの削除」

3.   表示された画面で、生成、または、削除するリソースの名前と、必要な情報を設定してください。設定内容の詳細は、[ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.9. Transactionサービス > 1.9.3. Transactionサービスに関する設定 ]を参照してください。

7.4.2.2. コマンドからリソース登録・削除

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

2.   リソースの登録、または、リソースの削除コマンドを実行します。

リソースの登録
otxadmin> create-ts-jdbc-resource リソース名
otxadmin> create-ts-jca-resource リソース名
otxadmin> create-ts-cppxa-resource --xaresourcetype XAリソースタイプ  --openstring オープン文字列  リソース名
otxadmin> create-ts-cppxa-ap-resource --xaresourcetype XAリソースタイプ  --openstring オープン文字列  上位のC++XAリソース名  登録するリソース名

リソースの削除
otxadmin> delete-ts-jdbc-resource  リソース名
otxadmin> delete-ts-jca-resource リソース名
otxadmin> delete-ts-cppxa-resource リソース名
otxadmin> delete-ts-cppxa-ap-resource 上位のC++ XAリソース名  削除するリソース名

3.   自動生成されたリソースを表示します。

otxadmin> invoke server.transactionservice.resources.refresh

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

項目

説明

表示対象となるトランザクション情報

OFF (レベル0) 統計情報は基本的に採取しません。 次の状態のトランザクション情報のみ表示します。
  • StatusCommitted
  • StatusRolledBack
  • StatusUnknown
LOW (レベル1) Transactionサービスで提供する統計情報のうち、障害レベルのものについてのみ採取します。レベルOFFの場合に比べ、若干のトランザクション性能劣化が発生します。 次の状態のトランザクション情報のみ表示します。
  • StatusCommitting
  • StatusRollingBack
  • StatusCommitted
  • StatusRolledBack
  • StatusUnknown
HIGH (レベル2) Transactionサービスで提供する統計情報の全てを採取します。レベルLOWの場合に比べ、大きなトランザクション性能劣化が発生します。 トランザクションの状態に関わらず全てのトランザクション情報を表示します。

これらのレベルについては次の手順で参照することができます。


図7.4.3.1-1

統合運用管理ツールを用いたトランザクション情報採取レベルの参照

1.   統合運用管理ツールよりドメインと接続します。

2.   ツリービューより「<ドメイン名>」−「アプリケーションサーバ」−「Transactionサービス」−「Transaction情報」を選択すると右側に表示されます。

コマンドを用いたトランザクション情報採取レベルの参照

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

2.   次のコマンドを実行します。0〜2の数字が戻り値として表示されます。

otxadmin> get server.transactionservice.tstxlist.monitor-level

なお、「Transaction情報」(tstxlist)からトランザクション情報採取レベルを設定することはできません。設定については上の絵の中に書かれているように「モニタリングサービス」のところから実施する必要があります。詳細は[ リファレンス集 運用管理・設定編 > 3. モニタリング ]を参照してください。ここでは簡単に方法を記載します。

統合運用管理ツールを用いたトランザクション情報採取レベルの操作

1.   統合運用管理ツールよりドメインと接続します。

2.   ツリービューより「<ドメイン名>」−「アプリケーションサーバ」−「モニタリングサービス」−「モジュールモニタリングレベル」を選択します。

3.   右側に表示される項目のうち、「transactionserviceモニタリングレベル」のところにOFF/LOW/HIGHのいずれかを指定します。

コマンドを用いたトランザクション情報採取レベルの参照

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

2.   次のコマンドのいずれかを実行します。’=’の後に「OFF」「LOW」「HIGH」のいずれかの文字列を指定します。

otxadmin> set server.monitoring-service.module-monitoring-levels.transaction_service=OFF
otxadmin> set server.monitoring-service.module-monitoring-levels.transaction_service=LOW
otxadmin> set server.monitoring-service.module-monitoring-levels.transaction_service=HIGH

次に稼動中のトランザクション一覧の取得方法を記載します。

7.4.3.2. 統合運用管理ツールからトランザクション一覧の取得操作

1.   統合運用管理ツールよりドメインと接続します。

2.   ツリービューより「<ドメイン名>」−「アプリケーションサーバ」−「Transactionサービス」−「Transaction情報」を選択し右クリックします。

3.   「Transaction一覧取得」を選ぶとサーバに対して処理要求を実施します。

4.   「Transaction情報」ツリーの下に各トランザクション情報が表示されます。

7.4.3.3. コマンドからトランザクション一覧の取得操作

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

2.   次のコマンドを実行します。

otxadmin> invoke server.transactionservice.tstxlist.txlist

3.   2.で実行したコマンドはサーバから情報を取得しただけなので、一覧を表示させるにはさらに次のコマンドを実行します。

otxadmin> list server.transactionservice.tstxlist.*

4.   3.を実行すると次のようにリスト表示されます。

server.transactionservice.tstxlist.0871227903690002
server.transactionservice.tstxlist.0910828752910004
数字の列がトランザクション識別子です。さらに例として次のようにすると各トランザクションの情報を見ることができます。
otxadmin> get server.transactionservice.tstxlist.*.*
次のように表示されます。ワイルドカードの部分を変えると表示内容を限定することができます。
server.transactionservice.tstxlist.0871227903690002.otid = 980614.3030323030354170723036323132363037303030303431343064726F6E676F
server.transactionservice.tstxlist.0871227903690002.owner = Recover
server.transactionservice.tstxlist.0871227903690002.starttime = 2005/4/6 21:26:9
server.transactionservice.tstxlist.0871227903690002.status = StatusUnknown
server.transactionservice.tstxlist.0871227903690002.stxid = 0871227903690002
server.transactionservice.tstxlist.0910828752910004.otid = 69637.7473430000000000000000000000000000002394000000004254DF1F000000004255211B00000004
server.transactionservice.tstxlist.0910828752910004.owner = Active
server.transactionservice.tstxlist.0910828752910004.starttime = 2005/4/7 21:1:31
server.transactionservice.tstxlist.0910828752910004.status = StatusUnknown
server.transactionservice.tstxlist.0910828752910004.stxid = 0910828752910004

7.4.4. トランザクションの操作

各トランザクションに対して強制的に完了操作を行うことができます。その手順について説明します。

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

1.   統合運用管理ツールよりドメインと接続します。

2.   ツリービューより「<ドメイン名>」−「アプリケーションサーバ」−「Transactionサービス」−「Transaction情報」−「<トランザクション識別子>(数字の部分)」を選択し右クリックします。右側にはトランザクションに関する情報が表示されます。

3.   該当するトランザクションに対して行いたい処理に応じてメニューを選択します。ただしトランザクションの状態に応じて実行可能なコマンドの種類は限定されますのでご注意ください。


図7.4.4.1-1

7.4.4.2. コマンドから操作

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

2.   次のコマンドを実施すると稼動中トランザクションの識別子一覧を見ることができます。

otxadmin> get server.transactionservice.tstxlist.*.stxid

3.   次のコマンドを実行してトランザクションの完了処理を行うことができます。<トランザクション識別子>のところには2.のコマンドで指定したstxid相当の数字を指定します。

強制コミットを行う場合
otxadmin> commit-transaction <トランザクション識別子>
強制ロールバックを行う場合
otxadmin> rollback-transaction <トランザクション識別子>
破棄(フォゲット)を行う場合
otxadmin> forget-transaction <トランザクション識別子>
強制削除を行う場合
otxadmin> delete-transaction <トランザクション識別子>


なお、強制削除を行うとトランザクションの継続処理を全く実施せずにトランザクション情報を削除してしまいますので、場合によってはトランザクション全体としての結果に矛盾が生じる場合があります。慎重に行ってください。

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.   ツリービューより次のいずれかを選択します。

<ドメイン名>−「アプリケーションサーバ」−「Transactionサービス」−「リソース」−「jdbc-resource」−「リソース名」
<ドメイン名>−「アプリケーションサーバ」−「Transactionサービス」−「リソース」−「jca-resource」−「リソース名」
<ドメイン名>−「アプリケーションサーバ」−「Transactionサービス」−「リソース」−「cppxa-resource」−「リソース名」

3.   右クリックメニューより次のいずれかのオペレーションを実行します。

「リソースの開始」、または、「リソースの停止」

7.4.5.3. コマンドからリソースの開始と停止

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

2.   リソースの開始、または、リソースの停止を実行します。

リソースの開始
otxadmin>  invoke server.transactionservice.resources.jdbc-resource.リソース名.start
otxadmin>  invoke server.transactionservice.resources.jca-resource.リソース名.start
otxadmin>  invoke server.transactionservice.resources.cppxa-resource.リソース名.start

リソースの停止
otxadmin>  invoke server.transactionservice.resources.jdbc-resource.リソース名.stop
otxadmin>  invoke server.transactionservice.resources.jca-resource.リソース名.stop
otxadmin>  invoke server.transactionservice.resources.cppxa-resource.リソース名.stop

7.4.5.4. トランザクションの手動リカバリ操作

トランザクションのリカバリ操作は、通常、本マニュアルの[ 3. ドメイン > 3.9. 統計情報の取得 > 3.9.4. Transactionサービス(JTA)統計情報の取得 > 3.9.4.3. トランザクションの操作 ]の説明に従って実行します。ただし、まれにDBMS間との状態不一致などによりトランザクションマネージャ側でトランザクションの結果を自動追跡できなくなる場合があります。そういう状態になった場合には、リソース毎にリカバリ操作を実行します。

なお、[ 3. ドメイン > 3.9. 統計情報の取得 > 3.9.4. Transactionサービス(JTA)統計情報の取得 > 3.9.4.3. トランザクションの操作 ]で表示されるトランザクションの情報は、リソース毎の操作では表示されません。

7.4.5.5. 統合運用管理ツールからトランザクションのリカバリ操作

1.   統合運用管理ツールよりドメインと接続します。

2.   ツリービューより次のいずれかを選択します。

<ドメイン名>−「アプリケーションサーバ」−「Transactionサービス」−「リソース」−「jdbc-resource」−「リソース名」
<ドメイン名>−「アプリケーションサーバ」−「Transactionサービス」−「リソース」−「jca-resource」−「リソース名」
<ドメイン名>−「アプリケーションサーバ」−「Transactionサービス」−「リソース」−「cppxa-resource」−「リソース名」

3.   右クリックメニューより「トランザクションの一覧表示」オペレーションを実行します。

オペレーションの実行結果として、次のような情報が表示されます。
   ShortTxId=[aaaa]status=[Heuristic]Xid=[formatID=xxxx1,gtrid=yyyy2,bqual=zzzz3]owner=[0]
   ShortTxId=[bbbb]status=[Heuristic]Xid=[formatID=xxxx1,gtrid=yyyy2,bqual=zzzz3]owner=[0]
   ShortTxId=[cccc]status=[Heuristic]Xid=[formatID=xxxx1,gtrid=yyyy2,bqual=zzzz3]owner=[0]

4.   「トランザクションの一覧表示」で表示された “ShortTxId”を指定して次のいずれかのオペレーションを実行します。

「トランザクションのコミット」
「トランザクションのロールバック」
「トランザクションのフォゲット」
「トランザクションの削除」

7.4.5.6. コマンドからトランザクションのリカバリ操作

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

2.   トランザクションの一覧を表示します。

otxadmin> invoke server.transactionservice.resources.jdbc-resource.リソース名.list
otxadmin> invoke server.transactionservice.resources.jca-resource.リソース名.list
otxadmin> invoke server.transactionservice.resources.cppxa-resource.リソース名.list


3.   トランザクションのリカバリ処理を実行します。

otxadmin> invoke server.transactionservice.resources.リソースタイプ名.リソース名.commit ShortTxIdの値
otxadmin> invoke server.transactionservice.resources.リソースタイプ名.リソース名.rollback ShortTxIdの値
otxadmin> invoke server.transactionservice.resources.リソースタイプ名.リソース名.forget ShortTxIdの値
otxadmin> invoke server.transactionservice.resources.リソースタイプ名.リソース名.delete ShortTxIdの値


どの操作を行うかどうかについては、「トランザクションの一覧表示」で表示された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フェーズコミット対応リソースが複数参加できてしまうと、片方の1フェーズコミット対応リソースのコミットが成功した後、別の1フェーズコミット対応リソースのコミットで失敗してしまうとデータの一貫性が守れないからです。
Transactionサービスでは、1つの1フェーズコミットメント対応リソースと任意の数の2フェーズコミット対応リソースの組み合わせでのトランザクション処理を行います。


・   伝播先トランザクションに1フェーズコミット対応リソースが参加している場合、伝播元(上位)のトランザクションに登録されているリソースが存在してはいけません。

提供機能編のTransactionサービスで記述したように、Transactionサービスでは「トランザクションの伝播機能」を提供しており、クライアントアプリケーションが呼び出したサーバオブジェクトを、クライアントが開始したトランザクションに参加させることができます。例えばEJB間の呼び出しを行う場合、EJBのトランザクション属性によってトランザクションの情報を伝播するか、呼び出し先で新たなトランザクションを開始させるか、トランザクションをサポートしないか、などを決めることができます。
そのEJBのトランザクション属性として、上位のトランザクションをそのまま伝播して使用するようなトランザクション構成をとる、かつ伝播先トランザクションで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)   データベースの更新状況の判断

ACOS上のデータベースの更新状況を、トランザクションログなどを使って調査し、コミットすべきかロールバックすべきか決定します。


(2)   該当するトランザクションの検索

WebOTXが提供する統合運用管理ツール、あるいは運用管理コマンドよりトランザクション一覧を表示させます。トランザクション状態が「StatusPreparing」となっているトランザクションが該当するものです。


(3)   該当するトランザクションへのコマンド発行

(2)で見つけたトランザクションに対して、(1)の結果に応じて「強制コミット」あるいは「強制ロールバック」を発行して2フェーズコミット対応リソースへの完了要求を発行してください。詳細は本マニュアルの[ 3. ドメイン > 3.9. 統計情報の取得 > 3.9.4. Transactionサービス(JTA)統計情報の取得 > 3.9.4.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.2-1

名前

既定値

TFDecision Proxy RCS、リカバリサーバの位置

0: 自マシン上にある
1: 他のマシン上のものを利用
0
TFMachine TFDecisionが1の場合のマシン名 無し
NSRoot Proxy RCS、リカバリサーバが利用する名前サーバの初期コンテキストをINS形式で指定する。

例:corbaloc://ホスト名:ポート番号/NameService
無し(自ホストの名前サーバを利用)
TxTimeout トランザクションタイムアウト時間(秒)。0を指定するとタイムアウト無しとなる。 600

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.   トレース採取方法設定ファイルを作成

C++クライアントアプリケーションの場合)

以下にあるので生成の必要はありません。

Windows: レジストリ\\HKEY_LOCAL_MACHINE\SOFTWARE\NEC\WebOTX\TS\Trace\WebOTX_S\Current配下
UNIX: /opt/share.nec/conf/comtrace.confの[WebOTX_S.Current]セクション
Javaクライアントアプリケーションの場合)

以下のJavaコマンドを実行して作成してください。これにより、trace.confファイルが生成されます。

Windows:コマンドプロンプトより以下を実行
> set CLASSPATH=(WebOTXインストールフォルダ)\TS\javalib\wots71.jar
> java jp.co.nec.WebOTX.TS.util.TraceGen -TraceFileName=CurTrace.trc
UNIX:以下のコマンドを実行
> setenv CLASSPATH=/opt/WebOTX/TS/javalib/wots71.jar
> java jp.co.nec.WebOTX.TS.util.TraceGen -TraceFileName=current.trc


2.   トレース採取方法設定ファイルの項目の設定

以下の項目を必要に応じて変更してください。

表7.4.7.4-1

名前

既定値

TraceLevel 0〜5

0:無し、1:エラー、2:警告、3:情報、4:詳細、5:デバッグ
1
TraceFileSize トレースファイルサイズ(Byte)、TraceLevelを5にする場合には、サイズを大きくして下さい 1048576(1MB)
TraceFileName 出力するトレースのファイル名 CurTrace.trc(C++)、もしくは、引数で指定したもの(Java)

3.   クライアントアプリケーション起動時にトレース採取方法設定ファイルを指定して実行

C++クライアントアプリケーションの場合)

特に指定しなくても自動的に参照します。

Javaクライアントアプリケーションの場合)

クライアントアプリケーション起動時のシステムプロパティに以下を追加してください。

-DJavaConfigPath=trace.conf


なお、採取したトレースを参照するためには以下のツールを利用してください。

Windows:(WebOTXインストールフォルダ)\TS\bin\trcview.exe
UNIX:/opt/WebOTX/TS/sbin/trcview


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」を参照してください。

7.5.7. 制御対象ドメインのインポート・エクスポート

多数の制御対象ドメインを登録する必要がある場合、登録済みの制御対象ドメインの設定内容を引用して登録を行うことができます。なお、この操作は統合運用管理ツールからのみ行うことができます。
制御対象ドメインのインポート・エクスポートを行う際の手順について説明します。

統合運用管理ツールから制御対象ドメインのインポート操作
あらかじめ、統合運用管理ツールより、Working Domain Coordinator の動作するドメインに接続しておきます。

  1. ツリービューより「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「ワーキングドメインコーディネータ」-「制御対象サーバ」-「<制御対象サーバ名>」-「制御対象ドメイン」を右クリックし、「制御対象ドメインのインポート」を選んでください。
  2. 表示された画面で、インポートする制御対象サーバと制御対象ドメインを設定してください。表示された画面に、選択した制御対象ドメインの設定が表示されます。
  3. 表示された画面の制御対象ドメインの名前および必要な情報を、実際のドメインの定義内容に合わせて編集してください。ビジネスロジックグループ名、ロードバランサ名、振り分け先のグループ名などを設定します。

統合運用管理ツールから制御対象ドメインのエクスポート操作
あらかじめ、統合運用管理ツールより、Working Domain Coordinator の動作するドメインに接続しておきます。

  1. ツリービューより「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「ワーキングドメインコーディネータ」-「制御対象サーバ」-「<制御対象サーバ名>」-「制御対象ドメイン」-「<エクスポートする制御対象ドメイン名>」を右クリックし、「制御対象ドメインのエクスポート」を選んでください。選択された制御対象ドメインの設定内容を引用した画面が表示されます。
  2. 表示された画面の「エクスポート先の制御対象サーバ名」と「生成する制御対象ドメイン名」を設定してください。また、それ以外の必要な情報を、実際のドメインの定義内容に合わせて編集してください。

7.5.8. 制御対象サーバのメンテナンス

制御対象サーバに定期的なサーバメンテナンスを行う必要がある場合、制御対象からの除外の設定を行うことで、そのサーバのみを負荷分散制御の対象から一時的に除外することができます。制御対象から除外されたサーバには、負荷の監視、および高負荷検出時の切り替え処理は行われません。
制御対象サーバのメンテナンスを行う際の手順について説明します。

統合運用管理ツールから操作
あらかじめ、統合運用管理ツールより、Working Domain Coordinator の動作するドメインに接続しておきます。

  1. ツリービューより「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「ワーキングドメインコーディネータ」-「制御対象サーバ」-「<メンテナンスを行う制御対象サーバ名>」を右クリックし、「制御対象から除外」を選んでください。
  2. 制御対象サーバのメンテナンスを行います。
  3. メンテナンス終了後、制御対象サーバを制御対象に復帰する場合は、ツリービューより「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「ワーキングドメインコーディネータ」-「制御対象サーバ」-「<メンテナンスを行った制御対象サーバ名>」を右クリックし、「制御対象に復帰」を選んでください。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、Working Domain Coordinator の動作するドメインにログインしておきます。

  1. 次のコマンドを発行し、メンテナンスを行う制御対象サーバを制御対象から除外します。

    制御対象サーバを制御対象から除外

    otxadmin> suspend-wdc-controlled-server メンテナンスを行う制御対象サーバ名

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


  2. 制御対象サーバのメンテナンスを行います。


  3. メンテナンス終了後、次のコマンドを発行し、メンテナンスを行った制御対象サーバを制御対象に復帰します。

    制御対象サーバを制御対象に復帰

    otxadmin> resume-wdc-controlled-server メンテナンスを行った制御対象サーバ名

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

7.5.9. 負荷分散制御装置(LB)の制御

Working Domain Coordinatorには、LBの振り分け先の制御モードが3つあります。このLB制御モードが「LB制御依頼」に設定されている場合、LBの振り分け先の制御を運用担当者が行う必要があります。
LB制御モードが「LB制御依頼」に設定されている場合の切り替え処理の動作シーケンス、およびそれに伴う運用操作について説明します。

  1. Working Domain Coordinatorが高負荷時のサンプリング監視で継続的な高負荷状態を検出すると、余裕のある制御対象サーバを選択します。


  2. メッセージIDがOTX22040012のメッセージがイベントログ(UNIXではsyslog)に出力されます。


  3. 運用担当者は、2.で出力されたイベントログ(UNIX ではsyslog)のメッセージに記載されている制御対象ドメインをLB の振り分け先から削除します。制御対象ドメインのLB の振り分け先からの削除は、統合運用管理ツールのツリービューより該当サーバもしくはドメインを右クリック、「負荷分散装置から削除」を選択することでも可能です。


  4. 運用担当者は、統合運用管理ツールのツリービューより「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「ワーキングドメインコーディネータ」-「制御対象サーバ」-「<制御対象サーバ名>」-「制御対象ドメイン」-「<停止する制御対象ドメイン名>」を右クリックし、「ドメイン停止処理の再開」を選びます。


  5. Working Domain Coordinatorは、制御対象ドメインの停止を行います。


  6. Working Domain Coordinatorは、高負荷なビジネスロジックの配備された制御対象ドメインを起動します。制御対象ドメインが起動すると、メッセージIDがOTX22040011のメッセージをイベントログ(UNIXではsyslog)に出力します。


  7. 運用担当者は、6.で出力されたイベントログ(UNIX ではsyslog)のメッセージに記載されている制御対象ドメインをLB の振り分け先に追加します。制御対象ドメインのLB の振り分け先への追加は、統合運用管理ツールのツリービューより該当サーバもしくはドメインを右クリック、「負荷分散装置への登録」を選択することでも可能です。

7.6. WebOTX Webサーバ

7.6.1. はじめに

WebOTX Application Serverでは、Webサーバ層の提供機能として、 Javaベースの内蔵Webサーバと、Apache HTTP ServerベースのWebOTX Webサーバをバンドルしています。

本書では Apache HTTP Serverベースの WebOTX Webサーバを運用するための 運用操作法についての概要や具体的な設定項目や設定方法について記載しています。

7.6.2. 機能

ここでは、WebOTX Webサーバが提供する機能について説明します。

7.6.2.1. 機能概要

WebOTX Webサーバは、WebOTX Application Server の Webサーバ層の機能を 提供しており、Webサーバのデファクトスタンダードである Apache HTTP Server の 次のバージョンをバンドルしています。(2014年7月現在)

WebOTX Webサーバでは、Apache HTTP Server で提供される すべての機能に加え、次の機能を提供します。

なお、WebOTX Application Server では、ApacheベースのWebOTX Webサーバの 他に、Java ベースの Webサーバを内蔵しており、そちらも利用可能です。
さらに、Internet Information Service(IIS) 、LinuxマシンなどのOSに添付 されている Apache HTTP Server 2.2.25 以降との連携動作をサポート しています。

7.6.2.2. 基本機能

WebOTX Webサーバは、Apache HTTP Server が提供する Webサーバ動作に 関する基本機能をすべて提供します。

主に次の機能があります。

7.6.2.3. SSL 通信機能

SSSL (Secure Sockets Layer) は、公開鍵暗号方式を利用して データの暗号化を行い、公開鍵と秘密鍵と呼ばれるキーの対を利用して、 情報の暗号化と復号を行います。公開鍵は、特定のアルゴリズムを使用して データを暗号化するためのものであり、他社に配布可能です。 秘密鍵は、一般には配布せず、サーバ上に安全が保たれた状態で保管する 必要があります。
SSL を使用してサイトにクライアントが接続すると、 サーバは証明書の一部として公開キーとそれに付随する情報を送信し、 クライアントが公開鍵暗号方式を利用してサーバの身元を確認します。

証明書は、認証局 (CA : Certificate Authority)によって発行された 電子的はドキュメントであり、インターネット上で個人または企業の 身元を保証するものであり、証明書にはサイトの公開鍵が含まれている ため、クライアントはそれを利用して、サーバから送られてきたデータ を復号できます。

WebOTX Webサーバでは、OpenSSLライブラリを利用した mod_sslモジュールを使用して、SSL2.0/3.0 および TLS1.0 を利用して、 かつ128Bit以上の暗号化方式をサポートしたセキュアなWebサイト を構築することができます。
また、SSLクライアント認証機能も利用可能です。
クライアントがSSLを利用したセキュアなサイトにアクセスするには、 次の形式のURLを指定します。

https://ホストアドレス[:ポート]/ホスト内資源アドレス

HTTPS接続の場合、ポートは通常443が利用されます。ポート番号に 443を利用する場合は省略が可能です。

7.6.2.4. LDAP 連携機能

LDAP (Lightweight Directory Access Protocol)サーバと連携して、 HTTP認証をLDAPエントリデータに登録されたユーザで行うことができます。

なお、WebOTX Application Server では、LDAPサーバとして EnterpriseDirectoryServer(EDS)をバンドルしており、 EDSに登録したユーザを利用してHTTP認証を行うことができます。

7.6.2.5. IPv6 ネットワークのサポート

IPv6 ネットワーク環境での動作をサポートします。
IPv6/IPv4ネットワーク混在環境において、それぞれ別々のIPアドレス、ポートに対して待ち合わせが可能です。

待ち合わせ用のポート番号は、IPv6/IPv4で同一にすることもできますし、別々に設定することもできます。

7.6.2.6. 提供モジュール一覧

WebOTX Webサーバは、Apache HTTP Serverで提供される次のモジュール を提供しています。
デフォルトで組み込まれていないモジュールが提供する機能を利用する 場合には、 LoadModule 指示子により、モジュールのロードを行う 必要があります。

 

Apache 2.2
表7.6.2.6-1
モジュール 機能概要
(コアモジュール) (デフォルトで組み込まれている機能。ロードする必要はありません)

core, http_core

サーバのコア機能を提供します。

worker

(UNIX)UNIX版のMPMモジュールはworkerとしています。Workerは、複数のスレッドを有するプロセスが複数個動作するモードです。クライアントから要求は、各スレッド上で受け付けを行い、処理を行います。

mpm_winnt

(Windows)Windows向けに最適化されたマルチプロセッシングモジュールです。複数のスレッドを有するプロセスが動作するモードです。クライアントから要求は、各スレッド上で受け付けを行い、処理を行います。

mod_so

起動時や再起動時に実行コードとモジュールをサーバにロードします。

(オプションモジュール)

デフォルトで組み込まれていません。利用するにはLoadModule指示子により別途ロードする必要があります。
右欄は、W(Windows)、U(Unix: HP-UX/Solaris/Linux)を意味し、 各OSで提供しているモジュールに○をつけています。
W U

mod_actions

メディアタイプやリクエストメソッドに応じてCGIスクリプトを実行する機能を提供します。

mod_alias

ホストファイルシステム上のいろいろな違う場所をドキュメントツリーにマップする機能と、URLのリダイレクトを行う機能を提供します。

mod_asis

自分用のHTTPヘッダの書かれているファイルを送信します。

mod_auth_basic

Basic 認証機能を提供します。

mod_auth_digest

digest

mod_authn_alias

xxxxxx

mod_authn_anon

認証が必要な領域への "anonymouse"ユーザのアクセスを許可する。

mod_authn_dbd

SQL データベース

mod_authn_dbm

DBM ファイルを用いたユーザ認証機能を提供します。

mod_authnz_ldap

LDAPディレクトリに格納されたデータベースを利用してHTTP基本認証を許可します。

mod_authz_dbm

DBMファイルを用いたグループ認証

mod_authz_default

承認フォールバックモジュール

mod_authz_file

プレーンテキストファイルを用いたグループ承認

mod_authz_host

ホスト(名前もしくは IPアドレス)に基づいたグループ承認

mod_authz_owner

ファイルの所有者に基づいた承認

mod_authz_user

ユーザ承認

mod_autoindex

UnixのlsコマンドやWindowsのdirシェルコマンドに似たディレクトリインデックスを生成します。

mod_cache

URI をキーにしたコンテンツのキャッシュ

mod_cern_meta

CERN httpd が使う追加のHTTPヘッダ形式でメタ情報を指定できるようにします。

mod_cgi

CGI スクリプトを実行します。

mod_cgid

外部CGIデーモンを使用したCGI スクリプトを実行します。

mod_charset_lite

キャラクターセットの変換と記録を指定します。

mod_dav

分散オーサリングとバージョン管理(WebDAV)機能

mod_dav_fs

mod_dav のためのファイルシステムプロバイダ

mod_dav_lock

mod_dav 用の汎用ロックモジュール

mod_dbd

SQL データベースコネクションを管理する

mod_deflate

クライアントへ送られる前にコンテンツを圧縮します。

mod_dir

URLに指定される「最後のスラッシュ」のリダイレクトと、ディレクトリのインデックスファイルを扱う機能を提供します。

mod_disk_cache

URIをキーにしたコンテンツキャッシュストレージを管理します。

mod_dumpio

すべてのI/Oをエラーログにダンプします。

mod_env

CGIスクリプト及びSSIページに渡される環境変数を変更する機能を提供します。

mod_expires

ユーザの指定した基準に基づいたExpiresとCache-Control HTTPヘッダの生成をします。

mod_ext_filter

レスポンスのボディをクライアントに送る前に外部プログラムで処理します。

mod_file_cache

メモリ内にファイルの静的なリストをキャッシュします。

mod_filter

Context-sensitive smart filter configuration module

mod_headers

HTTPリクエストヘッダとレスポンスヘッダをカスタマイズします。

mod_ident

RFC 1413 ident lookups

mod_imagemap

サーバサイドのイメージマップを実行します。

mod_include

サーバがパースするhtmlドキュメント(Server Side Includes)

mod_info

サーバの設定の包括的な概観を提供します。

mod_ldap

LDAP連携用モジュール。

mod_log_config

サーバへのリクエストのロギングを行います。

mod_log_forensic

サーバに送られたリクエストをforensicロギングします。

mod_logio

リクエスト毎に入力バイト数と出力バイト数をロギングします。

mod_mem_cache

URIをキーにしたコンテンツキャッシュします。

mod_mime

リクエストされたファイルの拡張子とファイルの振る舞い(ハンドラとフィルタ)、内容(MIMEタイプ、言語、文字セット、エンコーディング)とを関連付けます。

mod_mime_magic

ファイルの内容を読み込んでMIMEタイプを決定します。

mod_negotiation

コンテントネゴシエーション機能を提供します。

mod_proxy

HTTP/1.1プロキシ/ゲートウェイサーバを提供します。

mod_proxy_ajp

mod_proxyで AJP をサポートするモジュール。

mod_proxy_balancer

負荷分散のための mod_proxy拡張モジュール。

mod_proxy_connect

CONNECT リクエストを扱う mod_proxy 拡張モジュール。

mod_proxy_ftp

mod_proxyでFTPをサポートするモジュール。

mod_proxy_http

mod_proxyでHTTPをサポートするモジュール。

mod_rewrite

URLの書き換えを行うリライトエンジンを提供します。

mod_setenvif

リクエストの特徴に基づいた環境変数の設定を可能にします。

mod_speling

ユーザが入力したであろう間違ったURLを、大文字小文字の区別を無視することと一つ以下の綴り間違いを許容することで修正を試みます。

mod_ssl   

SSL通信用のモジュール。

mod_status

サーバの活動状況と性能に関する情報を提供します。

mod_substitute

Perform seach and replace operations on response bodies

mod_unique_id

それぞれのリクエストに対する一意な識別子の入った環境変数を提供します。

mod_userdir

ユーザ専用のディレクトリを提供します。

mod_usertrack

Cookieによりユーザの追跡を行います。

mod_version

バージョン依存の設定をします。

mod_vhost_alias

バーチャルホストに関する動的な設定を提供します。

mod_jk-22

Webコンテナと接続を行うコネクタモジュール。 WebOTX AS Express 利用時や、WebOTX AS Standard/Enterprise の「Webコンテナの動作モード」設定で「スタンダードモード」を選択した 場合に利用されます。

mod_jk_om-22

(WebOTX 独自) マルチプロセス対応のWebコンテナと連携を行うためのコネクタモジュール。 WebOTX AS Standard/Enterprise の「Webコンテナの動作モード」 設定で「アドバンスドモード」を選択した場合に利用されます。

7.6.2.7. その他の機能

その他の機能の詳細は、以下の Apache HTTP Server の Webサイトを参照してください。

または、WebOTX をインストールしたマシン上で、ブラウザから 次のURL にアクセスし、Apache HTTP Server のドキュメントを参照 してください。

7.6.3. 定義情報

WebOTX Webサーバの定義情報は、定義情報ファイル(httpd.conf)に格納され、WebOTX Webサーバ起動時に読み込まれます。
定義情報を更新した場合には、WebOTX Webサーバの再起動が必要になります。

定義情報の詳細は[ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.3. HTTPサーバ > 1.3.2. WebOTX Webサーバ設定方法]を参照してください。

7.6.4. 運用

ここでは、WebOTX Webサーバの運用・操作方法について説明します。
また、特定機能を利用する場合の設定方法についても説明します。

7.6.4.1. 起動・停止

WebOTX Webサーバの起動・停止は、WebOTX Application Server のドメインの起動・停止に 連動して動作します。
WebOTX のドメインの起動・停止処理は、OS のサービスプログラムとして 動作しますので、通常、Webサーバの起動・停止だけを意識する必要はありませんが、 WebOTX Webサーバの定義情報を変更するような場合に有効です。

WebOTX のドメインが起動している状態で、WebOTX Webサーバを単独で起動・停止を行う 場合は、統合運用管理ツールから操作するか、次のコマンドを実行してください。

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

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

起動・停止方法

  1. 「WebOTX 管理ドメイン[<サーバ名>]」− 「<ドメイン名>」−「アプリケーションサーバ」−「WebServer」 を選択し、マウスを右クリックして操作メニューを表示します。 あるいは、メニューバーの[操作]を選択します。


    図7.6.4.1-1


  2. 表示されるメニューから「Webサーバの開始」を選択すると、 WebOTX Webサーバが起動します。
    また、「Webサーバの停止」を選択すると、WebOTX Webサーバが停止します。

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

あらかじめ、運用管理コマンドで、ドメインにログインしておきます。
otxadmin>login --user admin --passwprd adminadmin --port 6212

起動・停止方法
  1. WebOTX Webサーバを起動する場合、次のコマンドを実行します。

    otxadmin>invoke server.WebServer.start
    
  2. WebOTX Webサーバを停止する場合、次のコマンドを実行します。

    otxadmin>invoke server.WebServer.stop
    

7.6.4.2. 定義情報の参照

WebOTX Webサーバの定義情報のうち、動作に必要となる一部の必須情報を WebOTX の統合運用管理ツール および 運用管理コマンドから参照すること ができます。

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

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

定義情報の参照

  1. 「WebOTX 管理ドメイン[<サーバ名>]」− 「<ドメイン名>」−「アプリケーションサーバ」−「WebServer」 を選択し、Webサーバの各定義情報を表示します。


    図7.6.4.2-1


  2. 「定義情報」、「定義情報(SSL)」、「アクセスログ」の各タブ情報を 選択することで、各項目の情報を参照できます。

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

あらかじめ、運用管理コマンドで、ドメインにログインしておきます。
otxadmin>login --user admin --passwprd adminadmin --port 6212

定義情報の参照
  1. WebOTX Webサーバの定義情報を取得するには、次のコマンドを実行します。
    運用管理コマンド(またはツール)から参照可能な定義情報の一覧については、 次の表を参照してください。

    otxadmin>get server.WebServer.*
    

WebOTX 運用管理コマンド(ツール)から参照できる定義情報一覧

表7.6.4.2-1
統合運用管理ツールでの属性名 Server.WebServer.* 説明
ポート番号 Port Listen 指示子の設定値を取得します。
WebOTX Webサーバが待ち合わせを行うポート番号を表します。
バージョン情報 Version Webサーバのバージョン情報を表示します。
なお、この情報は httpd.conf には定義されていません。
ServerName ServerName ServerName 指示子の設定値を取得します。
DocumentRoot DocuumentRoot DocumentRoot 指示子の設定値を取得します。
ブラウザから見えるメインのドキュメントツリーになるディレクトリを 表します。
ErrorLog ErrorLog ErrorLog 指示子の設定値を取得します。
Webサーバのエラーログの出力先を表します。
LogLevel LogLevel LogLevel 指示子の設定値を取得します。
Webサーバのエラーログの出力レベルを表します。
最大同時接続数 MaxClients UNIX版の MaxClients 指示子、あるいは Windows版の ThreadsPerChild 指示子の設定値を取得します。
クライアント(ブラウザ)から接続できる最大同時接続数を表します。
SSL(HTTPS)通信の使用の有無 security-enabled SSL(HTTPS)通信を利用するかどうかの情報です。
チェックされている(コマンドで true が返却された)場合、 SSL(HTTPS) 通信が利用可能です。チェックされていない (コマンドで false が返却された)場合、SSL(HTTPS)通信は 利用できません。
この情報は、httpd.conf に定義されていません。
HTTPS 通信用ポート番号 ssl-port SSL用の定義情報ファイルである ssl.conf に定義されている Listen 指示子の設定値を取得します。
HTTPS通信で利用するポート番号を表します。
アクセスログ出力先と出力フォーマット AccessLog CustomLog 指示子の設定値を取得します。
アクセスログの出力先と、出力するフォーマット(LogFormat)情報の ニックネーム値を表します。
「リクエスト処理時間(秒)」情報の出力 AccesslogTat アクセスログに「リクエスト処理時間」の情報が出力されるように 設定されている(LogFormat 指示子に「%T」が設定されている) かどうかの情報を取得します。
チェックされている(コマンドで true が返却された)場合、アクセスログに リクエスト処理時間(秒単位)が出力されます。 チェックされていない(コマンドで false が返却された)場合、 アクセスログにリクエスト処理時間の情報は出力されません。
アクセスログのローテーション Rotatelog アクセスログがローテーション出力されるように設定されている (CustomLog 指示子にローテーション出力が設定されている) かどうかの情報を取得します。
チェックされている(コマンドで true が返却された)場合、アクセス ログはローテーション出力を行います。チェックされていない(コマンド で false が返却された)場合、アクセスログはローテーション 出力されません。
ローテーション間隔 RotationTime 上記「アクセスログのローテーション」が設定されている場合、 そのローテーション時間(秒単位)の情報を取得します。
既定値は 864000 秒(=24 時間)です。

7.6.4.3. 定義情報の更新

通常、WebOTX Webサーバの定義情報を更新するには、httpd.conf ファイルを直接編集する必要がありますが、一部の定義情報は、 WebOTX の統合運用管理ツール および 運用管理コマンドを利用して 設定値を更新することができます。

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

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

定義情報の更新
  1. 「WebOTX 管理ドメイン[<サーバ名>]」− 「<ドメイン名>」−「アプリケーションサーバ」−「WebServer」 を選択し、Webサーバの各定義情報を表示します。


    図7.6.4.3-1


  2. 「定義情報」、「定義情報(SSL)」、「アクセスログ」の各タブ情報を 選択し、各項目の情報を更新します。
    例えば、ポート番号を 8080 に変更する場合には、現在定義されている ポート番号の項目を選択し、「編集」ボタンを押下して、出力されたダイアログ に 8080 を設定します。

  3. 「更新」ボタンを押下することで、定義情報ファイル(httpd.conf)に変更した 情報が反映されます。

  4. Webサーバの再起動 または WebOTX のドメインの再起動を行うことで、 変更した情報で Webサーバ が起動します。

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

あらかじめ、運用管理コマンドで、ドメインにログインしておきます。
otxadmin>login --user admin --passwprd adminadmin --port 6212

定義情報の更新
  1. WebOTX Webサーバの定義情報を取得するには、次のコマンドを実行します。
    運用管理コマンド(またはツール)から参照可能な定義情報の一覧については、 次の表を参照してください。

    otxadmin>set server.WebServer.*=xxx
    

    例えば、ポート番号を 8080 に変更する場合には、次のコマンドを 実行します。
    otxadmin>set server.WebServer.port=8080
    
  2. Webサーバ の再起動または WebOTX のドメインの再起動を行うことで、 更新された情報で Webサーバが起動します。

WebOTX 運用管理コマンド(ツール)から更新できる定義情報一覧

表7.6.4.3-1
統合運用管理ツールでの属性名 Server.WebServer.* 説明
ポート番号 Port Listen 指示子を設定します。
WebOTX Webサーバが待ち合わせを行うポート番号を設定します。
[IPアドレス:]ポート番号 の形式で設定可能です。 また、複数の設定も可能です。
ServerName ServerName ServerName 指示子を設定します。
DocumentRoot DocuumentRoot DocumentRoot 指示子を設定します。
ブラウザから見えるメインのドキュメントツリーになるディレクトリを 設定します。
ErrorLog ErrorLog ErrorLog 指示子を設定します。
Webサーバのエラーログの出力先を設定します。
LogLevel LogLevel LogLevel 指示子を設定します。
Webサーバのエラーログの出力レベルを設定します。
最大同時接続数 MaxClients UNIX版の MaxClients 指示子、あるいは Windows版の ThreadsPerChild 指示子を設定します。
クライアント(ブラウザ)から接続できる最大同時接続数を設定します。
SSL(HTTPS)通信の使用の有無 security-enabled SSL(HTTPS)通信を利用するかどうかを設定します。
SSL(HTTPS)通信を利用する場合は、チェックを行い(コマンド では true を設定し)、SSL(HTTPS) 通信を利用しない場合は、 チェックを外します(コマンドでは false を設定します)。
HTTPS 通信用ポート番号 ssl-port SSL用の定義情報ファイルである ssl.conf に Listen 指示子を設定します。
HTTPS通信で利用するポート番号を設定します。
アクセスログ出力先と出力フォーマット AccessLog CustomLog 指示子を設定します。
アクセスログの出力先と、出力するフォーマット(LogFormat)情報の ニックネーム値を設定します。
「リクエスト処理時間(秒)」情報の出力 AccesslogTat アクセスログに「リクエスト処理時間」の情報を 出力する(LogFormat 指示子に「%T」を設定する) かどうかを設定します。
アクセスログにリクエスト処理時間(秒単位)を出力する場合、 チェックを行い(コマンドでは true を設定し)、 アクセスログにリクエスト処理時間の情報を出力しない場合、 チェックを外します(コマンドでは false を設定します)。
アクセスログのローテーション Rotatelog アクセスログをローテーション出力させるかどうかを設定します。
ローテーション出力を行う場合は、チェックを行い(コマンドでは true を設定し)、ローテーション出力を行わない場合は、 チェックを外します(コマンドでは false を設定します)。
ローテーション間隔 RotationTime 上記「アクセスログのローテーション」が設定されている場合、 そのローテーション時間(秒単位)を設定します。
既定値は 864000 秒(=24 時間)です。

7.6.4.4. 定義情報の追加

通常、WebOTX Webサーバの定義情報を更新するには、httpd.conf ファイルを直接編集する必要がありますが、WebOTX の統合運用管理 ツール および 運用管理コマンドを利用して、httpd.confファイルに 現在設定されていない定義情報を追加することができます。

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

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

定義情報の追加
  1. 「WebOTX 管理ドメイン[<サーバ名>]」− 「<ドメイン名>」−「アプリケーションサーバ」−「WebServer」 を選択し、マウスを右クリックして操作メニューを表示します。 あるいは、メニューバーの[操作]を選択します。


    図7.6.4.4-1


  2. 表示されるメニューから「定義情報の追加」を選択すると、「定義情報の追加」 ダイアログが表示されます。


    図7.6.4.4-2

  3. 「追加する定義情報」に追加する定義情報を設定します。
    定義情報は、<指示子><設定値>の形式で指定する必要があります。
    なお<指示子>だけの定義を設定する場合は、<指示子>の後に半角スペース を設定してください。

  4. 「実行」ボタンを押下することで、設定した定義情報が、定義情報ファイルに 追加されます。

  5. Webサーバの再起動 または WebOTX のドメインの再起動を行うことで、 変更した情報で Webサーバ が起動します。

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

あらかじめ、運用管理コマンドで、ドメインにログインしておきます。
otxadmin>login --user admin --passwprd adminadmin --port 6212

定義情報の追加
  1. WebOTX Webサーバの定義情報に情報を追加するには、 次のコマンドを実行します。

    otxadmin>invoke server.WebServer.setDirective "directive value"
    

    追加する定義情報は<指示子> <設定値> の形式で、 ダブルコーテーションで囲む必要があります。

    例えば、ListenBackLog 512 という定義情報を追加する場合、次のように指定します。

    otxadmin>invoke server.WebServer.setDirective "ListenBackLog 512"
    

    また、Win32DisableAcceptEx のような <指示子> だけの定義を追加する 場合には、<指示子> の後に半角スペースを付けて、次のように指定します。
    otxadmin>invoke server.WebServer.setDorective "Win32DisableAcceptEx "
    
  2. Webサーバ の再起動または WebOTX のドメインの再起動を行うことで、 更新された情報で Webサーバが起動します。

本節で説明している定義情報の追加処理は、httpd.conf ファイル に対してのみ有効です。ssl.conf ファイルに対しては、ツールやコマンドから 定義情報の追加を行うことはできません。

7.6.4.5. SSL(HTTPS通信) 設定方法

WebOTX Webサーバは、OpenSSL ライブラリを利用した mod_ssl モジュールと 連携することで、SSL プロトコルを利用した HTTPS 通信を実現することができます。
ブラウザとWebサーバ間に HTTPS 通信を利用するには、次の設定が必要です。

7.6.4.5.1. SSL通信用ライブラリのインストール

HTTPS通信を利用するには、WebOTX Webサーバ用のSSL通信用ライブラリが インストールされている必要があります。

Windows版の場合、インストール時にWebOTX Webサーバをインストールする ことを選択することで、SSL通信用ライブラリも一緒にインストールされます。
SSL 通信用ライブラリがマシンにインストールされているかの確認は、 「アプリケーションの追加と削除」(または「プログラムの追加と削除」)から 「SSL通信用ライブラリ (Webサーバ Ver2.2)」がインストールされているかを確認してください。


図7.6.4.5-1

UNIX版の場合、インストール時にWebOTX Webサーバのインストールを 選択すると、SSL通信用ライブラリをインストールするかどうかが 選択できます。
SSL通信用ライブラリのインストールを選択していない場合には、 次のパッケージを別途インストールしてください。

表7.6.4.5-1
プラットフォーム バージョン パッケージ

Linux (x86)

2.2

/MODSSL/LINUX/modssl22-2.20.xx.xx-1.i386.rpm

Linux (x64)

2.2

/MODSSL/LINUX/modssl22-2.20.xx.xx-1.x86_64.rpm
7.6.4.5.2. SSL設定の有効化

SSL通信用ライブラリをインストール後、SSL通信機能を有効にするために、 WebOTX Application Server の設定変更を行う必要があります。
次の手順により、設定変更を行ってください。

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

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

SSL通信の有効化

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」 -「アプリケーションサーバ」-「WebServer」を選択し、「定義情報(SSL)」(※) タブの「SSL(HTTPS通信)の使用の有無」をチェックします。


    図7.6.4.5-2


    (※)「定義情報(SSL)」タブが表示されない場合、「4.5.1 SSL通信ライブラリのインストール」により、対応するSSL通信ライブラリをインストールし、WebOTX を再起動してください。

  2. 「更新」ボタンを押下すると、SSL設定が有効になります。
    SSLで利用するポート番号を変更する場合、 「HTTPS通信用の定義情報ファイル」の項目で表示されるファイルを 編集してください。
    または「HTTPS通信用のポート番号」の項目を更新します。

  3. WebOTX Webサーバを再起動することにより、SSL設定が有効になります。

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

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

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

SSL通信の有効化

  1. WebOTX WebサーバのSSL通信を有効化するには、以下のコマンドを実行します。

    otxadmin>set server.WebServer.security-enabled=true
    
  2. SSL通信用のポート番号を変更するには、以下のコマンドを実行します。
    例えば、8443に変更する場合、次のコマンドを実行します。

    otxadmin>set server.WebServer.ssl-port=8443
    
  3. WebOTX Webサーバを再起動します。

    otxadmin>invoke server.WebServer.stop
    
    otxadmin>invoke server.WebServer.start
    
7.6.4.5.3. HTTPS 通信の接続確認

WebOTX Webサーバでは、SSL通信用ライブラリをインストールすることで、 HTTPS接続評価用の証明書ファイルと秘密鍵ファイルが同時にインストールされます。
したがって、インストール直後でもローカルマシンのブラウザからHTTPSでの接続確認が 可能です。

  1. ブラウザから次のURLを指定します。 SSL接続用のポート番号を変更している場合には、 そのポート番号も指定してください。 別マシンから接続確認を行う場合には、WebOTXをインストールした ホスト名を指定してください。

    https://localhost/manual/

  2. 例えば、Apache2.2を利用している場合、次のような画面が表示されれば、 SSLで接続できたことが確認できます。
    また、ブラウザのステータスバーに HTTPS 接続中であることを意味する 「鍵」マークが表示されていることを確認してください。


    図7.6.4.5-3


  3. ブラウザに表示される「鍵」マークをクリックすることで、 WebOTX WebサーバのSSL通信機能で利用している 証明書情報を参照することができます。
    ただし、WebOTX WebサーバのSSL通信ライブラリが インストールする本証明書は、接続確認用の自己署名証明書であるため、 以下のように「信頼された証明機関がこの証明書を確認できません」 と表示されます。
    「OK」ボタンを押下して証明書のダイアログを終了させてください。


    図7.6.4.5-4


  4. なお、Internet Explorer 7(IE 7)を利用した場合、次の画面 (IE7でのHTTPS接続画面-?)が表示されます。
    これは、IE 7で証明書のチェックが厳しくなったために 出力される情報であり、SSLでの接続ができないという 訳ではありません。
    「このサイトの閲覧を続行する(推奨されません)。」を選択すると、 さらに次の画面(IE7でのHTTPS接続画面-?)が表示され、 アドレスバーに「証明書エラー」と表示されます。
    本件は、信頼された証明機関から発行された正しい証明書 を利用することで解決します。
    次節に示す手順により、正しい証明書を入手してください。

    IE7でのHTTPS接続画面-?


    図7.6.4.5-5

    IE7でのHTTPS接続画面-?


    図7.6.4.5-6

7.6.4.5.4. サーバ証明書の取得

次に示す手順は、 CA機関に対して証明書の発行を要求する手順の一例です。
この例では、 Linux 上で OpenSSLコマンドを利用して、秘密鍵の生成と証明書署名要求の生成を行い、 CA機関に送付して証明書を取得し、WebOTX Webサーバへ設定を行うまでの手順を記載します。
詳細については、各CA機関での証明書の取得方法(Apacheの場合)を参照してください。

Windowsで OpenSSLコマンドを利用する場合には、OpenSSLのWindows用の バイナリファイルを入手する必要があります。以下を参照してください。
   http://www.openssl.org/related/binaries.html

  1. 秘密鍵の生成

    /usr/local/openssl/private に 秘密鍵ファイル(server.key)を生成します。
    キー生成のために、ランダムな情報が含まれている file1〜file3 をあらかじめ用意しておいてください。

      >openssl genrsa -rand file1:file2:file3 1024 -out /usr/local/openssl/private/server.key
    

    生成された秘密鍵ファイルにアクセス権の設定を行います。
      >chmod 400 /usr/local/openssl/private/server.key
    
      >chmod 700 /usr/local/openssl/private
    
  2. 証明書署名要求の生成

    証明書著名要求 (CSR)ファイルを生成し、CA機関に送付します。

      >openssl req -new -key server.key -out server.csr
    
  3. 証明書ファイルの取得

    CA機関から返信された証明書ファイル(server.crt)を /use/local/openssl/certs に格納し、アクセス権を設定します。

      >chmod 400 /usr/local/openssl/certs/server.crt
    
      >chmod 700 /usr/local/openssl/certs
    
  4. 証明書と秘密鍵の設定

    証明書ファイルと秘密鍵ファイルを、 WebOTX Webサーバに設定します。
    /opt/WebOTX/domains/domain1/conf/WebServer/ssl.confSSLCertificateFile 指示子に入手した証明書ファイルを、 SSLCertificateKeyFile 指示子に秘密鍵ファイルを設定してください。

    SSLCertificateFile /usr/local/openssl/certs/server.crt
    SSLCertificateKeyFile /user/local/openssl/private/server.key
  5. パスフレーズの取得設定

    秘密鍵作成時にパスフレーズを設定している場合、証明書にアクセスするために パスフレーズの読み込み処理を設定しておく必要があります。
    SSLPassPhraseDialog 指示子を参照し、パスフレーズの設定を行ってください。 また、パスフレーズの読み込み処理を行うスクリプト(例えば、次のpass.sh のようなシェルスクリプト)等をあらかじめ用意しておく必要があります。
    なお、Windows の場合には、パスフレーズなしで秘密鍵を作成してください。

    <</usr/local/openssl/private/pass.sh(※)の内容>>

    #!/bin/sh
    echo "passphrease"
    exit 0

       (※)pass.sh はアクセス権を設定しておく必要があります。
      >chmod 500 /usr/local/private/pass.sh
    
  6. Webサーバの再起動

    設定した内容を反映するために、WebOTX Webサーバまたは WebOTX のドメインを 再起動します。

7.6.4.6. アクセスログファイルのローテーション

WebOTX Webサーバの出力するログファイルには、 クライアントからのアクセス状況を出力するaccess.logと、 Webサーバ本体側の動作に関連した情報を出力するerror.logがあります。

既定値の設定のままでWebOTX Webサーバを長時間動作させたままにすると、 access.log に出力されるログ情報が蓄積されてディスク領域を 大きく占有する場合があります。
これを解消するために、access.logファイルを一定時間で ローテーションさせることが可能です。
次の例では、access.logファイルを24時間(86400秒)でローテーション (1日毎にaccess.logファイルを作成)させる設定方法について記載します。

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

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

アクセスログファイルのローテーション

  1. 「WebOTX管理ドメイン[<ホスト名>]」- 「<ドメイン名>」-「アプリケーションサーバ」- 「WebServer」を選択し、「アクセスログ」タブの 「アクセスログのローテーション」をチェックします。


    図7.6.4.6-1


  2. 「ローテーション間隔」にローテーション時間を設定します。

  3. 「更新」ボタンを押下することで、設定内容が定義情報ファイルに反映されます。

  4. Webサーバを再起動することにより、設定内容が反映されます。

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

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

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

アクセスログファイルのローテーション

  1. WebOTX Webサーバのアクセスログのローテーション設定を有効にするには、 以下のコマンドを実行します。

    otxadmin>set server.WebServer.Rotatelog=true
    
  2. ローテーション時間は既定値で24時間(=86400秒)が設定されますが、 ローテーション時間を変更するには、以下のコマンドを実行します。
    例えば、1週間(=604800秒)でローテーションさせる場合は、 次のコマンドを実行します。

    otxadmin>set server.WebServer.RotationTime=604800
    
  3. 設定内容を反映するには、Webサーバの再起動が必要です。

上記の設定により、定義情報ファイルに次の設定が追加されます。
なお、統合運用管理ツール/運用管理コマンドからの操作ができない場合には、 定義情報ファイルを直接編集し、次の設定を行ってください。

(UNIX)

CustomLog "|/opt/WebOTX/WebServer22/bin/rotatelogs \
/opt/WebOTX/domains/domain1/logs/web/access_log 86400" common


(Windows)

CustomLog "||C:/WebOTX/WebServer22/bin/rotatelogs.exe\
C:/WebOTX/domains/domain1/logs/web/access.log 86400" common

上記の設定により、Webサーバの再起動を実施することで、次のログファイルが順次生成されます。

access_log.1089207300
access_log.1083293700
access_log.1083380100

作成されたファイルのうち、小さい数字のものは過去のログとなりますので、ファイルの移動/削除等が可能となります。

なお、SSL通信用の定義情報ファイル(ssl.conf)に定義されている ssl_request_logファイルに対してローテーション設定を行う場合には、直接ssl.confファイルを編集し、次の設定を行ってください。

(UNIX)

CustomLog "|/opt/WebOTX/WebServer22/bin/rotatelogs \
  /opt/WebOTX/domains/domain1/logs/web/ssl_request_log 86400" \
  "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"


(Windows)

CustomLog "||C:/WebOTX/WebServer22/bin/rotatelogs.exe \
  C:/WebOTX/domains/domain1/logs/web/ssl_request_log 86400" \
  "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

 

7.6.4.7. リクエスト処理時間のログ出力

アクセスログに リクエスト処理時間の情報を出力することで、 Webサーバがそのリクエストを受け付けて、レスポンスを返却するまでの 時間を出力することができます。
この情報は、例えば、どのリクエスト(コンテンツ)に対する処理に時間が かかっているかを調査するような場合に役立つことがあります。

ここでは、access.logファイルにリクエスト処理時間を出力する設定方法 について記載します。

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

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

リクエスト処理時間の情報出力

  1. 「WebOTX管理ドメイン[<ホスト名>]」- 「<ドメイン名>」-「アプリケーションサーバ」-「WebServer」を選択し、 「アクセスログ」タブの「リクエスト処理時間(秒)情報の出力」 をチェックします。


    図7.6.4.7-1


  2. 「更新」ボタンを押下することで、設定内容が定義情報ファイルに 反映されます。

  3. Webサーバを再起動することにより、設定内容が反映されます。

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

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

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

リクエスト処理時間の情報出力

  1. WebOTX Webサーバのアクセスログにリクエスト処理時間 の情報を出力するには、以下のコマンドを実行します。

    otxadmin>set server.WebServer.AccesslogTat=true
    
  2. 設定内容を反映するには、Webサーバの再起動が必要です。

上記の設定により、定義情報ファイルに次の設定が追加されます。
なお、統合運用管理ツール/運用管理コマンドからの操作ができない場合には、 定義情報ファイルを直接編集し、LogFormat 指示子に%T を追加してください。

LogFormat "%h %l %u %t \”%r\”%>s %b %T" common

この設定により、アクセスログには次のログ情報が出力されます。最後の項目がリクエスト処理時間(秒)となります。
なお、1秒未満でリクエスト処理が完了した場合には、0が表示されます。

(アクセスログの出力内容例)


図7.6.4.7-2

7.6.4.8. 最大同時接続数の変更

多数のブラウザから接続要求が同時に行われた場合 (最大同時接続数を超えた場合)、次のメッセージがerror.logに出力されます。

(UNUX)
  [error] server reached MaxClients setting, consider raising the MaxClients setting

(Windows)
  [warn] Server ran out of threads to serve requests. Consider raising the ThreadsPerChild setting

最大同時接続数を増やすには、定義情報の次の設定を変更する必要があります。

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

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

最大同時接続数の変更

  1. 「WebOTX管理ドメイン[<ホスト名>]」- 「<ドメイン名>」-「アプリケーションサーバ」-「WebServer」を選択し、 「定義情報」タブの「最大同時接続数」の値を変更します。


    図7.6.4.8-1


  2. 「更新」ボタンを押下することで、設定内容が定義情報ファイルに 反映されます。

  3. Webサーバを再起動することで、設定内容が反映されます。

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

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

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

最大同時接続数の変更

  1. WebOTX Webサーバの最大同時接続数を変更するには、 以下のコマンドを実行します。

    otxadmin>set server.WebServer.MaxClients=250
    
  2. Webサーバを再起動することで、設定内容が反映されます。

なお、最大同時接続数の値を変更した場合は、次の設定も合わせて 変更してください。

定義情報ファイルを直接編集する場合には、次の設定を変更します。

 

7.6.4.9. 特定クライアントに対するアクセス制限

特定のクライアンに対してアクセス制限をかける場合、 次の設定を追加します。
定義情報ファイルを直接編集してください。

例えば、次の設定例では、特定のフォルダ(静的コンテンツ)ごとに アクセスを許可するクライアントを設定しています。
http://server/aaa にアクセスできるクライアントは yourdomain.comに属するマシンに限定し、http://server/bbb にアクセスできるクライアントは anotherdomain.com に属するマシンに限定しています。

<Directory /opt/WebOTX/domains/domain1/docroot/aaa>
  Order Deny,Allow
  Deny form all
  Allow from yourdomain.com
  ...
</Directory>

<Directory /opt/WebOTX/domains/domain1/docroot/bbb>
  Order Deny,Allow
  Deny form all
  Allow from anotherdomain.com
  ...
</Directory>

次の設定例では、特定のフォルダ(静的コンテンツ)に対してアクセスを拒否する クライアントを設定しています。
http://server/ccc にアクセスできるクライアントは、ccc.domain.com 以外に属するクライアントとなります。 ccc.domain.comに属するクライアントはhttp://server/cccにアクセスできません。

<Directory /opt/WebOTX/domains/domain1/docroot/ccc>
  Order Allow,Deny
  Allow from all
   Deny from ccc.domain.com
  ...
</Directory>

Webアプリケーションなどの動的コンテンツに対して、 アクセス制限する場合には、Location 指示子の設定を追加します。
例えば、http://server/webapp 配下に配備されているWebアプリケーションに対して、 yourdomain.com 以外からのアクセスを拒否するには、次のように設定します。

<Location /webapp>
  Order Deny,Allow
  Deny form all
  Allow from yourdomain.com
  ...
</Location>

7.6.4.10. LDAP 連携

WebOTX Webサーバは、WebOTX Application Server にバンドルされている Enterprise Directory Server(EDS)と連携動作が可能であり、 EDSに登録されたエントリ情報を、HTTP認証に利用することができます。
定義情報ファイル(httpd.conf) において、次の設定を追加します。

LoadModule ldap_module "/opt/WebOTX/WebServer22/modules/mod_ldap.so
LoadModule auth_ldap_module /opt/WebOTX/WebServer22/modules/mod_auth_ldap.so

<Directory /opt/WebOTX/domains/domain1/docroot>
  AuthType Basic
  AuthName "Enter username/password."
  AuthLDAPUrl ldap://ldap-server:ldap-port/dc=users,dc=webotx,o=NEC,c=JP?uid?sub
  Require valid-user
</Directory>

上記設定により、ブラウザから http://server/ に対してアクセスが行われた場合に、次のダイアログが出力されます。
ここで LDAPサーバに登録されたユーザ/パスワード を入力することで、ブラウザからのアクセスが可能となります。


図7.6.4.10-1

認証に失敗した場合には、次のメッセージ(HTTPステータスコード 401) がブラウザに出力されます。


図7.6.4.10-2

7.6.4.11. IPv6/IPv4 混在環境での設定

Windowsマシンに、IPv4 ネットワークとIPv6 ネットワーク のそれぞれのIPアドレスが設定されている環境において、 それぞれのIPアドレスに対してWebサーバでアクセス受付を行う場合、 Listen 指示子を利用して、IPv4とIPv6の それぞれのIPアドレスとポート番号を設定してください。

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

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

ポート番号の設定

  1. 「WebOTX管理ドメイン[<ホスト名>]」- 「<ドメイン名>」-「アプリケーションサーバ」-「WebServer」を選択し、 「定義情報」タブの「ポート番号」の値を更新します。
    (例:WindowsマシンのIPv4/IPv6混在環境でポート番号80を有効にする場合、 編集ボタンや追加ボタンを押下して次の情報を設定します。)
       0.0.0.0:80
       [::]:80


    図7.6.4.11-1


  2. 「更新」ボタンを押下することで、設定内容が定義情報ファイル に反映されます。

  3. Webサーバを再起動することで、設定内容が反映されます。

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

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

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

ポート番号の設定

  1. WebOTX Webサーバのポート番号を変更するには、以下のコマンドを実行します。

    otxadmin>set server.WebServer.port=0.0.0.0:80,[::]:80
    
  2. Webサーバを再起動することで、設定内容が反映されます。

上記の操作を行うことで、定義情報ファイルには、次の設定が反映されます。

#Listen 80
 Listen 0.0.0.0:80
 Listen [::]:80

それぞれIPアドレスに対して指定したポート番号で受付可能状態に なっているかを確認するには、netstat コマンド等を利用し、設定したポート番号が LISTENING 状態となっていることを確認してください。
次の例では、 IPv4 および IPv6 のそれぞれのアドレスに対して ポート番号 80 がLISTENING 状態(リクエスト受付可能状態)になっている ことを意味します。

>netstart -an
 Proto Local Address Foreign Address State
 TCP   0.0.0.0:80         0.0.0.0:0         LISTENING
 …
 TCP   [::]:80                [::]:0             LISTENING        0
 …

 

7.6.4.12. システム環境変数の設定

(UNIX)
LoadModule 指示子を利用してモジュールの動的ロードを行う場合、 モジュールが利用するライブラリをロードするために、 あらかじめシステム環境変数(LD_LIBRARY_PATH/SHLIB_PATH等)にライブラリ情報 を登録しておく必要がある場合があります。

この場合、次のファイルに必要となるシステム環境変数の設定を 追加してください。

${AS_INSTALL}/WebServer2/bin/envvars
<<envvarsの内容>>

LD_LIBRARY_PATH="xxx:/opt/WebOTX/WebServer22/lib:$LD_LIBRARY_PATH"
export LD_LIBRARY_PATH

 

7.6.4.13. 起動待ち合わせ時間の設定

WebOTX Webサーバは、WebOTX Application Server の起動と連動しており、 WebOTX Application Server の起動と同時にWebOTX Webサーバに対して、 アライブチェックモニタ機能が動作します。

WebOTX Webサーバの起動タイミングとアライブチェックモニタの 開始タイミングによっては、Webサーバが完全に起動する前に、 アライブチェックモニタ機能が動作するため、「Webサーバが起動していない」 というログが出力される場合があります。

この場合、WebOTX Application Server の JavaVM のオプションに次の設定を行うことで、Webサーバ起動後に アライブチェックモニタ機能を開始する時間(待ち合わせ時間) を秒単位で指定することができます。

あらかじめ、otxadminコマンドを起動し、ドメインにログインし、次のコマンドを実行します。

otxadmin>create-jvm-options -Dwebotx.webserver.startup_wait_count=xxx(秒単位)


7.6.4.14. WebOTX Webサーバ起動失敗時の対処方法について

WebOTX Webサーバの起動/停止は、WebOTX Application Server のドメイン起動/停止に連動していますが、ポートの重複や定義情報の設定ミス等 により、WebOTX Webサーバの起動に失敗する場合があります。

WebOTX Webサーバの起動に失敗した場合、次のファイルに エラーメッセージが出力されますので、その内容を確認し、 エラー発生箇所を修正し、WebOTX Webサーバの再起動を行ってください。

エラー出力先)
  /opt/WebOTX/domains/domain1/logs/webotx_agent.log
  /opt/WebOTX/domains/domain1/logs/web/webotx_websv.log

エラーメッセージ内容)
  OTX05230002: execute ExecException occurred
  Error: com.nec.webotx.enterprise.util.ExecException: abnormal sub process termination:
  Detailed Message: Error Message

または
  OTX05230002: コマンドの実行(execute)で例外(ExecException)が発生しました。(com.nec.webotx.enterprise.syste.webserver)
  Error: com.nec.webotx.enterprise.util.ExecException: abnormal sub process termination:
  Detailed Message: Error Message

Error Message には起動に失敗した原因を意味する メッセージが出力されます。

Webサーバの起動に失敗する主な原因は次のことが考えられます。

失敗原因についての詳細については、 [ トラブルシューティングガイド > 2. 障害解析 > 2.4. 機能別リンク > 2.4.9. Webサーバ(Apache HTTP Serverベース) ] を参照してください。

7.6.5. 注意・制限事項

WebOTX Webサーバの注意・制限事項については、[ 注意制限事項 > 2. Webサーバ(Apache HTTP Serverベース) ]を参照してください。


7.7. 分散管理サーバ

7.7.1. はじめに

分散管理サーバに関する運用操作法について説明します。おおまかな操作の流れは次の通りです。
  1. ドメイングループの登録
  2. 制御対象サーバ、制御対象ドメインの登録
  3. ドメイングループの管理対象一覧の更新

    以上の操作で、ドメイングループの管理対象への操作(配備以外)を行なうことができるようになります。

  4. 分散配備サービスのコンポーネントリポジトリへのコンポーネントの登録
  5. 分散配備サービスの配備構成登録
  6. 分散配備サービスの配備構成への配備先サーバ追加
  7. 分散配備サービスの配備先サーバへのコンポーネントおよび設定ファイル登録

    以上の操作で、ドメイングループの管理対象への配備操作を行なうことができるようになります。

なお、各属性の説明については、[リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) ]を参照してください。

PropertyChange
図7.7.1-1

7.7.2. ドメイングループの運用操作

ドメイングループに関する運用操作方法について説明します。

7.7.2.1. ドメイングループの登録・削除

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

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「ドメイングループ」を選択し、右クリックするか、あるいは、メニューバーの 「操作」を選択します。
  2. 表示される操作メニューから「グループの作成」または「グループの削除」を選択します。
  3. 表示される「ドメイングループの操作」ダイアログで、「実行」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、プロキシドメインにログインしておきます。

ドメイングループを作成する場合は、以下に示すcreate-domain-groupコマンドを使用します。
otxadmin> create-domain-group --anyedition=<Edition混在の許可フラグ[true|false]> --consistency=<自動的な設定差異検出の有無フラグ[true|false]> <グループ名>


ドメイングループを削除する場合は、以下に示すdelete-domain-groupコマンドを使用します。
otxadmin> delete-domain-group <グループ名>


作成済みのドメイングループを確認する場合は、以下に示すlist-domain-groupsコマンドを使用します。
otxadmin> list-domain-groups


7.7.2.2. 制御対象サーバの登録・削除

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

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「ドメイングループ」-「<グループ名>」-「制御対象サーバ」 を選択し、右クリックするか、あるいは、メニューバーの「操作」を選択します。
  2. 表示される操作メニューから「制御対象サーバの登録」または「制御対象サーバの削除」を選択します。
  3. 表示される「制御対象サーバの操作」ダイアログで、「実行」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、プロキシドメインにログインしておきます。

  1. 制御対象サーバを登録する場合は、create-wdc-controlled-serverコマンドを使用します。
    otxadmin> create-wdc-controlled-server --domainGroup <ドメイングループ名> --jmxAdminRemoteURL <管理ドメインのJMX Remote URL> <制御対象サーバ名>


  2. 制御対象サーバを削除する場合は、delete-wdc-controlled-serverコマンドを使用します。
    otxadmin> delete-wdc-controlled-server --domainGroup <ドメイングループ名> <制御対象サーバ名>


7.7.2.3. 制御対象ドメインの登録・削除

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

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「ドメイングループ」-「<グループ名>」-「制御対象サーバ」- 「<制御対象サーバ名>」-「制御対象ドメイン」を選択し、右クリックするか、あるいは、メニューバーの「操作」を選択 します。
  2. 表示される操作メニューから「制御対象ドメインの登録」または「制御対象ドメインの削除」を選択します。
  3. 表示される「制御対象ドメインの操作」ダイアログで、「実行」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、プロキシドメインにログインしておきます。

  1. 制御対象ドメインを登録する場合は、create-wdc-controlled-domainコマンドを使用します。
    otxadmin> create-wdc-controlled-domain --domainGroup <ドメイングループ名> --controlledServerName <制御対象サーバ名> --jmxRemoteURL <制御対象ドメインのJMX Remote URL> <制御対象ドメイン名>


  2. 制御対象ドメインを削除する場合は、delete-wdc-controlled-domainコマンドを使用します。
    otxadmin> delete-wdc-controlled-domain --domainGroup <ドメイングループ名> --controlledServerName <制御対象サーバ名> <制御対象ドメイン名>


次に、この操作により登録したドメイン環境を、後述するドメインの起動/停止や一括操作などの運用のためのグルーピング対象/非対象 とするために、以下の操作を行います。
統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりプロキシドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「ドメイングループ」-「<グループ名>」を選択し、右クリック するか、あるいは、メニューバーの「操作」を選択します。
  2. 表示される操作メニューから「ドメインの登録」または「ドメインの削除」を選択します。
  3. 表示される「<グループ名>の操作」ダイアログで、「実行」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、プロキシドメインにログインしておきます。

グループ内に運用対象とするドメインを登録する場合は、以下に示すadd-group-domainコマンドを使用します。
otxadmin> add-group-domain --groupname <グループ名> --replace=<固有情報再設定の要否フラグ[true|false]> <ホスト名> <ドメイン名>

グループ内から運用対象とするドメインを削除する場合は、以下に示すremove-group-domainコマンドを使用します。
(注意) この操作により、実際のドメイン環境(のファイルやリソース)が削除されることはありません。
otxadmin> remove-group-domain --groupname <グループ名> <ホスト名> <ドメイン名>

グループ内に登録済みのドメインを確認する場合は、以下に示すlist-group-domainsコマンドを使用します。
otxadmin> list-group-domains <グループ名>


ここで、上述の制御対象サーバの登録(7.7.2.2. 制御対象サーバの登録・削除)および制御対象ドメインの登録(7.7.2.3. 制御対象ドメインの登録・削除)の作業を、登録対象のドメインを管理するホスト上の管理ドメインによって自動化することができます。登録対象のホスト上のドメインが、VMwareなどの仮想化ソフトウェアが作成・展開したイメージを用いて動作し、そのような環境を複数台構築する場合などには、本機能により構築時間を短縮できます。 本機能を使用する場合、マスタ・イメージにおける登録対象のドメインを管理する管理ドメインにおいて、次の作業を実施します。
統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールより管理ドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」を選択し、右クリック するか、あるいは、メニューバーの「操作」を選択します。
  2. 表示される操作メニューから「分散管理サーバ」-「プロキシドメインへのドメイン登録のための設定」を選択します。
  3. 表示される「WebOTX管理ドメイン[<ホスト名>]の操作」ダイアログで、プロキシドメイン上のドメイングループへ制御対象とするドメインを登録するためのパラメータを入力し、「実行」ボタンをクリックします。
  4. 上記操作により設定した情報を確認するには、「分散管理サーバ」-「プロキシドメインへのドメイン登録のための設定情報一覧の表示」を選択します。表示される「WebOTX管理ドメイン[<ホスト名>]の操作」ダイアログで、「実行」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、管理ドメインにログインしておきます。

プロキシドメイン上のドメイングループへ制御対象とするドメインを登録するために、以下に示すinvokeコマンドを使用します。
otxadmin> invoke domain.setupForProxy <ドメイン名> <プロキシドメインに対するJMXリモート接続URL> <プロキシドメインに対するJMXリモート接続時のセキュリティ機能の有無[true|false]> <登録対象のドメイングループ名のリスト> <ドメイン固有情報に対する再設定処理の要否[true|false]>

上記コマンドにより設定した情報を確認するには、以下に示すinvokeコマンドを使用します。
otxadmin> invoke domain.listSetupInfoForProxy

本操作後、登録対象のドメイン起動時には、上記で設定した情報を基に、プロキシドメイン上のドメイングループに対して自動的に制御対象サーバおよび制御対象ドメインの登録処理が実施されます。
なお、登録対象のドメイン起動の際には、予めプロキシドメインが起動しており、登録対象のドメイングループが存在している必要があります。

7.7.2.4. ドメインの起動・停止

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

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「ドメイングループ」-「<グループ名>」を選択し、右クリック するか、あるいは、メニューバーの「操作」を選択します。
  2. 表示される操作メニューから「ドメインの起動」または「ドメインの停止」を選択します。グループ内の個々のドメインを起動 または停止するには、操作メニューから「特定のドメインの起動」または「特定のドメインの停止」を選択します。
  3. 表示される「<グループ名>の操作」ダイアログで、「実行」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、プロキシドメインにログインしておきます。

  1. グループ内のドメインを全て起動する場合は、以下に示すstart-group-domainコマンドを使用します。
    ※グループ内の個々のドメインは、並列に起動処理が開始されます。
    otxadmin> start-group-domain --waitingtimeout <タイムアウト時間(秒)> <グループ名>

    グループ内の特定のドメインを起動する場合は、以下に示すstart-group-domainコマンドを使用します。
    otxadmin> start-group-domain --targethost <ホスト名> --targetdomain <ドメイン名> --waitingtimeout <タイムアウト時間(秒)> <グループ名>

  2. グループ内のドメインを全て停止する場合は、以下に示すstop-group-domainコマンドを使用します。
    ※グループ内の個々のドメインは、並列に停止処理が開始されます。
    otxadmin> stop-group-domain --waitingtimeout <タイムアウト時間(秒)> --force=<タイムアウト時の強制停止フラグ[true|false]> <グループ名>

    グループ内の特定のドメインを停止する場合は、以下に示すstop-group-domainコマンドを使用します。
    otxadmin> stop-group-domain --targethost <ホスト名> --targetdomain <ドメイン名> --waitingtimeout <タイムアウト時間(秒)> --force=<タイムアウト時の強制停止フラグ[true|false]> <グループ名>

7.7.2.5. 管理対象一覧の更新

(注意) この操作を行う際には、グループ内のドメインが起動している必要があります。

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

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「ドメイングループ」-「<グループ名>」を選択し、右クリックするか、 あるいは、メニューバーの「操作」を選択します。
  2. 表示される操作メニューから「管理対象一覧の更新」を選択します。
  3. 表示される「<グループ名>の操作」ダイアログで、「実行」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、プロキシドメインにログインしておきます。

  1. 以下に示すrefresh-management-objectsコマンドを使用します。
    otxadmin> refresh-management-objects <グループ名>


7.7.2.6. 管理対象ドメインへのJMX接続タイムアウトについて

ドメイングループ内の各管理対象ドメインへのJMX接続のタイムアウトは以下の手順で変更可能です。

接続のアイドルタイムアウト時間

管理対象ドメインに対し、以下のシステムプロパティを設定することで指定可能です。この値は、設定された管理対象ドメインに対する接続のみに有効な値です。

com.nec.webotx.rmi.transport.tcp.readTimeout=<タイムアウト値[ms]>

設定方法は [ドメイン構築・基本設定ガイド] > [3. ドメイン] > [3.8. Java VMオプションの設定] > [3.8.2. ユーザ独自のJavaVMオプションの追加方法] を参照してください。

初期接続のタイムアウト時間

proxyドメインに対し、以下のシステムプロパティを設定することで指定可能です。この値は、proxyドメインから接続する全ての管理対象ドメインへの接続に対し有効な値です。

com.nec.webotx.rmi.transport.connectTimeout=<タイムアウト値[ms]>

既定値は10[s]です。

設定方法は [ドメイン構築・基本設定ガイド] > [3. ドメイン] > [3.8. Java VMオプションの設定] > [3.8.2. ユーザ独自のJavaVMオプションの追加方法] を参照してください。


7.7.3. 制御対象ドメインの一括操作

グループ内に登録されたドメインに対して、一括した運用操作を行うための方法について説明します。

7.7.3.1. 管理対象の設定更新

グループ内に登録されたドメインに対して、個々のドメイン内の管理対象に対する同一の設定項目を一括して変更するためには、次の 操作を行います。

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

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「ドメイングループ」-「<グループ名>」配下に、登録されたドメイン上 の管理対象が表示されていることを確認します。表示されていない場合は、先述の「管理対象一覧の更新」操作を予め実施します。
  2. 設定を変更する管理対象を選択し、画面右側に表示される属性ビューから、設定を変更する項目に対して新しい設定値を入力します。
  3. 入力完了後、「更新」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 以下に示すsetコマンドを使用します。
    otxadmin> set domain.groups.<グループ名>.<管理対象名>.<属性名>=<設定値>

    ここで、<管理対象名>および<属性名>には、通常のドメインに対してsetコマンドで指定する管理対象名(CLIName)および 属性名が該当します。

    (例) JVM構成の最大ヒープサイズを変更する場合

    管理対象名:server.java-config、属性名:max-heap-size

    従って、ドメイングループに対して同一の設定を行う場合には、次のように指定します。

    (例) グループ名 dg1 、最大ヒープサイズ 1024MB の場合
    set domain.groups.dg1.server.java-config.max-heap-size=1024m

7.7.4. 分散配備サービスの運用操作

分散配備のサービスMOに関する運用操作法について説明します。

7.7.4.1. 分散配備サービスの設定

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

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」を選択します。
  2. リストビューから変更したい属性を選択して変更します。
  3. 「更新」ボタンをクリックして変更を反映します。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

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

    例) 1つの項目(タイムアウト)を参照する場合
    otxadmin> get domain.ddeployment.ddeployTimeout

    例) すべての項目を参照する場合
    otxadmin> get domain.ddeployment.*


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

    例) タイムアウトを設定する場合
    otxadmin> set domain.ddeployment.ddeployTimeout=600


7.7.4.2. 分散配備サービスの起動・停止

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

分散配備サービスの停止中は、配備に関わる操作は実行できません。情報の登録・削除等の操作は実行できます。



  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」を選択し、右クリックするか、あるいは、メニューバーの[操作] を選択します。
  2. 表示されるメニューから「分散配備機能の開始」または「分散配備機能の停止」を選択します。
  3. 表示される「分散配備の操作」ダイアログで、「実行」ボタンをクリックします。
  4. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 分散配備サービスを開始する場合は、start-ddeploy-serviceコマンドを使用します。
    otxadmin> start-ddeploy-service


  2. 分散配備サービスを停止する場合は、stop-ddeploy-serviceコマンドを使用します。
    otxadmin> stop-ddeploy-service


7.7.4.3. 分散配備サービスの初期化

分散配備サービスに登録されているコンポーネントに関わる全ての情報を削除することができます。
統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。また、この操作はデフォルトでは表示されません。
[ 運用ツールガイド > 2.11.2. 画面表示 ]の「操作の表示レベル」を、「詳細レベルの情報を表示」 や「全レベルの情報を表示」に変更してください。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」を選択し、右クリックするか、あるいは、メニューバーの[操作] を選択します。
  2. 表示されるメニューから「分散配備サービスの初期化」を選択します。
  3. 表示される「分散配備の操作」ダイアログで、「実行」ボタンをクリックします。
  4. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 分散配備サービスの初期化を行うためには、clear-ddeploy-serviceコマンドを使用します。
    otxadmin> clear-ddeploy-service


7.7.5. コンポーネントの管理

分散配備では、アプリケーションや設定ファイルをコンポーネントとして管理します。 それらの各種コンポーネントに関する運用操作法について説明します。

7.7.5.1. コンポーネントリポジトリへの登録・削除

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

  1. 登録するコンポーネントの種類に応じて「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」-「コンポーネントリポジトリ」配下のEJBコンポーネントまたはESBサービスアセンブリ、 JavaEEアプリケーション、Webコンポーネント、CORBAコンポーネント、その他のコンポーネントのいずれかを選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「コンポーネントの登録」または「コンポーネントの削除」を選択します。
  3. 登録を行う場合は最低限コンポーネントIDとファイルパスを設定します。削除を行う場合は削除するコンポーネントのIDを選択します。
  4. 表示される「コンポーネントの操作」ダイアログで、「実行」ボタンをクリックします。
  5. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

コンポーネントの削除は、コンポーネントを直接選択して実行することもできます。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. コンポーネントを登録する場合は、ddeploy-register-componentコマンドを使用します。
    otxadmin> ddeploy-register-component --componentType ejb --componentId ejb1 ./ejb/sample.jar


  2. コンポーネントを削除する場合は、ddeploy-unregister-componentコマンドを使用します。
    otxadmin> ddeploy-unregister-component ejb1


7.7.5.2. 配備構成への追加・削除

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

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」-「配備構成」-「<配備構成名>」-「<サーバ名>」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「コンポーネントの追加」または「コンポーネントの削除」を選択します。
  3. 表示される「<サーバ名>の操作」ダイアログで、リストボックスからコンポーネントIDを選択します。
  4. 「実行」ボタンをクリックします。
  5. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

コンポーネントの削除は、コンポーネントを直接選択して実行することもできます。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. コンポーネントを追加する場合は、ddeploy-link-componentコマンドを使用します。
    otxadmin> ddeploy-link-component --constitutionName constitusion1 --serverName apg1-pg1 ejb1


  2. コンポーネントを削除する場合は、ddeploy-unlink-componentコマンドを使用します。
    otxadmin> ddeploy-unlink-component --constitutionName constitusion1 --serverName apg1-pg1 ejb1


7.7.5.3. アーカイブファイルの取り出し

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

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」-「コンポーネントリポジトリ」配下のEJBコンポーネントまたはESBサービスアセンブリ、 JavaEEアプリケーション、Webコンポーネント、CORBAコンポーネント、その他のコンポーネントのいずれかを選択して、その配下の「<コンポーネントID>」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「アーカイブファイルの取り出し」を選択します。
  3. 表示される「<コンポーネントID>の操作」ダイアログで、必要に応じて出力先ディレクトリを変更します。
  4. 「実行」ボタンをクリックします。
  5. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. アーカイブファイルの取り出しを行う場合は、ddeploy-export-componentコマンドを使用します。
    otxadmin> ddeploy-export-component --path ../backup ejb1


7.7.5.4. CORBAコンポーネントの登録

CORBAコンポーネントの登録について説明します。

CORBAコンポーネントは、makecpkコマンドで作成したアーカイブファイル(cpk)を登録してください。

R5形式のCORBAアプリケーションを登録する場合は、アーカイブファイルに含まれるプロパティファイル名(拡張子を除く)を、 コンポーネントIDとして指定してください。プロパティファイルは、コンポーネント初期化ファイル名(component.initfuncで指定)が指定されているファイルです。 例として、corbaap.propertiesに指定されている場合は、corbaapをコンポーネントIDとして指定します。

CORBAアプリケーションの配備時に名前サーバへの登録も行う場合は、あらかじめ、名前サーバ登録情報ファイルをコンポーネントリポジトリに登録する必要があります。 名前サーバ登録情報ファイルは、「その他のコンポーネント」に登録します。その際、コンポーネントタイプとして「名前サーバ登録情報ファイル」 を指定します。登録した名前サーバ登録情報ファイルのコンポーネントIDを、CORBAコンポーネントの「名前サーバ登録情報ファイルコンポーネントID」 属性に指定します。

7.7.5.5. 共有コンポーネントの登録

共有コンポーネントの登録について説明します。

共有コンポーネントは、「その他のコンポーネント」に登録します。その際、コンポーネントタイプとして「共有コンポーネント」を指定します。

共有コンポーネントは、makecpkコマンドで作成したアーカイブファイル(spk)を登録してください。

7.7.5.6. 名前サーバ登録情報ファイルの登録

名前サーバ登録情報ファイルの登録について説明します。

名前サーバ登録情報ファイルは、CORBAアプリケーションの配備時に名前サーバへの登録を行う際、必要とする情報を記述したものです。

名前サーバ登録情報ファイルは、「その他のコンポーネント」に登録します。その際、コンポーネントタイプとして「名前サーバ登録情報ファイル」 を指定します。

名前サーバ登録情報ファイルは、次のxmlフォーマットに従って作成してください。


<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<DDNameServerInformation>
    <DDCORBAInterfaceInformation>
        <InterfaceName>インタフェース名</InterfaceName>
        <ConnectCtrlPolicy>コネクション制御ポリシ</ConnectCtrlPolicy>
        <SystemSetupRefer>TPシステム設定の参照の有無</SystemSetupRefer>
        <BindType>オブジェクトリファレンスのポリシ</BindType>
        <UseMultiServer>登録するIORの生成方式(マルチサーバ使用有無)</UseMultiServer>
        <MultiServerID>マルチサーバのシステムグループ名</MultiServerID>
        <RoundRobinFunction>ラウンドロビン機能を使用有無</RoundRobinFunction>
        <RegisterName>名前サーバ登録名</RegisterName>
        <RegisterName>名前サーバ登録名</RegisterName>
    </DDCORBAInterfaceInformation>
</DDNameServerInformation>
要素名 説明 子要素 設定先
DDNameServerInformation 名前サーバ登録情報を設定します。名前サーバ登録情報ファイル内に1個だけ存在します。 DDCORBAInterfaceInformation[1]
DDCORBAInterfaceInformation DDNameServerInformation内に1個だけ記述します。 InterfaceName[0,1]
ConnectCtrlPolicy[0,1]
SystemSetupRefer[0,1]
BindType[0,1]
UseMultiServer[0,1]
MultiServerID[0,1]
RoundRobinFunction[0,1]
RegisterName[1,*]
InterfaceName インタフェース名を指定します。DDCORBAInterfaceInformation内に0個または1個だけ記述します。
ConnectCtrlPolicy コネクション制御ポリシを設定します。DDCORBAInterfaceInformation内に0個または1個だけ記述します。
指定された値は「設定先」の属性に設定されます。設定値は、BYHOST(ホスト単位), BYREFERENCE(オブジェクト単位) または NOREUSE(コネクションを再利用しない) です。
WebOTXCORBAObject MO の connectCtrlPolicy属性
SystemSetupRefer 非推奨 since V9.2
下位互換性維持の為に存在しています。本要素に指定された値は無視されます。
WebOTXCORBAObject MO の systemSetupRefer属性
BindType 名前サーバへの登録方法を設定します。
DDCORBAInterfaceInformation内に0個または1個だけ記述します。
指定された値は「設定先」の属性に設定されます。設定値は、TEMPORARY(一時的に扱う) または PERSIST(永続的に扱う) です。
WebOTXCORBAObject MO の bindType属性
UseMultiServer 非推奨 since V9.2
下位互換性維持の用に存在しています。本要素に指定された値は無視されます。
マルチサーバを使用する場合は、MultiServerIDを指定してください。
WebOTXCORBAObject MO の useMultiServer属性
MultiServerID 複数サーバ設定を行うときシステムグループを設定します。
DDCORBAInterfaceInformation内に0個または1個だけ記述します。
指定された値は「設定先」の属性に設定されます。設定値は設定先の属性値に従ってください。
WebOTXCORBAObject MO の multiServerID属性
RoundRobinFunction ラウンドロビン機能の利用を設定します。
DDCORBAInterfaceInformation内に0個または1個だけ記述します。
指定された値は「設定先」の属性に設定されます。設定値は、true または false です。
WebOTXCORBAObject MO の roundRobinFunction属性
RegisterName 名前サーバへの登録名を指定します。名前サーバへのIOR登録URLをcorbaname形式で指定します。
DDCORBAInterfaceInformation内に1個以上、任意の数だけ記述できます。
指定された値は「設定先」の属性に設定されます。設定値は設定先の属性値に従ってください。
WebOTXCORBAObject MO の urlList属性

7.7.6. 配備構成の管理

分散配備では、配備先サーバや配備対象のコンポーネントの組み合わせを配備構成として管理します。 その配備構成や、その配下の配備先サーバとコンポーネント、設定ファイルに関する運用操作法について説明します。

7.7.6.1. 配備構成の登録・削除・複製

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

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」-「配備構成」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「配備構成の登録」または「配備構成の削除」、「配備構成の複製」を選択します。
  3. 表示される「配備構成の操作」ダイアログで、配備構成名やドメイングループ名を指定します。
  4. 「実行」ボタンをクリックします。
  5. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

あらかじめドメイングループの登録(7.7.2.1. ドメイングループの登録・削除)を行っておくと、配備構成の登録時にリストボックスからドメイングループの名前を選択することができます。
配備構成の削除は、配備構成を直接選択して実行することもできます。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 配備構成を登録する場合は、ddeploy-add-constitutionコマンドを使用します。
    otxadmin> ddeploy-add-constitution --domainGroup group1 constitusion1


  2. 配備構成を削除する場合は、ddeploy-delete-constitutionコマンドを使用します。
    otxadmin> ddeploy-delete-constitution constitusion1


  3. 配備構成を複製する場合は、ddeploy-copy-constitutionコマンドを使用します。
    otxadmin> ddeploy-copy-constitution --constitutionName constitusion1 constitution2


7.7.6.2. サーバの追加・削除

WebOTX AS Standard/Enterpriseのプロセスグループに対してアプリケーションを配備する場合には、サーバの追加を行う必要があります。ドメインのエージェントプロセスに対して アプリケーションを配備する場合は、自動的に生成される"server"を利用します。
統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」-「配備構成」-「<配備構成名>」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「サーバの追加」または「サーバの削除」を選択します。
  3. 表示される「<配備構成名>の操作」ダイアログで、リストボックスからサーバ名を選択します。リストボックスが表示されない場合は、 アプリケーショングループ名-プロセスグループ名の形式で名前を入力してください。
  4. 「実行」ボタンをクリックします。
  5. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

あらかじめ、ドメイングループで管理対象一覧の更新(7.7.2.5. 管理対象一覧の更新)を行っておくと、サーバの追加時にリストボックスからサーバ名を選択することができます。 サーバの削除は、サーバを直接選択して実行することもできます。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 配備構成を登録する場合は、ddeploy-add-serverコマンドを使用します。
    otxadmin> ddeploy-add-server --constitutionName constitution1 apg1-pg1


  2. 配備構成を削除する場合は、ddeploy-delete-serverコマンドを使用します。
    otxadmin> ddeploy-delete-server --constitutionName constitution1 apg1-pg1


7.7.6.3. コンポーネントの追加・削除

7.7.5.2. 配備構成への追加・削除を参照してください。

7.7.6.4. 設定ファイルの追加・削除

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

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」-「配備構成」-「<配備構成名>」-「設定ファイル」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「設定ファイルの追加」または「設定ファイルの削除」を選択します。
  3. 表示される「設定ファイルの操作」ダイアログで、リストボックスからコンポーネントIDを選択します。
  4. 「実行」ボタンをクリックします。
  5. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

設定ファイルの削除は、設定ファイルを直接選択して実行することもできます。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 設定ファイルを追加する場合は、ddeploy-link-configurationコマンドを使用します。
    otxadmin> ddeploy-link-configuration --constitutionName constitution1 domain.properties


  2. 設定ファイルを削除する場合は、ddeploy-unlink-configurationコマンドを使用します。
    otxadmin> ddeploy-unlink-configuration --constitutionName constitution1 domain.properties


7.7.7. 配備操作

分散配備の様々な配備操作に関する運用操作法について説明します。

7.7.7.1. コンポーネントリポジトリの配備操作

コンポーネントリポジトリの配備操作を実行することで、登録されている全てのコンポーネントの配備操作を実行することができます。

7.7.7.2. 配備構成の配備操作

配備構成の配備操作を実行することで、特定の構成のシステムやサーバ(プロセスグループやエージェントプロセス)に配備を行うことができます。

自動配備対象ドメイン一覧に、配備操作の対象となる配備構成が存在する場合、配備操作を実行することはできません。
自動配備対象予約を取り消して配備操作を実行する場合には、自動配備対象ドメイン状態監視を停止後、 手動で「自動配備対象ドメイン一覧」属性からドメイン情報を削除してから、配備操作を行なってください。

CORBAコンポーネントの配備操作については、7.7.7.13. CORBAコンポーネントの配備操作も参照してください。

共有コンポーネントの配備操作については、7.7.7.14. 共有コンポーネントの配備操作も参照してください。

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

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」-「配備構成」-「<配備構成名>」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「配備操作の実行」を選択します。
  3. 表示される「<配備構成名>の操作」ダイアログで、リストボックスから実行する配備操作とドメイングループ名を選択します。
  4. 「実行」ボタンをクリックします。
  5. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

統合運用管理ツールから行った配備操作は、非同期に終了します。配備操作の進捗状況は、7.7.7.6. 配備操作状況の確認で確認してください。
非常に大きなアプリケーションを配備する場合は、タイムアウトの指定を調整してください。デフォルト値を変更する場合は、分散配備サービスMOのタイムアウトの値を変更してください。
障害等で配備を中断した後に再実行する場合は、配備制御モードにrecoveryやforceを指定してください。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 配備および開始操作を実行する場合は、ddeploy-deployコマンドを使用します。
    otxadmin> ddeploy-deploy --constitutionName constitution1


  2. 停止および配備解除操作を実行する場合は、ddeploy-undeployコマンドを使用します。
    otxadmin> ddeploy-undeploy --constitutionName constitution1


  3. 開始操作を実行する場合は、ddeploy-startコマンドを使用します。
    otxadmin> ddeploy-start --constitutionName constitution1


  4. 停止操作を実行する場合は、ddeploy-stopコマンドを使用します。
    otxadmin> ddeploy-stop --constitutionName constitution1


  5. 配備操作を実行する場合は、ddeploy-distributeコマンドを使用します。
    otxadmin> ddeploy-distribute --constitutionName constitution1


  6. 置換操作を実行する場合は、ddeploy-replaceコマンドを使用します。
    otxadmin> ddeploy-replace --constitutionName constitution1


コマンドからの配備操作は、完了するまで応答が返りません。
各コマンドの詳細は、otxadminコマンドのhelpコマンドで説明を表示するか、[ リファレンス集 運用管理・設定編 > 4. 運用管理コマンドリファレンス > 4.2.2. コマンド検索一覧 > 運用管理コマンド (otxadmin) リファレンス ]を参照してください。

7.7.7.3. 配備先サーバの配備操作

配備先サーバの配備操作を実行することで、特定のサーバ(プロセスグループやエージェントプロセス)への配備を行うことができます。

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

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」-「配備構成」-「<配備構成名>」-「<サーバ名>」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「配備操作の実行」を選択します。
  3. 表示される「<サーバ名>の操作」ダイアログで、リストボックスから実行する配備操作とドメイングループ名を選択します。
  4. 「実行」ボタンをクリックします。
  5. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

統合運用管理ツールから行った配備操作は、非同期に終了します。配備操作の進捗状況は、7.7.7.6. 配備操作状況の確認で確認してください。
非常に大きなアプリケーションを配備する場合は、タイムアウトの指定を調整してください。デフォルト値を変更する場合は、分散配備サービスMOのタイムアウトの値を変更してください。
障害等で配備を中断した後に再実行する場合は、配備制御モードにrecoveryやforceを指定してください。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 配備および開始操作を実行する場合は、ddeploy-deployコマンドを使用します。
    otxadmin> ddeploy-deploy --constitutionName constitution1 --serverName apg1-pg1


  2. 停止および配備解除操作を実行する場合は、ddeploy-undeployコマンドを使用します。
    otxadmin> ddeploy-undeploy --constitutionName constitution1 --serverName apg1-pg1


  3. 開始操作を実行する場合は、ddeploy-startコマンドを使用します。
    otxadmin> ddeploy-start --constitutionName constitution1 --serverName apg1-pg1


  4. 停止操作を実行する場合は、ddeploy-stopコマンドを使用します。
    otxadmin> ddeploy-stop --constitutionName constitution1 --serverName apg1-pg1


  5. 配備操作を実行する場合は、ddeploy-distributeコマンドを使用します。
    otxadmin> ddeploy-distribute --constitutionName constitution1 --serverName apg1-pg1


  6. 置換操作を実行する場合は、ddeploy-replaceコマンドを使用します。
    otxadmin> ddeploy-replace --constitutionName constitution1 --serverName apg1-pg1


コマンドからの配備操作は、完了するまで応答が返りません。
各コマンドの詳細は、otxadminコマンドのhelpコマンドで説明を表示するか、[ リファレンス集 運用管理・設定編 > 4. 運用管理コマンドリファレンス > 4.2.2. コマンド詳細 > コマンド索引一覧 ]を参照してください。

7.7.7.4. コンポーネントの配備操作

コンポーネントリポジトリに登録されているコンポーネントを個別に配備することができます。

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

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」-「コンポーネントリポジトリ」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「配備操作の実行」を選択します。
  3. 表示される「コンポーネントリポジトリの操作」ダイアログで、リストボックスから実行する配備操作とドメイングループ名を選択します。配備するコンポーネントIDを追加します。配備先のサーバ名を入力します。
  4. 「実行」ボタンをクリックします。
  5. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

統合運用管理ツールから行った配備操作は、非同期に終了します。配備操作の進捗状況は、7.7.7.6. 配備操作状況の確認で確認してください。
非常に大きなアプリケーションを配備する場合は、タイムアウトの指定を調整してください。デフォルト値を変更する場合は、分散配備サービスMOのタイムアウトの値を変更してください。
障害等で配備を中断した後に再実行する場合は、配備制御モードにrecoveryやforceを指定してください。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 配備および開始操作を実行する場合は、ddeploy-deployコマンドを使用します。
    otxadmin> ddeploy-deploy --domainGroup domain1 --serverName apg1-pg1 --componentId ejb1


  2. 停止および配備解除操作を実行する場合は、ddeploy-undeployコマンドを使用します。
    otxadmin> ddeploy-undeploy --domainGroup domain1 --serverName apg1-pg1 --componentId ejb1


  3. 開始操作を実行する場合は、ddeploy-startコマンドを使用します。
    otxadmin> ddeploy-start --domainGroup domain1 --serverName apg1-pg1 --componentId ejb1


  4. 停止操作を実行する場合は、ddeploy-stopコマンドを使用します。
    otxadmin> ddeploy-stop --domainGroup domain1 --serverName apg1-pg1 --componentId ejb1


  5. 配備操作を実行する場合は、ddeploy-distributeコマンドを使用します。
    otxadmin> ddeploy-distribute --domainGroup domain1 --serverName apg1-pg1 --componentId ejb1


  6. 置換操作を実行する場合は、ddeploy-replaceコマンドを使用します。
    otxadmin> ddeploy-replace --domainGroup domain1 --serverName apg1-pg1 --componentId ejb1


コマンドからの配備操作は、完了するまで応答が返りません。
各コマンドの詳細は、otxadminコマンドのhelpコマンドで説明を表示するか、[ リファレンス集 運用管理・設定編 > 4. 運用管理コマンドリファレンス > 4.2.2. コマンド詳細 > コマンド索引一覧 ]を参照してください。

7.7.7.5. 設定ファイルの配備操作

コンポーネントリポジトリに登録されている設定ファイルによる設定をすることができます。

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

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」-「コンポーネントリポジトリ」-「その他のコンポーネント」-「<コンポーネントID>」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「配備操作の実行」を選択します。
  3. 表示される「<コンポーネントID>の操作」ダイアログで、リストボックスからドメイングループ名を選択します。
  4. 「実行」ボタンをクリックします。
  5. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

統合運用管理ツールから行った配備操作は、非同期に終了します。配備操作の進捗状況は、7.7.7.6. 配備操作状況の確認で確認してください。
非常に大きな設定を実施する場合は、タイムアウトの指定を調整してください。デフォルト値を変更する場合は、分散配備サービスMOのタイムアウトの値を変更してください。
障害等で配備を中断した後に再実行する場合は、配備制御モードにrecoveryやforceを指定してください。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 設定を実行する場合は、ddeploy-configureコマンドを使用します。
    otxadmin> ddeploy-configure --domainGroup domain1 --componentId config1


コマンドからの配備操作は、完了するまで応答が返りません。
各コマンドの詳細は、otxadminコマンドのhelpコマンドで説明を表示するか、[ リファレンス集 運用管理・設定編 > 4. 運用管理コマンドリファレンス > 4.2.2. コマンド詳細 > コマンド索引一覧 ]を参照してください。

7.7.7.6. 配備操作状況の確認

配備操作の途中で、配備操作状況を確認することができます。

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

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「配備操作状況の参照」を選択します。
  3. 表示される「分散配備の操作」ダイアログで、必要に応じてコンポーネントの表示数を変更します。
  4. 「実行」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 配備操作状況を確認するためには、ddeploy-statusコマンドを使用します。
    otxadmin> ddeploy-status

      実行結果は次のように表示されます。

    deploy operation  [DEPLOY]
    domain group      [group5]
    status            [DONE]
    
    distributed       1/1  * 100% completed *
    now distributing  0
    
    * * running components * *
    [Host,domain group,server(target),component,elapsed time]
    Command ddeploy-status executed successfully.
    


7.7.7.7. 配備操作の中止

配備操作を途中で中止することができます。

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

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「配備操作の中止」を選択します。
  3. 表示される「分散配備の操作」ダイアログで、必要に応じて中止操作のタイムアウト時間を変更します。
  4. 「実行」ボタンをクリックします。
  5. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 配備操作を中止するためには、ddeploy-cancelコマンドを使用します。
    otxadmin> ddeploy-cancel


7.7.7.8. 配備操作の再実行

指定された配備結果レポートをもとに配備に失敗した操作のみを再実行することができます。配備結果レポートについての詳細は、[ 製品構成と提供機能 > 3. 提供機能 > 3.8.3. 分散配備 ] の「配備結果の確認機能」を参照ください。

再実行の対象が配備構成の場合、対象の配備構成の「自動配備対象ドメイン一覧」属性に自動配備予約されたドメイン情報 が存在すると、再実行はできません。再実行したい場合は、自動配備対象ドメイン状態監視を停止後、 手動で「自動配備対象ドメイン一覧」属性からドメイン情報を削除してから、再実行をしてください。

配備操作の再実行は、配備結果に記載されている配備対象および配備構成をもとに配備操作を行いますので、 配備構成が変更されている場合も変更後の配備構成は有効となりません。

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

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「配備操作の再実行」を選択します。
  3. 「実行」ボタンをクリックします。
  4. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 配備操作の再実行をするためには、ddeploy-re-operationコマンドを使用します。
    otxadmin> ddeploy-re-operation


7.7.7.9. 自動配備対象ドメイン状態監視の開始

ドメイン起動時に自動配備するためのドメイン状態監視を開始することができます。

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

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「自動配備対象ドメイン状態監視の開始」を選択します。
  3. 「実行」ボタンをクリックします。
  4. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 自動配備対象ドメイン状態監視を開始するためには、ddeploy-start-admonitorコマンドを使用します。
    otxadmin> ddeploy-start-admonitor


7.7.7.10. 自動配備対象ドメイン状態監視の停止

ドメイン起動時に自動配備するためのドメイン状態監視を停止することができます。

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

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「自動配備対象ドメイン状態監視の停止」を選択します。
  3. 「実行」ボタンをクリックします。
  4. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 自動配備対象ドメイン状態監視を停止するためには、ddeploy-stop-admonitorコマンドを使用します。
    otxadmin> ddeploy-stop-admonitor


7.7.7.11. 自動配備対象ドメイン状態監視状況の参照

ドメイン起動時に自動配備するためのドメイン状態監視状態を参照することができます。

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

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「自動配備対象ドメイン状態監視状況の参照」を選択します。
  3. 「実行」ボタンをクリックします。
  4. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. 自動配備対象ドメイン状態監視状況を参照するためには、ddeploy-admonitor-statusコマンドを使用します。
    otxadmin> ddeploy-admonitor-status


7.7.7.12. 自動配備対象ドメイン一覧

ドメイン起動時の自動配備待ちとなっているドメイン一覧を参照することができます。



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

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「proxy」-「分散配備」を選択し、右クリックするか、あるいは、メニューバーの[操作]を選択します。
  2. 表示されるメニューから「自動配備対象ドメイン一覧」を選択します。
  3. 「実行」ボタンをクリックします。
  4. 表示される「確認」ダイアログで、「はい」ボタンをクリックします。

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. ドメイン起動時の自動配備待ちとなっているドメイン一覧を参照するためには、ddeploy-reserved-domainsコマンドを使用します。
    otxadmin> ddeploy-reserved-domains


7.7.7.13. CORBAコンポーネントの配備操作

CORBAコンポーネントの配備操作について説明します。

CORBAコンポーネントの配備、再配備、配備解除を行う場合、CORBAアプリケーションの形式(「アプリケーション開発ガイド」参照)、配備先プロセスグループのバージョン によっては、アプリケーショングループが停止している必要があります。このような場合は、配備操作の実行時に「配備操作前の停止」 オプションで「通常停止」「強制停止」を指定すると、分散配備が配備操作前に配備対象アプリケーショングループを停止後、 配備処理を行います。その際、配備対象アプリケーショングループの停止に失敗すると、配備操作は失敗します。
配備対象のアプリケーショングループ、プロセスグループが多いと配備操作の実行に要する時間も長くなります。

通常のdeploy操作は、コンポーネント単位でdistribute操作、start操作を続けて実行します。
CORBAコンポーネントと共有コンポーネントのdeploy操作は、他コンポーネントとは異なり、CORBAコンポーネントと共有コンポーネント タイプの全コンポーネントのdistribute操作を実行後、全コンポーネントのstart操作を実行します。
deploy(replace)操作時、「配備操作前の停止」オプションで「通常停止」「強制停止」が指定されているとdistribute操作前に アプリケーショングループを停止し、start操作前にアプリケーショングループを開始します。
この時、アプリケーショングループの開始に失敗すると、配備操作は失敗します。

CORBAコンポーネントのdistribute操作、deploy操作時に名前サーバへの登録を行うことができます。
名前サーバへの登録を行う場合は、「その他のコンポーネント」に登録した名前サーバ登録情報ファイルのコンポーネントIDを CORBAコンポーネントの「名前サーバ登録情報ファイルコンポーネントID」に指定した状態で配備操作を行います。 名前サーバへの登録は、名前サーバ登録情報ファイルに指定された関連属性をWebOTXCORBAObject MOの属性に設定後、 名前サーバへの登録を実行します。

CORBAコンポーネントとその他の種別のコンポーネントとで配備構成を分けて作成してください。 「配備操作前の停止」にてアプリケーショングループの停止を行う場合、CORBAコンポーネントと その他の種別のコンポーネントとが混在していると、J2EEのプロセスグループも停止されます。 (J2EEとCORBAのプロセスグループが混在するアプリケーショングループの場合)

7.7.7.14. 共有コンポーネントの配備操作

共有コンポーネントの配備操作について説明します。

共有コンポーネントの配備操作を行う場合は、配備構成を登録し、server配下にコンポーネントを登録してください。


7.8. Webサービス

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

7.8.1. WS-ReliableMessagingの操作

WS-ReliableMessaging機能を使用する場合の設定項目と運用操作について説明します。

使用手順については、 [ アプリケーション開発ガイド(Java EE) > 1. Webサービスアプリケーションの開発 > 1.2. プログラミング・開発ガイド > 1.2.14. WS-ReliableMessaging > 1.2.14.1. 事前準備 ] を併せて参照してください。

7.8.1.1. 設定値の説明

WS-ReliableMessaging機能を使用する場合の設定項目について説明します。

「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「Webサービス」-「WS-ReliableMessaging」を選択します。設定はドメイン単位で有効です。

WS-ReliableMessgingの操作
図7.8.1.1-1

表7.8.1.1.-1
項目 説明 既定値
JDBCデータソースのJNDI名
WS-ReliableMessagingで利用するJDBCデータソースのJNDI名を指定します。

jdbc/WSRM
スレッドプール最大値
WS-ReliableMessagingのスレッドプールの最大値を指定します。[1-2147483647]

10
最大メッセージサイズ WS-ReliableMessagingで処理する最大メッセージサイズを指定します。0を指定すると無制限になります。(単位:MB)[0-2147483647]

4
デッドキュー保持期間
WS-ReliableMessagingで有効期限切れのメッセージをデッドキューで保持する期間を指定します。(単位:分)[1-2147483647]

43200
テーブル名プレフィックス
WS-ReliableMessagingで利用するテーブル名のプレフィックスを指定します。最大文字数は8文字です。

RMTABLES

各項目の詳細については、 [ リファレンス集 運用管理・設定編 > 1. コンフィグレーション(設定一覧) > 1.16. Webサービス > 1.16.4. WS-ReliableMessaging Webサービスの設定 ] を参照してください。

7.8.1.2. キューの表示

WS-ReliableMessagingのキューを表示します。

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

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「Webサービス」-「WS-ReliableMessaging」を選択し、右クリックするか、あるいは、メニューバーの[操作] を選択します。
  2. 表示されるメニューから「キューの表示」を選択するとダイアログが表示されます。

    WS-ReliableMessgingの操作
    図7.8.1.2-1

  3. パラメータを入力し、「実行」を選択することでキューの表示します。

    WS-ReliableMessgingの操作
    図7.8.1.2-2

    表7.8.1.2.-1
    項目 説明 既定値
    キューの種別
    キューの種別を指定します。
    "キュー" を指定した場合、現在実行中のメッセージの一覧を表示します。
    "デッドキュー"を指定した場合、アプリケーションの実行失敗したメッセージの一覧を表示します。

    キュー
    エンドポイントURI エンドポイントURIを指定します。

    空白
    取得開始日時 キュー内容を取得する開始日時を指定します。(yyyy-MM-dd hh:mm:ss)

    空白
    取得終了日時 キュー内容を取得する終了日時を指定します。(yyyy-MM-dd hh:mm:ss)

    空白
    ステータス 取得するキューのステータスを指定します。
    ステータスは、Web Services Reliable Messaging (WS-ReliableMessaging) Version 1.2 で定義される用語です。

    ALL
    日時の表示順序 キュー内容の表示順序を日時の降順または日時の昇順から指定します。

    降順
    表示件数 キュー内容の最大表示件数を指定します。[1-2147483647]

    1000

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. otxadminコマンドを起動し、ドメインにログインします。
    otxadmin> login --user admin --password adminadmin --port 6212
    
  2. キューの表示するには、以下のコマンドを実行します。
    otxadmin> invoke server.web-service.ws-rm.listRmQueues <queueType> <endpointURI> <startDate> <endDate> <status> <desc> <count>
    
    パラメータの詳細については、 [ リファレンス集 運用管理・設定編 > 2. MO定義リファレンス > ws-rm > listRmQueues(キューの表示) ] を参照してください。

7.8.1.3. メッセージのエクスポート

WS-ReliableMessagingのメッセージのエクスポートをします。出力件数が多い場合、出力に時間がかかる事があります。

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

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「Webサービス」-「WS-ReliableMessaging」を選択し、右クリックするか、あるいは、メニューバーの[操作] を選択します。
  2. 表示されるメニューから「メッセージのエクスポート」を選択するとダイアログが表示されます。

    WS-ReliableMessgingの操作
    図7.8.1.3-1

  3. パラメータを入力し、「実行」を選択することでメッセージのエクスポートします。

    WS-ReliableMessgingの操作
    図7.8.1.3-2

    表7.8.1.3.-1
    項目 説明 既定値
    キューの種別
    キューの種別を指定します。
    "キュー" を指定した場合、現在実行中のメッセージをエクスポートします。
    "デッドキュー"を指定した場合、アプリケーションの実行失敗したメッセージをエクスポートします。

    キュー
    エンドポイントURI エンドポイントURIを指定します。

    空白
    シーケンスID シーケンスIDをカンマ区切りで指定します。
    シーケンスIDは、Web Services Reliable Messaging (WS-ReliableMessaging) Version 1.2 で定義される用語です。

    空白
    メッセージ番号 メッセージ番号をカンマ区切りで指定します。
    メッセージ番号は、Web Services Reliable Messaging (WS-ReliableMessaging) Version 1.2 で定義される用語です。

    空白
    相関ID 相関IDをカンマ区切りで指定します。
    相関IDは、Web Services Reliable Messaging (WS-ReliableMessaging) Version 1.2 で定義される用語です。

    空白
    エクスポートパス メッセージをエクスポートするパスを指定します。
    指定したパスに次のファイル名で出力します。
        <エンドポイントURI(30文字打ち切り)>/<シーケンスID(UUID)>/<メッセージ番号>.log
    指定しない場合、既定で下記の場所に出力します。
        ${INSTANCE_ROOT}/logs/webservice/rm_msg/

    空白

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. otxadminコマンドを起動し、ドメインにログインします。
    otxadmin> login --user admin --password adminadmin --port 6212
    
  2. キューの表示するには、以下のコマンドを実行します。
    otxadmin> invoke server.web-service.ws-rm.exportRmMessages <queueType> <endpointURI> <sequenceID> <messageNumber> <correlationID> <directoryPath>
    
    パラメータの詳細については、 [ リファレンス集 運用管理・設定編 > 2. MO定義リファレンス > ws-rm > exportRmMessages (メッセージのエクスポート) ] を参照してください。

7.8.1.4. キュー/メッセージの削除

WS-ReliableMessagingのキュー/メッセージを削除します。

Caution
この操作は実行すると元に戻せなくなるため十分にご注意ください。
統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「Webサービス」-「WS-ReliableMessaging」を選択し、右クリックするか、あるいは、メニューバーの[操作] を選択します。
  2. 表示されるメニューから「キュー/メッセージの削除」を選択するとダイアログが表示されます。

    WS-ReliableMessgingの操作
    図7.8.1.4-1

  3. パラメータを入力し、「実行」を選択することでキュー/メッセージの削除します。

    WS-ReliableMessgingの操作
    図7.8.1.4-2

    表7.8.1.4.-1
    項目 説明 既定値
    キューの種別
    キューの種別を指定します。

    キュー
    エンドポイントURI エンドポイントURIを指定します。

    空白

運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. otxadminコマンドを起動し、ドメインにログインします。
    otxadmin> login --user admin --password adminadmin --port 6212
    
  2. キューの表示するには、以下のコマンドを実行します。
    otxadmin> invoke server.web-service.ws-rm.deleteRmMessages <queueType> <endpointURI>
    
    パラメータの詳細については、 [ リファレンス集 運用管理・設定編 > 2. MO定義リファレンス > ws-rm > deleteRmMessages (キュー/メッセージの削除) ] を参照してください。

7.8.1.5. テーブルの作成

WS-ReliableMessagingのテーブルを作成します。

Memo
この操作はWS-ReliableMessaging機能を使用する前に一度だけ実行します。
統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「Webサービス」-「WS-ReliableMessaging」を選択し、右クリックするか、あるいは、メニューバーの[操作] を選択します。
  2. 表示されるメニューから「テーブルの作成」を選択するとダイアログが表示されます。「実行」を選択することでテーブルを作成します。

    WS-ReliableMessgingの操作
    図7.8.1.5-1


運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. otxadminコマンドを起動し、ドメインにログインします。
    otxadmin> login --user admin --password adminadmin --port 6212
    
  2. テーブルを作成するには、以下のコマンドを実行します。
    otxadmin> invoke server.web-service.ws-rm.createRmTables
    

7.8.1.6. テーブルの削除

WS-ReliableMessagingのテーブルを削除します。

Caution
この操作は実行すると元に戻せなくなるため十分にご注意ください。
統合運用管理ツールからの操作
あらかじめ、統合運用管理ツールよりドメインと接続しておきます。

  1. 「WebOTX管理ドメイン[<ホスト名>]」-「<ドメイン名>」-「アプリケーションサーバ」-「Webサービス」-「WS-ReliableMessaging」を選択し、右クリックするか、あるいは、メニューバーの[操作] を選択します。
  2. 表示されるメニューから「テーブルの削除」を選択するとダイアログが表示されます。「実行」を選択することでテーブルを削除します。

    WS-ReliableMessgingの操作
    図7.8.1.6-1


運用管理コマンド(otxadmin)からの操作
あらかじめ、otxadminコマンドを起動し、ドメインにログインしておきます。

  1. otxadminコマンドを起動し、ドメインにログインします。
    otxadmin> login --user admin --password adminadmin --port 6212
    
  2. テーブルを削除するには、以下のコマンドを実行します。
    otxadmin> invoke server.web-service.ws-rm.deleteRmTables
    

7.9. インメモリデータグリッド連携部品

インメモリデータグリッド連携部品 に関する運用操作法について説明します。なお、各属性の説明については、[リファレンス集 運用管理・設定編 > 1.19. インメモリデータグリッド連携 ]を参照してください。

7.9.1. データグリッドの選択

L2キャッシュで使用するデータグリッドを指定する手順について説明します。
何も指定しない場合はEclipseLinkのL2キャッシュを使用します。

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

1.  統合運用管理ツールよりドメインと接続します。

2.  ツリービューより「<ドメイン名>」−「アプリケーションサーバ」−「永続化サービス」を選択します。

3.  「L2キャッシュで使用するデータグリッド」に使用するデータグリッド名を指定します。
 指定するデータグリッド名は、事前に「データグリッド」の設定で登録しておく必要があります。
 尚、インメモリデータグリッド連携部品用のデータグリッドは、初期設定で「__default_jpa」で登録してありますので、必要に応じて、データグリッド製品等の設定を行ってください。



図7.9.1.1-1


7.9.2.データプリロード の実行

データプリロードを実行する手順について説明します。
事前に、データプリロードの読み込み対象エンティティ、読み込みの振る舞いについて、統合運用管理ツールで設定しておく必要があります。

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

統合運用管理ツールから操作した場合は、ドメイン再起動時に有効となり、データプリロードを実行します。

1.  統合運用管理ツールよりドメインと接続します。

2.  ツリービューより「<ドメイン名>」−「アプリケーションサーバ」−「永続化サービス」−「データプリロード」を選択し、 右クリックするか、あるいは、メニューバーの[操作]を選択します。

3.  表示されるメニューから「データプリロードの実行」を選択します。



図7.9.2.1-1


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

コマンドから操作した場合は、即時データプリロードを実行します。

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

2.  データプリロードを実行する場合は次のコマンドを実行します。

otxadmin> start-data-preload


7.9.3.性能情報採取の開始・停止

性能情報採取を開始・停止する手順について説明します。


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

統合運用管理ツールから操作した場合は、ドメイン再起動時に有効となり、性能情報採取を行います。

1.  統合運用管理ツールよりドメインと接続します。

2.  ツリービューより「<ドメイン名>」−「アプリケーションサーバ」−「永続化サービス」を選択し、 右クリックするか、あるいは、メニューバーの[操作]を選択します。

3.  表示されるメニューから「性能情報採取の開始」を選択します。



図7.9.3.1-1

3.  「性能情報」−「性能情報採取ステータス」に性能情報採取の状態が、開始した場合は「実行中」、停止した場合は「停止」と表示されます。


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

コマンドから操作した場合は、即時、性能情報採取を開始します。

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

2.  性能情報採取を開始する場合は次のコマンドを実行します。

otxadmin> start-jpa-performanceinfomation

3.  逆に性能情報採取を停止する場合は次のコマンドを実行します。

otxadmin> stop-jpa-performanceinfomation


7.9.4.性能情報のリセット

採取した性能情報をリセットする場合は、コマンドから操作します。性能情報採取中には実行することができません。

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

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

2.  採取した性能情報採取をリセットする場合は次のコマンドを実行します。

otxadmin> reset-jpa-performanceinfomation


7.9.5.JPAランキング情報の利用

採取した性能情報から生成したJPAランキング情報は、データプリロードの読み込み対象の順番として利用することができます。


7.9.5.1.JPAランキング情報の生成

採取した性能情報からランキング情報を生成します。

ランキング情報を生成する場合は次のコマンドを実行します。

JPAランキング情報生成コマンドからの操作

JPAランキング情報生成コマンドの詳細は、 [ リファレンス集 運用管理・設定編 > 4. 運用管理コマンドリファレンス > 4.11. インメモリデータグリッド連携部品コマンド] 、および、 [ 製品構成と提供機能 > 3.提供機能> 3.7.12.5.JPAの性能情報プロファイルデータ ] を参照してください。



7.9.5.2. データプリロードでのJPAランキング情報の利用

JPAランキング情報を利用する場合は統合運用管理ツールから操作しします。

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

1.  統合運用管理ツールよりドメインと接続します。

2.  ツリービューより「<ドメイン名>」−「アプリケーションサーバ」−「永続化サービス」を選択します。

3.  「データプリロード」−「ランキングデータのパス」に生成したランキング情報のファイルパスを指定します。
指定しない場合は、既定値として${ AS_INSTALL }/config/jpa/Profile/Ranking/ENTITY_ranking.dat のデータが使用されます。
この既定値のファイルパスは、WebOTXシステム全てのドメインのJPAランキング情報生成コマンドの既定値の出力先となっていますのでご注意ください。 JPAランキング情報生成コマンドの実行は、出力先を変更することを推奨します。



図7.9.5.2-1


4.  ツリービューより「<エンティティ名>」−「プリロード対象エンティティID指定方法」で「ランキング順」を指定します。



図7.9.5.2-2