WebOTX Manual V11.1 (第6版) 目次を表示 |
UNIX版のサーバアプリケーションの内部では、signalが発生すると異常処理が発生したと見なして、TPモニタはアボート処理を行います。 よって、signalを利用したサーバアプリケーションの作成を制限しています。
特に重大な障害時に発生するSIGILL,SIGFPE,SIGBUS,SIGSEGVや内部制御用に使用しているSIGUSR1,SIGUSR2のシグナルマスクを変更した時の動作は保証できません。
Linux版にて、プロセスグループの「モジュールの種類」にJava EE または CORBA Javaを選択している場合、そのサーバアプリケーションがSIGTERMを受信すると、プロセスは停止処理を行わずに即時終了します。サーバアプリケーションがSIGTERMを受信するケースは、次のとおりです。
本注意点はCORBAアプリケーションの場合のみの場合に該当します。
名前サーバへのオブジェクトリファレンスの登録方法が"一時的に扱う"の場合、プロセス起動時に多数のリファレンスを一度に登録すると名前サーバに負荷がかかります。
名前サーバへの登録に失敗したりクライアント側でオブジェクトリファレンスの取得に失敗したりする可能性がありますので注意してください。
CORBAアプリケーションの場合、Javaのクラスロードの優先順は以下のようになります
(注)${AS_INSTALL}/domains/<ドメイン名>/lib/extについては、Java9以降を利用の場合は${AS_INSTALL}/domains/<ドメイン名>/libに読み替えてください。
次のような向きのクラス参照はできませんので注意してください。
また、複数のjarファイルでクラスの重複がある場合、java.lang.ClassCastException等のエラーが発生する可能性があります。
その場合は、クラスの重複を取り除くような対処をしてください。
もしクラスの重複を取り除くのが困難である場合は、プロセスグループの設定の「コマンドライン引数」に以下の値を設定することで回避できる可能性があります。
ただし、このオプションを設定しますとコンポーネントの動的配備・配備解除機能が利用できなくなりますのでご了承ください。
Java EEアプリケーションの場合は
[配備
> クラスローダ
]
を参照してください。
WebOTXは大量のクライアントからの同時リクエストに対応し、一台のクライアントの送受信に通信等が占有されることはシステム構築上避けるべきである、というコンセプトの元に作成されています。
よってWebOTXサーバにおける送受信電文長の上限を99,999,998バイトと定めています。
これを超える通信があった時は、CORBA::IMP_LIMIT()、マイナー=LENGTH_OVER(3933)エラーが出力されます。
リクエスト電文長(クライアントからサーバへの要求)は、200から300バイトのヘッダ領域の後にinおよびinoutの引数データが続きます。
このデータの大きさは型の定義と並びに依存します。
リプライ電文長(サーバからクライアントへの返却)は、40バイト前後のヘッダ領域の後にoutおよびinoutの引数データが続きます。
このデータの大きさも型の定義と並びに依存します。
プロセスグループの「トレース設定」で「トレースレベル」を6以上に設定すると、送受信電文長を確認できます。
V8.3よりプロセスグループのJavaシステムプロパティに「jp.co.nec.orb.UseHostName=true」を指定しません。 これにより、オブジェクトリファレンスでホスト名はIPアドレス形式に変換して設定されます。 オブジェクトリファレンスにホスト名を使用する場合は、プロセスグループのJavaシステムプロパティに「jp.co.nec.orb.UseHostName=true」を指定します。
IPアドレスを利用する方が性能は優れていますが、IPアドレスの変更に備える場合やV8.2以前と同じ動作を期待する場合は「jp.co.nec.orb.UseHostName=true」を指定してください。
Windowsで、TPシステム関連のコマンド(wostack, jnlsave, stop_tpm, contpsなど<WebOTXインストールディレクトリ>\Trnsv\binにあるコマンド)はマシンにログインしたユーザで実行されます。ログインユーザとWebOTX AS <バージョン番号> Agent Serviceのサービスを起動するアカウントが異なる場合、コマンドの実行はエラーとなります。これらのコマンドを使用する場合、WebOTX AS <バージョン番号> Agent Serviceのサービスを起動するアカウントでマシンにログインしてください。
なお、WebOTX AS <バージョン番号> Agent Serviceのサービスを起動するアカウントをローカルシステムアカウントとしている場合、コマンドの実行はエラーとなり、使用できません。コマンドを使用したい場合、WebOTX AS <バージョン番号> Agent Serviceのサービスを起動するアカウントの変更が必要になります。
V9.2から、tpadm2.shの廃止に伴い、TPモニタで固定値を設定していたcoreの最大サイズ指定を廃止しました。coreの最大サイズは起動するシェルの設定に従いますので、ulimitコマンドの利用や/etc/security/limits.confファイルの編集などにより、coreの最大サイズを指定してください。
環境によってはcoreの最大サイズの既定値が0であるため、coreが出力されず、障害発生時の調査が困難になる可能性があります。
なお、coreはプロセスが使用するメモリ使用量に応じたサイズとなりますので、coreの最大サイズが小さい場合、不完全なファイルとなります。
逆に、coreの最大サイズを大きくすると、大量にメモリを使用するプロセスで障害が発生した場合、coreの出力によってプロセスの停止に時間がかかります。
システムで許容される負荷やディスクの空き容量などから、coreの最大サイズを決定してください。
起動中のプロセスグループに対してコンポーネントの配備・配備解除を行う動的配備・配備解除機能には、以下のような注意があります。
プロセスグループの起動・停止順序は、Jakarta EEプロセスグループのみ実装しています。Jakarta EEプロセスグループの起動・停止順序をご利用の際は、Jakarta EEプロセスグループのみ同一アプリケーショングループに作成するようにしてください。
Java11以降において、プロセスグループにJavaシステムプロパティで「-Xloggc」もしくは「-Xlog」で指定することによるGCのログファイル名の指定が効かなくなっています。Java側にはファイルパスを渡せているため、指定したGCログファイルは作成されますが、GCログの内容は次のプロセスグループのログに出力されます。
${INSTANCE_ROOT}/logs/tpsystem/${APGNAME}/${PGNAME}.${PID}.log
プロセスグループのプロセス数を2以上に設定してマルチプロセス構成とした場合には、Java8以前の場合においても、GCログのファイル名指定が複雑になる問題がありました。Java11以降の場合には、プロセスグループのログにGCログを出力してください。
動作しているOSがWindowsの場合、次のプロセスグループのログファイルに、ご利用のOSがWindows Server 2016以降の場合は「OS = Windows Server 2016」、Windows 10以降の場合は「OS = Windows 10」と出力されます。これは、Windows Server 2016以降、もしくはWindows 10以降の場合、WindowsのAPIで取得しているOSのバージョンが、いずれも10.0で判別がつかないためです。
${INSTANCE_ROOT}/logs/tpsystem/${APGNAME}/${PGNAME}_sys.${PID}.log
TPシステムの「例外ハンドル」の設定で、「例外ハンドルを行う」がtrue(既定値)である場合、マルチスレッドで動作するC++アプリケーションのオペレーション呼び出しで例外が発生すると、以降該当モジュールの「モジュールアイドル時間」が更新されなくなります。
該当プロセスグループを再起動すると、モジュールアイドル時間が更新されるようになります。
IPv6使用時、以下の情報のIPアドレスを表示できません。
いずれの場合も、IPアドレス情報には"255.255.255.255"が表示されます。
WindowsのVC++2005、VC++2008では、クライアント管理ライブラリを利用できません。また、VC++2010、VC++2012、VC++2013、VC++2015、VC++2017、VC++2019のデバッグ版でも、クライアント管理ライブラリを利用できません。
TPモニタ上では、JSESSION Cookieの名称を「JSESSIONID」以外に変更したWebアプリケーションを動作させることはできません。
また、URL Rewritingにおけるパラメータ名についても「JSESSIONID」以外に変更したWebアプリケーションを動作させることはできません。
AJPリスナのカレントディレクトリは、次の通りです。
<WebOTXインストールディレクトリ>/domains/domain名/logs/tpsystem
そこから遡って ../../config/ajp_errdef.properties を参照しようとします。そのため、logsディレクトリのシンボリックリンクを作成してカレントディレクトリが変わると、propertiesファイルを参照できずにAJPリスナが異常終了します。そうした場合、参照可能な場所に config/ajp_errdef.properties を作成してください。