TPモニタ

13. TPモニタ

13.1. J2SE1.4の利用について

(CORBAの場合のみ)
WebOTXにてJ2SE 1.4以降を利用する時は以下の点に注意する必要があります。

module定義のないIDLファイルをそのまま利用することはできません(実行は可能です)。どうしてもmodule指定なしのIDLファイルをする場合は1.3.1でコンパイルするか、IDLコンパイラが生成したソースを修正してpackageを付与してください。そのIDLファイルを参照して別のIDLファイルを作成する場合は -rp<パッケージ名> つけてIDLコンパイルしてください。

13.2. 既定値以外のValueファクトリを使用する場合

(CORBAの場合のみ)
jp.co.nec.WebOTX.Objectcreator.InitTermにて、valueファクトリを登録してください。

(例)
((org.omg.CORBA_2_3.ORB)orb).register_value_factory(NamesHelper.id(), new NamesValueFactory_impl());

13.3. スレッド初期化時間に関する注意事項

「プロセスの起動時にかかった時間」が、運用管理ツールで設定されている「スレッド初期化時間」を超えた時は、プロセスの起動に失敗して終了します。
マルチスレッドの場合は各スレッドの初期処理を順番に行うため、この時の「プロセスに起動時にかかった時間」とは全スレッドでかかった時間の総計になります。

「プロセスの停止時にかかった時間」が、運用管理ツールで設定されている「スレッド初期化時間」を超えた時には、スレッドの終了処理を打ち切って終了します。
マルチスレッドの場合は各スレッドの終了処理を順番に行うため、この時の「プロセスに停止時にかかった時間」とは全スレッドでかかった時間の総計になります。

13.4. オペレーション経過時間オーバに関する注意事項

運用管理ツールで「実行時間上限」を設定した時、各オペレーションの処理時間がこの時間(WebOTX内部の精度は最大10秒の遅れがあります) を超えた時はプロセスを終了します。

処理時間を超えたスレッド以外のスレッドで処理中のオペレーションの完了は全て待ちあわせ、完了したらスレッドの終了処理を行います。

13.5. signalに関する注意事項

UNIX版のWebOTXサーバアプリケーションの内部ではsignalが発生すると異常処理が発生したと見なして、アボート処理を行います。よって、現在はsignalを利用したサーバアプリケーションの作成を制限しています。

特に重大な障害事に発生する SIGILL, SIGFPE, SIGBUS, SIGSEGVや内部制御用に使用している SIGUSR1, SIGUSR2のシグナルマスクを変更した時の動作は保証できません。

13.6. 電文長に関する制限事項

WebOTXは大量のクライアントからの同時リクエストに対応し、一台のクライアントの送受信に通信等が占有されることはシステム構築上避けるべきである、というコンセプトの元に作成されています。

よってWebOTXサーバにおける送信および受信電文長の最大を9,999,998バイトと定めています。これを超える通信があった時は、CORBA::IMP_LIMIT()、マイナー=LENGTH_OVER(3933)です。 Ver3.2互換動作を選択した場合CORBA::BAD_OPERATION()、マイナー=LENGTH_OVER(3933)となります。 CORBA例外の詳細化を行わない場合はCORBA::UNKNOWN()、マイナー=1041となります。

リクエスト電文長(クライアントからサーバへの要求)は、200から300バイトのヘッダ領域の後に、 inおよびinoutの引数データが続きます。このデータの大きさは型の定義と並びに依存します。リプライ電文長(サーバからクライアントへの返却)は、40バイト前後のヘッダ領域の後に outおよびinoutの引数データが続きます。このデータの大きさも型の定義と並びに依存します。

サーバアプリケーションのトレースにて、トレースレベル6以上に設定すると、入力電文長および出力電文長を確認することが出来ます。

13.7. IOR登録の注意事項

Ver5.1から名前サーバへのIOR登録は永続的に扱う事が既定値になりました。
つまり、プロセス起動時に自動で登録されません。運用管理ツールから手動で登録を行う必要があります。
プロセス起動時に自動で登録する場合は運用管理ツールから名前サーバの登録ページで一時的に扱う設定にしてください。システムの名前サーバの登録ページでも一時的に扱う設定にすることができます。

多数を一度に登録すると名前サーバに負荷がかかります。名前サーバへの登録に失敗したりクライアント側でIOR取得に失敗したりする可能性がありますので注意してください。

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

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

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

コマンドは以下の位置にインストールされています。: Windows:<WebOTX install directory>\Trnsv\bin\woiorunbind
UNIX:<WebOTX install directory>/Trnsv/bin/woiorunbind

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

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

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

13.8. ステートおよびスレッドモデルについて

(CORBAの場合のみ)
V5.1から、ステートおよびスレッドモデルは実装単位で指定可能になりました。これによって、プロセス単位のステートおよびスレッドモデルというモードはなくなりました。そのため、TPSGetServerInformation()は実装クラスの延長から呼ばれた場合はその実装クラスで指定されたステートとスレッドモデルを返しますが、実装クラス以外から呼ばれた場合はステートとスレッドモデルの値が不定になってしまいます。このため、互換維持のために以下の指定で互換動作するようにしました。実装クラス以外から、TPSGetServerInformation()を使用してステートとスレッドモデルを取得する場合は、この指定をするようにしてください。

運用管理ツールからプロセスグループのプロパティを開き、以下の環境変数を設定する。
- ステートの設定
  
  名前：
  WOCP_PROC_STATE
  値：
  STATELESS ステートレス（既定値）
  STATEFUL ステートフル
  それ以外ステートレス
  環境変数自身が設定されていないときは「ステートレス」
- スレッドモデルの設定
  
  名前：
  WOCP_THREAD_MODEL
  値：
  SINGLE シングル
  APARTMENT アパートメント（既定値）
  FREE フリー
  それ以外アパートメント
  環境変数自身が設定されていないときは「アパートメント」
内部的には、各インターフェースの設定で指定したモードで動作します。よってこの指定と1の指定がミスマッチの時の動作は保障されません。

13.9. SetTxStatus について

(CORBAの場合のみ)
以前はSetTxStatus()を呼び出してオペレーションが異常終了した場合には、コールバック関数 OnTPSAbort() を呼び出していませんでした。しかし、V5.xからはこれを呼び出すように変更しました。
もしこの関数を呼び出されて問題が発生した場合には、環境変数に以下の値を設定してください。
OnTPSAbort()を呼び出さない以前の動作に変更されます。

    名前 ： WO_SETTXSTATUS_CMPT
    値   ： ON

環境変数が設定されていない場合、および値が異なる場合は従来の動作となります。環境変数の設定はプロセスグループごとかWebOTX全体かのどちらかで設定できます。プロセスグループごとに設定する場合は、運用管理ツールからプロセスグループのプロパティの環境変数に設定してください。
WebOTX全体で有効にするには、Windowsの場合はマシンのシステム環境変数に、 UNIXの場合は/opt/WebOTX/config/asenv.conf に設定してください。

13.10. 独自にスレッドを生成する場合の注意事項(Javaのみ)

V5.xまでは、Javaプロセス停止時にJavaの明示的な停止処理を行いませんでした。
Javaの停止処理は、生成された全てのスレッド(メインスレッド以外)が停止するのを待ち合わせてしまうため、サーバAPで独自スレッドを生成した場合にプロセスが停止しない問題が発生する可能性があったためです。
しかしJavaの停止処理を行わない場合、Javaプロファイルの採取などができなくなってしまう問題があったため、R6.xからはこれを呼び出すように変更しました。
そのため、独自にスレッドを生成しているようなサーバAPが登録されている場合に、プロセスがなかなか停止しない可能性があります。
そのような場合は、プロセスグループの設定の「コマンドライン引数」に以下の値を設定することで回避できます。

    -notusedestroyjavavm

ただし、このオプションを設定しますとJavaプロファイルの機能が利用できなくなりますのでご了承ください。

13.11. Javaのクラスロードについて

CORBAアプリケーションの場合、Javaのクラスロードの優先順は以下のようになります。

J2SEの標準クラス
<WebOTX>\domains\<ドメイン名>\lib\ext 配下のjarファイル内のクラス
WebOTX のシステムクラス
環境変数 CLASSPATH に設定されているjarファイル内のクラス
共有コンポーネントのjarファイル内のクラス
R4形式サーバコンポーネントのjarファイル内のクラス
R5形式サーバコンポーネントのjarファイル内のクラス

次のような向きのクラス参照はできませんので注意してください。

<WebOTX>\domains\<ドメイン名>\lib\ext 配下のjarファイル内のクラス → ロード優先度がそれ以下のクラス
環境変数 CLASSPATH に設定されているjarファイル内のクラス → ロード優先度がそれ以下のクラス
共有コンポーネントのjarファイル内のクラス → R5形式サーバコンポーネントのjarファイル内のクラス
R4形式サーバコンポーネントのjarファイル内のクラス → R5形式サーバコンポーネントのjarファイル内のクラス
R5形式サーバコンポーネントのjarファイル内のクラス → R5形式サーバコンポーネントの別なjarファイル内のクラス

また、複数のjarファイルでクラスの重複がある場合、java.lang.ClassCastException 等のエラーが発生する可能性があります。その場合は、クラスの重複を取り除くような対処をしてください。
もしクラスの重複を取り除くのが困難である場合は、プロセスグループの設定の「コマンドライン引数」に以下の値を設定することで回避できる可能性があります。

    -notusewojarloader

ただし、このオプションを設定しますとコンポーネントの動的配備・配備解除機能が利用できなくなりますのでご了承ください。

J2EEアプリケーションの場合は「運用編」の「アプリケーションの配備」、「10 J2EE アプリケーションの実行時環境」を参照してください。

13.12. 複数のJDKがインストールされている場合の注意事項

複数バージョンのJDKがインストールされている場合に、サーバAPのJavaプロセスが使用する JDK は以下のようにして決定されます。

Windows :

Java のレジストリに従います。
レジストリキー HKEY_LOCAL_MACHINE\JavaSoft\Java Development Kit 配下の "CurrentVersion" というレジストリから使用するJDKのバージョンが決定されます。
使用するJDKのパスは、レジストリキー HKEY_LOCAL_MACHINE\JavaSoft\Java Development Kit\<Javaバージョン> 配下の"JavaHome" というレジストリから取得されます。
UNIX :

/opt/WebOTX/config/asenv.conf に記述されている、環境変数JAVA_HOME に従います。

よってWindows の場合は、そのままですと最後にインストールしたJDKを使用されてしまうため注意が必要です。

使用したいJDKを変更したい場合は以下の設定を行ってください。

Windows :

レジストリエディタから、レジストリキー HKEY_LOCAL_MACHINE\JavaSoft\Java Development Kit 配下の "CurrentVersion" というレジストリの値を、使用したいJDKのバージョンに変更してください。設定する値は、 "1.4"のように <メジャーバージョン>.<マイナーバージョン>の形式です。
UNIX :

/opt/WebOTX/config/asenv.conf に記述されている、AS_JAVA の値を使用したいJDKのパスに変更してください。 (/opt/WebOTX/Trnsv/bin/tpadm2.sh にて、AS_JAVAの値を環境変数JAVA_HOMEに設定しています。)

13.13. WebOTX R3.2以前で作成したAPを再コンパイルする場合の注意事項

(CORBAの場合のみ)
V4.xから、インターフェース WO_Base にサーバプロセスメッセージ通知用のオペレーションが追加されています。よって、R3.2以前で作成したAPでWO_Baseを継承しているものを再コンパイルする場合には以下のようなソース修正が必要になります。

実装クラスの定義に、サーバプロセスメッセージ通知用のメソッドを追加してください。
メソッドはpublic である必要があります。中身は空でもかまいません。
- Java :
```
void OnTPSMessageNotified(java.lang.String mes)
```
- C++ :
```
void OnTPSMessageNotified(const char* mes, 

        CORBA::Environment& _env = Ob_default_environment())
```

13.14. 動的配備・配備解除の制限事項

起動中のプロセスグループに対してコンポーネントの配備・配備解除を行う動的配備・配備解除機能には、以下のような制限があります。

CORBAアプリケーションの場合は、R5形式のコンポーネントでのみ行えます。
旧互換のプロセスグループに対しては行えません。
共有コンポーネントの動的配備解除を行う場合は、参照している全てのサーバコンポーネントを全て閉塞させる必要があります。
同一プロセスグループに、同じネイティブライブラリを使用してJNI呼び出しを行うサーバコンポーネントが複数ある場合、java.lang.UnsatisfiedLinkError が発生します。
その場合は、JNI呼び出しの処理を共有コンポーネントに移動してください。
同じネイティブライブラリを使用してJNI呼び出しを行う共有コンポーネントが複数使用されている場合、java.lang.UnsatisfiedLinkError が発生します。
その場合は、特定のネイティブライブラリを使用したJNI呼び出しの処理を 1つの共有コンポーネントにまとめてください。
JNI呼び出しを行うサーバコンポーネントを動的配備解除する場合、ネイティブライブラリがなかなかアンロードされない場合があります。
その状態で同じサーバコンポーネントを動的配備すると、java.lang.UnsatisfiedLinkError が発生します。
そのため、JNI呼び出しを行うサーバコンポーネントを配備する前には、プロセスグループを停止することを推奨します。

13.15. 共有プロパティの解放処理について(C++のみ)

共有プロパティを使用する時、共有プロパティの削除API(WOPropertyGroup::DeleteProperty) を呼び出しても、実際には共有メモリが削除されない問題がV5.xまではありました。
V5.xでは、オプションを用意して回避できるようにしていましたが、V6.xからはデフォルトで共有メモリを削除するようにしました。
もしこれによって問題が発生するような場合には、プロセスグループの設定の「環境変数」に以下の値を設定することで共有メモリを実際に削除しないV5.x以前と同様の動作にすることができます。

    名前 ： WO_NOT_DELETE_PROPERTY
    値   ： ON

なお、旧互換のプロセスグループの場合は共有メモリを実際に削除しないV5.x以前と同様の動作がデフォルトになります。
プロセスグループの設定の「環境変数」に以下の値を設定することで、共有メモリを実際に削除する動作にすることができます。

    名前 ： WO_DELETE_PROPERTY
    値   ： ON

13.16. モジュールアイドル時間について(C++のみ)

例外ハンドルありの設定で、マルチスレッドで動作するC++アプリケーションのオペレーション呼び出しが例外すると、以降該当モジュールの「モジュールアイドル時間」が更新されなくなります。
該当プロセスグループを再起動すると、モジュールアイドル時間が更新されるようになります。

13.17. OutOfMemoryError発生時のJavaヒープ情報採取機能について(Javaのみ)

V6.5から、OutOfMemoryErrorが発生した場合にJavaヒープの情報をAPトレースに出力する機能を提供しています。
この機能はJ2SE5.0 のJVMTIの機能を使用しているため、J2SE5.0を使用しているときのみ有効になります。
また、JVMTIのException発生時イベントを使用しているために、APの作りによって(正常系で例外が何度も発生するような場合など)は性能に影響がある場合があります。
その場合は、プロセスグループの設定の「JavaVMオプション」-「OutOfMemoryError発生時にJavaヒープの情報を採取する」のチェックをはずすことで無効にすることができます。

13.18. 旧バージョンの運用管理ツール・コマンドについて

V6の運用管理ツール、コマンドではWebOTX V5の運用操作は行なえません。また、V5の運用管理ツール、コマンドではWebOTX V6の運用操作は行なえません。

13.19. CPU情報取得機能と性能について

V6.3以降のWebOTXでは、オペレーションのCPU情報取得機能が新規に追加されたことにより、 Solaris版とHP-UX版でV6.2と比べてオペレーションの実行性能が遅くなっています。V6.2と比較して、 HP-UX版で約4%、Solaris版で約16%遅くなっています。Windows版とLinux版ではV6.2との性能差はありません。V6.31以降では、このオペレーションのCPU情報取得機能を抑制し、オペレーション呼び出しの実行性能をV6.2と同等にすることができます。
CPU情報取得を抑制するには、プロセスグループの設定の「環境変数」に以下の値を設定し、アプリケーショングループを再起動します。この環境変数を指定すると、オペレーションジャーナルに記録されるオペレーションのCPU使用時間が全て0になります。オペレーションのCPU情報採取機能を利用しない場合は、本環境変数を設定してください。

    名前 ： WO_NO_SAMPLING_CPUINFO
    値   ： ON

13.20. IPv6使用時のIPアドレス表示

IPv6使用時、以下の情報のIPアドレスを表示できません。
いずれの場合も、IPアドレス情報には"255.255.255.255"が表示されます。

「クライアントセッション」の属性「接続クライアント情報」
プロセスグループの属性「スレッド情報」の接続クライアント
C++アプリケーションでTPSGetTerminalIPによるIPアドレスの取得

13.21. Java VMの標準エラー出力先について

V7.11より、Java VMの本体部分が出力する標準エラー出力が、標準出力に向けられるようになりました。
プロセスグループの属性「標準出力出力先」または「標準エラー出力出力先」の設定を、既定値の「トレースに統合する」から「出力しない」に明示的に変更している場合にのみ影響があります。
既定値設定では、どちらもトレースに統合されるため、影響はありません。
Java VMの本体部分が出力するスタックトレースは、標準出力に出力されるため、こちらも影響はありません。
Java VM上で動作するアプリケーションの標準エラー出力に対しても影響はなく、従来どおりに動作します。

13.22. Javaヒープサイズ、メモリプールサイズ、最大同時接続数の上限

32ビットWindowsを使用している場合、WebOTXではJavaヒープサイズとメモリプールサイズの合計は最大で700MB程度となります。また、IIOPリスナの最大同時接続数の設定可能な値はOSの制限により最大で1700程度です。

Javaヒープサイズの上限

メモリプールサイズ + Javaヒープサイズ < 700MB程度

Javaヒープサイズは連続した領域を確保する必要があります。ユーザアプリケーションが使用できる仮想メモリ空間はOSの制限により2GBとなっていますが、連続して確保できる領域はProcess Explorer等のツールを使用して確認すると1.4～1.6GB程度となっています。 (連続した領域でなければ2GB程度使用可能です。)
WebOTXではユーザアプリケーションのプロセスの仮想メモリの一部領域をWebOTX制御用としてアドレス固定で確保しているため、Javaヒープサイズが確保できる連続した領域は700MB程度となります。
IIOPリスナの最大同時接続数の制限
次の式で示されるIIOPリスナプロセスの仮想メモリ空間の制限があります。ただし、メモリプールサイズとIIOPリスナの最大同時接続数だけで 2GB分の仮想メモリを全て使用できるわけではありません。 IIOPリスナの最大同時接続数の上限は最大1700程度となっています。

メモリプールサイズ + IIOPリスナの最大同時接続数 * 1MB < 2GB程度

OSで各スレッドに1MB のスタック空間が割り当てられているため、IIOPリスナの接続端末1つに1MBが必要になります。各スレッドで必要な連続領域は1MBであり、Javaヒープサイズのように数百MBの領域を連続して確保する必要はないため、OSの制限である2GBに達するまではIIOPリスナの最大同時接続数を増やす事が可能です。

・メモリプールサイズ + Javaヒープサイズを 700MB以上としたい場合の拡張方法

WindowsでJavaアプリケーションのみを使用している場合に限り「メモリプールサイズ + Javaヒープサイズ」の上限を900MB程度まで拡張する事が出来ます。 WebOTXを停止した状態で次のファイルのバックアップを採取後、任意の行に次の値を追加(手修正)してください。

修正ファイル：: ${INSTANCE_ROOT}\config\tpsystem\tpbase.cnf
値：: (以下の3行をそのまま追加(セパレータは空白文字)); QUESHMATADDR 20000000; MSGSHMATADDR 21000000; MEMSHMATADDR 23000000

・32ビットWindowsでJ2SE 5.0 以降を利用する場合

J2SE 5.0 以降では、ガベージコレクタのエルゴノミクスの影響で最大ヒープサイズのデフォルトが物理メモリの 1/4 か、1GB かの小さい方になります。そのため、32ビットWindows で物理メモリ4GB(実際は3.4GB)の環境ではWebOTXのヒープサイズ制限(700MB程度)の影響によりデフォルトの最大ヒープサイズではプロセスグループが起動しないので、必ず最大ヒープサイズを700MB程度より小さい値に設定する必要があります。