CORBAアプリケーションでmodule定義のないIDLファイルをそのまま利用することはできません(実行は可能です)。
(CORBAの場合のみ)
jp.co.nec.WebOTX.Objectcreator.InitTermにて、valueファクトリを登録してください。
(例) ((org.omg.CORBA_2_3.ORB)orb).register_value_factory(NamesHelper.id(), new NamesValueFactory_impl());
「プロセスの起動時にかかった時間」が、運用管理ツールで設定されている"スレッド初期化時間"を超えた時は、プロセスの起動に失敗して終了します。 マルチスレッドの場合は各スレッドの初期処理を順番に行うため、この時の「プロセスの起動時にかかった時間」とは全スレッドでかかった時間の総計になります。
「プロセスの停止時にかかった時間」が、運用管理ツールで設定されている"スレッド初期化時間"を超えた時には、スレッドの終了処理を打ち切って終了します。 マルチスレッドの場合は各スレッドの終了処理を順番に行うため、この時の「プロセスの停止時にかかった時間」とは全スレッドでかかった時間の総計になります。
運用管理ツールで"実行時間上限"を設定し、かつ"プロセスを強制停止する"設定を行っている場合、各オペレーションの処理時間がこの時間(WebOTX内部の精度は最大10秒の遅れがあります)を超えるとプロセスを終了します。
処理時間を超えたスレッド以外のスレッドで処理中のオペレーションの完了は全て待ちあわせ、完了したらスレッドの終了処理を行います。 オペレーション完了待ち合わせ時間は調整可能で、既定値は600秒です。
UNIX版のWebOTXサーバアプリケーションの内部ではsignalが発生すると異常処理が発生したと見なして、アボート処理を行います。 よって、signalを利用したサーバアプリケーションの作成を制限しています。
特に重大な障害事に発生するSIGILL,SIGFPE,SIGBUS,SIGSEGVや内部制御用に使用しているSIGUSR1,SIGUSR2のシグナルマスクを変更した時の動作は保証できません。
Linux版にて、プロセスグループの「モジュールの種類」にJava EE または CORBA Javaを選択している場合、そのサーバアプリケーションがSIGTERMを受信すると、プロセスは停止処理を行わずに終了します。サーバアプリケーションがSIGTERMを受信するケースは、次のとおりです。
名前サーバへの負荷を軽減するため、名前サーバへのIOR登録方法は"永続的に扱う"が既定値です。 つまり、プロセス起動時に自動で登録されません。運用管理ツールから手動で登録を行う必要があります。 プロセス起動時に自動で登録する場合は運用管理ツールから名前サーバの登録で"一時的に扱う"設定にしてください。 システムの名前サーバの登録でも"一時的に扱う"設定にすることができます。
多数のリファレンスを一度に登録すると名前サーバに負荷がかかります。 名前サーバへの登録に失敗したりクライアント側でIOR取得に失敗したりする可能性がありますので注意してください。
IORを永続的に扱う設定をしている場合、IORの削除をしないうちにコンポーネント削除や置換によるインタフェース名の変更・削除があると、登録されたIORは無効となります。 運用管理ツールからは情報が消えるため削除できなくなりますのでコンポーネント削除やインタフェース名変更前に名前サーバからIORを削除してください。 IORを一時的に扱う設定にしている場合はプロセス停止時にWebOTXが削除します。
IOR削除前にインタフェース名を変更・削除してしまった場合は、実行環境のIOR削除コマンドwoiorunbindで手動削除してください。 この時指定するURLは、名前サーバホスト名の省略はできません。
コマンドは以下の位置にインストールされています。
URLを指定できずコマンドも使用できないという場合は、WebOTXAdministratorにインストールされるOrbManagerを起動し、手動で削除してください。 起動の方法に関しては名前サービスに登録したオブジェクトリファレンスの確認を参照してください。
ただし、このツールで表示されるURLはユーザが手動登録したIOR以外も含まれます。 WebOTXが自動登録したIORやWebOTX製品自身が動作するのに必要なIORを削除した場合、動作が不定になります。 IOR削除は極力運用管理ツールでインタフェース変更・削除前に行うかIOR削除コマンドで行ってください。どうしてもOrbManagerを使用しなければならない場合は誤って他のIORを削除することのないよう取り扱いには十分注意してください。
(CORBAの場合のみ)
WebOTX V5から、ステートおよびスレッドモデルは実装単位で指定可能になりました。
これによって、プロセス単位のステートおよびスレッドモデルというモードはなくなりました。
そのため、TPSGetServerInformation()は実装クラスの延長から呼ばれた場合はその実装クラスで指定されたステートとスレッドモデルを返しますが、実装クラス以外から呼ばれた場合はステートとスレッドモデルの値が不定になってしまいます。このため、互換維持のために以下の指定で互換動作するようにしました。
実装クラス以外から、TPSGetServerInformation()を使用してステートとスレッドモデルを取得する場合は、この指定をするようにしてください。
(CORBAの場合のみ)
以前はSetTxStatus()を呼び出してオペレーションが異常終了した場合には、コールバック関数OnTPSAbort()を呼び出していませんでした。
しかし、WebOTX V5からはこれを呼び出すように変更しました。
もしこの関数を呼び出されて問題が発生した場合には、環境変数に以下の値を設定してください。
OnTPSAbort()を呼び出さない以前の動作に変更されます。
環境変数が設定されていない場合、および値が異なる場合は従来の動作となります。
環境変数の設定はプロセスグループごとかWebOTX全体かのどちらかで設定できます。
プロセスグループごとに設定する場合は、運用管理ツールからプロセスグループのプロパティの環境変数に設定してください。
WebOTX全体で有効にするには、Windowsの場合はマシンのシステム環境変数に、UNIXの場合は/opt/WebOTX/config/asenv.confに設定してください。
WebOTX V5までは、Javaプロセス停止時にJavaの明示的な停止処理を行いませんでした。 Javaの停止処理は、生成された全てのスレッド(メインスレッド以外)が停止するのを待ち合わせてしまうため、サーバAPで独自スレッドを生成した場合にプロセスが停止しない問題が発生する可能性があったためです。 しかしJavaの停止処理を行わない場合、Javaプロファイルの採取などができなくなってしまう問題があったため、WebOTXV6からはこれを呼び出すように変更しました。 そのため、独自にスレッドを生成しているようなサーバAPが登録されている場合に、プロセスがなかなか停止しない可能性があります。 そのような場合は、プロセスグループの設定の「コマンドライン引数」に以下の値を設定することで回避できます。
ただし、このオプションを設定しますとJavaプロファイルの機能が利用できなくなりますのでご了承ください。
CORBAアプリケーションの場合、Javaのクラスロードの優先順は以下のようになります。
次のような向きのクラス参照はできませんので注意してください。
また、複数のjarファイルでクラスの重複がある場合、java.lang.ClassCastException等のエラーが発生する可能性があります。
その場合は、クラスの重複を取り除くような対処をしてください。
もしクラスの重複を取り除くのが困難である場合は、プロセスグループの設定の「コマンドライン引数」に以下の値を設定することで回避できる可能性があります。
ただし、このオプションを設定しますとコンポーネントの動的配備・配備解除機能が利用できなくなりますのでご了承ください。
Java EEアプリケーションの場合は
[
ドメイン構築・基本設定ガイド
> 5. アプリケーション
> 5.9. クラスローダ
]
を参照してください。
複数バージョンのJDKがインストールされている場合に、サーバAPのJavaプロセスが使用するJDKは以下のようにして決定されます。
よってWindows の場合は、そのままですと最後にインストールしたJDKを使用されてしまうため注意が必要です。 使用したいJDKを変更したい場合は以下の設定を行ってください。
(CORBAの場合のみ)
V4.xから、インターフェースWO_Baseにサーバプロセスメッセージ通知用のオペレーションが追加されています。
よって、R3.2以前で作成したAPでWO_Baseを継承しているものを再コンパイルする場合には
以下のようなソース修正が必要になります。
void OnTPSMessageNotified(java.lang.String mes)
void OnTPSMessageNotified(const char* mes, CORBA::Environment& _env = Ob_default_environment())
共有プロパティを使用する時、共有プロパティの削除API(WOPropertyGroup::DeleteProperty)
を呼び出しても、実際には共有メモリが削除されない問題がWebOTX V5まではありました。
V5では、オプションを用意して回避できるようにしていましたが、V6からはデフォルトで共有メモリを削除するようにしました。
もしこれによって問題が発生するような場合には、プロセスグループの設定の「環境変数」に以下の値を設定することで共有メモリを実際に削除しないV5以前と同様の動作にすることができます。
なお、旧互換のプロセスグループの場合は共有メモリを実際に削除しないV5以前と同様の動作がデフォルトになります。
プロセスグループの設定の「環境変数」に以下の値を設定することで、共有メモリを実際に削除する動作にすることができます。
V6.5から、java.lang.OutOfMemoryErrorエラーが発生した場合にJavaヒープの情報をAPトレースに出力する機能を提供しています。 この機能はJ2SE 5.0のJVMTIの機能を使用しているため、J2SE 5.0以上を使用しているときのみ有効になります。 また、JVMTIのException発生時イベントを使用しているために、アプリケーションの作りによって(正常系で例外が何度も発生するような場合など)は性能に影響がある場合があります。 その場合は、プロセスグループの設定の「JavaVMオプション」-「スタックトレース採取時にJavaヒープの情報を採取する」のチェックをはずすことで無効にすることができます。
WebOTX V6以降の運用管理ツール、コマンドではWebOTX V5の運用操作は行なえません。 また、V5の運用管理ツール、コマンドではWebOTX V6以降の運用操作は行なえません。
V7.11より、Java VMの本体部分が出力する標準エラー出力が、標準出力に向けられるようになりました。
プロセスグループの属性「標準出力の出力先」または「標準エラー出力の出力先」の設定を、既定値の「トレースに統合する」から「出力しない」に明示的に変更している場合にのみ影響があります。
既定値設定では、どちらもトレースに統合されるため、影響はありません。
Java VMの本体部分が出力するスタックトレースは、標準出力に出力されるため、こちらも影響はありません。
Java VM上で動作するアプリケーションの標準エラー出力に対しても影響はなく、従来どおりに動作します。
32ビットWindowsを使用している場合、WebOTXではJavaヒープサイズとメモリプールサイズの合計は最大で700MB程度となります。また、IIOPリスナの最大同時接続数の設定可能な値はOSの制限により最大で1700程度です。
| メモリプールサイズ + Javaヒープサイズ < 700MB程度 |
| メモリプールサイズ + IIOPリスナの最大同時接続数 * 1MB <2GB程度 |
WindowsでJavaアプリケーションのみを使用している場合に限り「メモリプールサイズ + Javaヒープサイズ」の上限を900MB程度まで拡張することができます。 WebOTXを停止した状態で次のファイルのバックアップを採取後、任意の行に次の値を追加(手修正)してください。
J2SE 5.0 以降では、ガベージコレクタのエルゴノミクスの影響で最大ヒープサイズのデフォルトが物理メモリの 1/4 か、1GB かの小さい方になります。 そのため、32ビットWindows で物理メモリ4GB(実際は3.4GB)の環境ではWebOTXのヒープサイズ制限(700MB程度)の影響によりデフォルトの最大ヒープサイズでは プロセスグループが起動しないので、必ず最大ヒープサイズを700MB程度より小さい値に設定する必要があります。
WebOTXは大量のクライアントからの同時リクエストに対応し、一台のクライアントの送受信に通信等が占有されることはシステム構築上避けるべきである、というコンセプトの元に作成されています。
よってWebOTXサーバにおける送信および受信電文長の最大を99,999,998バイトと定めています。
これを超える通信があった時は、CORBA::IMP_LIMIT()、マイナー=LENGTH_OVER(3933)です。
CORBA例外の詳細化を行わない場合はCORBA::UNKNOWN()、マイナー=1041となります。
リクエスト電文長(クライアントからサーバへの要求)は、200から300バイトのヘッダ領域の後にinおよびinoutの引数データが続きます。
このデータの大きさは型の定義と並びに依存します。
リプライ電文長(サーバからクライアントへの返却)は、40バイト前後のヘッダ領域の後にoutおよびinoutの引数データが続きます。
このデータの大きさも型の定義と並びに依存します。
サーバアプリケーションのトレースにて、トレースレベル6以上に設定すると、入力電文長および出力電文長を確認することが出来ます。
V8.3よりプロセスグループ上のホスト検索について、既定値でjp.co.nec.orb.UseHostName=trueを指定しません。 オブジェクトリファレンスにホスト名を使用する場合は、プロセスグループのJavaシステムプロパティに「jp.co.nec.orb.UseHostName=true」を指定します。
性能はIPアドレスを利用する方が有利ですが、IPアドレスの変更に備える場合やV8.2以前と同じ動作を期待する場合は「jp.co.nec.orb.UseHostName=true」を指定してください。
Windows OSで、TPシステム関連のコマンド(wostack, jnlsave, stop_tpm, contpsなど<WebOTXインストールディレクトリ>\Trnsv\binにあるコマンド)はマシンにログインしたユーザで実行されます。ログインユーザとWebOTX AS TPBASEadmのサービスを起動するアカウントが異なる場合、コマンドの実行はエラーとなります。これらのコマンドを使用する場合、WebOTX AS TPBASEadmのサービスを起動するアカウントでマシンにログインしてください。
なお、WebOTX AS TPBASEadmのサービスを起動するアカウントをローカルシステムアカウントとしている場合、コマンドの実行はエラーとなり、使用できません。コマンドを使用したい場合、WebOTX AS TPBASEadmのサービスを起動するアカウントの変更が必要になります。
V8.42からリカバリプロセスの起動有無を設定できるようになりました。
配備したアプリケーションと[名前サーバへの登録]を確認して適切な設定を行ってください。
起動中のプロセスグループに対してコンポーネントの配備・配備解除を行う動的配備・配備解除機能には、以下のような制限があります。
例外ハンドルありの設定で、マルチスレッドで動作するC++アプリケーションのオペレーション呼び出しが例外すると、以降該当モジュールの「モジュールアイドル時間」が更新されなくなります。
該当プロセスグループを再起動すると、モジュールアイドル時間が更新されるようになります。
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情報採取機能を利用しない場合は、本環境変数を設定してください。
IPv6使用時、以下の情報のIPアドレスを表示できません。
いずれの場合も、IPアドレス情報には"255.255.255.255"が表示されます。