Hitachi

OpenTP1 Version 7 分散トランザクション処理機能 TP1/Client for .NET Framework 使用の手引


rpc

〈このページの構成〉

形式

<rpc use="通信形態"
     watchTime="最大応答待ち時間"
     watchTimeNotification="true|false"
     maxMessageSize="RPCメッセージの最大長"
     compressData="true|false"
     prfInfoSend="true|false"
     cupRecvPort="CUP.NETの受信で使用するポート番号"
     useMultiScheduler="true|false"
     extendOpt="RPCサービスの機能拡張オプション"/>

説明

RPCに関する指定をします。

この要素は省略できません。必ず<common>要素内または<profile>要素内にこの要素を一つ以上指定してください。

属性

use="通信形態"

通信形態を指定します。

この属性は省略できません。次のどれかを指定してください。

rap:rapサービスを使用

nam:ネームサービスを使用

scd:スケジューラサービスを使用

watchTime="最大応答待ち時間"  〜〈符号なし整数〉((0〜65535))《180》(単位:秒)

応答型RPCの場合に,CUP.NETからSPP.NETまたはSPPへサービス要求を送ってからサービスの応答が返るまでの待ち時間の最大値を指定します。

指定時間を過ぎても応答が返らない場合は,CUP.NETにエラーリターンします。0を指定した場合は,応答を受信するまで待ち続けます。

この属性は省略できます。

watchTimeNotification="true|false"  〜《false》

CUP.NETの最大応答待ち時間をサーバ側に引き継ぐかどうかを指定します。

CUP.NETの最大応答待ち時間を引き継ぐと,CUP.NETがタイムアウトしているのにサーバ側でサービスが実行されることを防止できます。

この属性は省略できます。

true:サーバ側にCUP.NETの最大応答待ち時間を引き継ぎます。

false:サーバ側にCUP.NETの最大応答待ち時間を引き継ぎません。

maxMessageSize="RPCメッセージの最大長"  〜〈符号なし整数〉((1〜8))《1》(単位:メガバイト)

TP1ClientクラスのCallメソッドで送受信できるユーザメッセージの最大長を指定します。

Callメソッドの引数に,この属性で指定した値より大きな値を送信メッセージ長および受信メッセージ長として指定できません。

送信メッセージ長にこの属性の指定値よりも大きい値を指定した場合,Callメソッドは,ErrMessageTooBigExceptionを返します。

送信メッセージ長にこの属性の指定値よりも小さい値を指定して,受信メッセージ長にこの属性の指定値よりも大きい値を指定した場合,CallメソッドはErrInvalidArgsExceptionを返します。

この属性に1(デフォルト値)または8(最大に拡張した値)を指定した場合,RPCメッセージの最大長は次のようになります。

  • 1(デフォルト値)の場合:1メガバイト=1048576バイト

  • 8(最大に拡張した値)の場合:8メガバイト=8388608バイト

この属性に2以上を指定した場合,ネームサービスを使用したRPCでネームサーバへの問い合わせをしたとき,RPCメッセージの最大長が拡張されたサービス情報を,要求先として使用します。

この属性は以下のメソッドにも有効です。詳細は「6. クラスリファレンス」の各メソッドの説明を参照してください。

  • AcceptNotificationメソッド

  • AcceptNotificationChainedメソッド

  • CancelNotificationメソッド

  • CallToメソッド

システム共通定義のrpc_max_message_sizeオペランドをサポートしていないTP1/Server(バージョン06-02より前)に対して,maxMessageSize属性を指定して,次の機能を使用しないでください。使用した場合,通信先のTP1/Serverノードでエラーが発生します。

  • スケジューラダイレクト機能を使用したRPC

  • 通信先を指定したRPC

この属性は省略できます。

compressData="true|false"  〜《false》

データ圧縮機能を使用するかどうかを指定します。

compressDataにtrueを指定した場合でも,サービス要求を受信するSPPのメッセージ格納バッファプール長(message_store_buflenオペランド)は,圧縮前のユーザデータ長でサイズを計算してください。

true:データ圧縮機能を使用します。

false:データ圧縮機能を使用しません。

この属性は省略できます。

prfInfoSend="true|false"  〜《true》

TP1/Serverに対して,ネームサービスを使用したRPC,およびスケジューラダイレクト機能を使用したRPCを行う場合に,OpenTP1の性能検証用トレースに出力する情報としてClient .NET内部で識別情報を付加するかどうかを指定します。

スケジューラダイレクト機能を使用したRPCでサービス要求先のTP1/Serverのバージョンが03-03未満である場合は,SPPのサービス関数に不正なデータを渡す可能性があるので必ずfalseを指定してください。

なお,ネームサービス機能を使用したRPCでサービス要求先のTP1/Serverのバージョンが03-03未満である場合,trueを指定しても,この指定は無視されるためTP1/Server上へ性能検証用の識別情報は伝播できません。

true:Client .NET内部で識別情報(IPアドレスなど)を付加します。

false:Client .NET内部で識別情報(IPアドレスなど)を付加しません。

この属性は省略できます。

cupRecvPort="CUP.NETの受信で使用するポート番号"  〜〈符号なし整数〉((5001〜65535))

サーバからのメッセージを受信するCUP.NETのポート番号を指定します。

この属性で指定したポート番号は,次の機能を使用する場合に有効です。

  • スケジューラダイレクト機能を使用したRPCの受信時(受信ポート)

  • ネームサービスを使用したRPCの受信時(受信ポート)

この属性を省略すると,システムが任意に割り当てたポート番号を使用します。

同一マシン内で,複数のプロセス,または複数のスレッドを同時に実行する場合は,それぞれ異なるポート番号を指定してください。

指定できるポート番号でも,OSまたはほかのプログラムで使用するポート番号は指定しないでください。指定した場合,応答データを正しく受信できないことがあります。なお,OSが使用するポート番号は,OSごとに異なります。OSが使用するポート番号については,ご利用のOSの関連ドキュメントを参照してください。

useMultiScheduler="true|false"  〜《false》

マルチスケジューラ機能を使用するかどうかを指定します。

true:マルチスケジューラ機能を使用します。

false:マルチスケジューラ機能を使用しません。

マルチスケジューラ機能を使用すると,複数起動されたマルチスケジューラデーモンの中から,一つをランダムに選択することで,スケジューリングの負荷を軽減できます。この属性にtrueを指定した場合,サービス要求を送信するスケジューラデーモンはClient .NET構成定義の指定によって異なります。次のClient .NET構成定義も併せて参照してください。

  • <rpc>要素のuse属性

  • <tp1Server>要素のport属性

  • <scheduleService>要素のport属性

  • <scheduleService>要素のmultiSchedulerCount属性

この属性は,CallToメソッド実行時は無効です。

この属性は省略できます。

extendOpt="RPCサービスの機能拡張オプション"  〜〈16進整数〉((00000000〜00000001))《00000000》

RPCサービスの機能拡張オプションを指定します。

00000000:RPCサービスの機能を拡張しません。

00000001:応答電文受信障害時のキャッシュリフレッシュ機能を使用します。

ネームサービスを使用したRPCでCallメソッドを呼び出した場合,サービス要求先のTP1/Serverからの応答電文受信時にErrNetDownException,またはErrTimedOutExceptionが発生したときに,例外が発生したサービス要求先をRPCの宛先から除外します。同じサービスに対する2回目以降のRPCは,キャッシュにサービス情報がないため,ネームサービスから新しいサービス要求先を取得し,キャッシュをリフレッシュします。これによって,通信障害,またはタイムアウトが発生し続ける現象を回避できます。

この指定は,<rpc>要素のuse属性でnamを指定したときだけ有効です。

この属性は省略できます。

ErrTimedOutExceptionは,クライアント側,またはサーバ側の高負荷など環境によって発生することもあり,必ずしも通信障害やサーバ障害ではない場合があります。

なお,サービス要求先のTP1/Serverでサーバ障害や通信障害が発生すると,窓口となるTP1/Serverへサービス情報の通知ができなくなるため,窓口となるTP1/Serverのキャッシュには障害が発生したTP1/Serverのサービス情報が残ったままになることがあります。この状態では,CUP.NETがネームサービスへの問い合わせをしても,障害が発生したTP1/Serverのサービス情報を再度取得するため,キャッシュをリフレッシュできず,Callメソッドで例外が発生することがあります。そのため,この機能を使用する場合,TP1/Server側でノード監視機能の使用をお勧めします。

また,ノード監視機能を使用した場合でも,監視タイミングによってはネームサービスのキャッシュが更新されていないことがあります。そのため,ErrNetDownException,またはErrTimedOutExceptionが発生した場合,ネームサービス定義のname_audit_intervalオペランドに指定した監視間隔時間の間,CUP.NETのRPC呼び出し処理でリトライすることをお勧めします。

記述例

<rpc use="nam"
     watchTime="180"
     watchTimeNotification="false"
     maxMessageSize="1"
     compressData="false"
     prfInfoSend="true"
     cupRecvPort="6000"
     useMultiScheduler="false"
     extendOpt="00000001"/>