2.15.1 TP1/Serverとの通信時
- 〈この項の構成〉
(1) 通信先ホスト複数指定個所
Client .NET構成定義の<tp1Server>要素を2個以上指定します。
(2) 通信先ホスト選択契機
OpenRpcメソッド実行時に選択します。
接続障害発生時は，Callメソッド実行時にホストを切り替えます。
|
実行メソッド |
ホスト切り替えの契機 |
|---|---|
|
Call |
|
(3) 通信先ホスト選択方法
Client .NET構成定義の<nameService>要素のrandomSelect属性の指定値によって，選択方法が異なります。randomSelect属性の指定を省略，またはfalseを指定した場合，<tp1Server>要素のhost属性に指定された順番に通信先ホストを選択します。
この指定の場合，Client .NET構成定義の<tp1Server>要素のhost属性に同一の指定を行った複数のCUP.NETから一斉にサービスを要求した場合，1つのホストに負荷が集中してしまいます。randomSelect属性にtrueを指定すると，初回Call()メソッド呼び出し時にランダムに通信先ホストを選択するため，サーバの負荷を分散させることができます。
|
randomSelect |
通信先ホストの選択方法 |
|
|---|---|---|
|
初回選択時 （OpenRpcメソッド実行時） |
接続障害発生時 |
|
|
false |
先頭に指定されたホストを選択します。 |
障害となったホストの次に指定されたホストを選択します。 |
|
true |
複数指定されたホストの中からランダムに選択します。 |
障害となったホストの次に指定されたホストを選択します。 |
ホスト切り替えは，通信が成功するまで繰り返し行います。指定されたすべてのホストとの接続に失敗した場合，メソッドはエラーリターンします。
次メソッド発行時，再度ホスト切り替えが発生した場合，前回障害となったホストも切り替えるホストの対象となります。
ホスト切り替えによって決定したホストは，次の契機で再びホストの選択，または切り替えが発生するまで，通信先ホストとなります。
-
OpenRpcメソッドによるホスト選択
-
SetTP1Serverメソッドによるホスト選択
-
Callメソッドの接続障害で再びホスト切り替えが発生
- 例1) 次の指定の場合
<tp1Server host="hostA"> <tp1Server host="hostB"> <tp1Server host="hostC"> <nameService randomSelect="false"> 1. OpenRpcメソッド発行 先頭に指定されたhostAを選択 +-----+ |hostA| hostB hostC +-----+ hostAとの接続に成功 2. Callメソッド発行 hostAとの接続障害発生 障害となったhostAの次に指定されたhostBを選択 +-----+ × |hostB| hostC +-----+ hostBとの接続障害発生 障害となったhostBの次に指定されたhostCを選択 +-----+ × × |hostC| +-----+ hostCとの接続に成功 3. Callメソッド発行 hostCとの接続障害発生 障害となったhostCの次に指定されたhostAを選択 +-----+ |hostA| hostB × +-----+ hostAとの接続障害発生 障害となったhostAの次に指定されたhostBを選択 +-----+ × |hostB| × +-----+ hostBとの接続障害発生 選択対象ホストがなくなりメソッドはエラーリターン 4. Callメソッド発行 3.で最後に接続障害が発生したホストhostBを選択 +-----+ hostA |hostB| hostC +-----+ 5. CloseRpcメソッド発行 6. OpenRpcメソッド発行 先頭に指定されたhostAを選択- 例2) 次の指定の場合
<tp1Server host="hostA"> <tp1Server host="hostB"> <tp1Server host="hostC"> <nameService randomSelect="true"> 1. OpenRpcメソッド発行 hostA，hostB，hostCからランダム選択 +-----+ hostA |hostB| hostC +-----+ hostBとの接続に成功 2. Callメソッド発行 hostBとの接続障害発生 障害となったhostBの次に指定されたhostCを選択 +-----+ hostA × |hostC| +-----+ hostCとの接続障害発生 障害となったhostCの次に指定されたhostAを選択 +-----+ |hostA| × × +-----+ hostAとの接続に成功 3. Callメソッド発行 hostAとの接続障害発生 障害となったhostAの次に指定されたhostBを選択 +-----+ × |hostB| hostC +-----+ hostBとの接続障害発生 hostCを選択 +-----+ × × |hostC| +-----+ hostCとの接続障害発生 選択対象ホストがなくなりメソッドはエラーリターン 4. Callメソッド発行 3.で最後に接続障害が発生したホストhostCを選択 +-----+ hostA hostB |hostC| +-----+ 5. CloseRpcメソッド発行 6. OpenRpc発行メソッド hostA，hostB，hostCからランダム選択
(4) 窓口ホストの切り替え契機の変更
Client .NETは，Client .NET構成定義に窓口となるホストを複数指定しておくと，指定したホストと一時的に通信できなくなった場合に，ホストを切り替えて別のホストに通信を試みます。
ネームサービスを使用したRPCの場合，従来のClient .NETは，ネームサービスとの接続エラーのときだけ窓口ホストを切り替えていました。
この機能を使用すると，下図の1.で示す従来のホスト切り替え契機に加え，下図の2.から4.で示す範囲のエラー種別も，ホスト切り替え契機にできます。これによって，業務形態に応じて最適なホスト切り替え契機を選択できます。
窓口ホストの切り替え契機とするエラー種別は，Client .NET構成定義 <nameService>要素のhostChangeMode属性に指定します。
|
|
![[図データ]](GRAPHICS/ZU090170.GIF)
Callメソッドでは次の内部処理を実行しており，1.から4.で示す範囲のエラーが発生したときを窓口ホストの切り替え契機にできます。
- <サービス情報の問い合わせ>
-
1. ネームサービスとの接続エラー
2. ネームサービスからのエラー応答電文受信
3. ネームサービスからの応答電文受信タイムアウト※
- 注※
-
タイムアウトの監視時間を<nameService>要素のsysWatchTime属性で指定します。
- <サービス要求（RPC）>
-
4. スケジュールサービスからのエラー応答電文受信
エラーの詳細を次の表に示します。
|
内部処理 |
エラー範囲 |
エラーの詳細 |
<nameService>要素のhostChangeMode指定値 |
|
|---|---|---|---|---|
|
サービス情報の問い合わせ |
1. ネームサービスとの接続エラー |
|
省略 |
all |
|
2. ネームサービスからのエラー応答電文受信 |
|
namrcv |
||
|
3. ネームサービスからの応答電文受信タイムアウト |
|
namtimeout |
||
|
サービス要求（RPC） |
4. スケジュールサービスからのエラー応答電文受信 |
|
scdrcv |
|
<nameService>要素のhostChangeMode属性に"namtimeout"を指定したときの，<rpc>要素のwatchTime属性，<nameService>要素のsysWatchTime属性，および<socket>要素のconnectTimeout属性との関係性を次の図に示します。
|
|
![[図データ]](GRAPHICS/ZU090180.GIF)
-
"ホストA"のネームサービスとのコネクション確立が成功し，サービス情報を問い合わせます。
-
100秒経過してもネームサービスから応答が返ってこなかった場合，"ホストB"へ窓口ホストを切り替えます。
-
"ホストB"のネームサービスとのコネクション確立が成功し，サービス情報を問い合わせます。
-
"ホストB"のネームサービスからの応答待ちで100秒経過する前に，Call()メソッドの最大応答待ち時間である180秒が経過すると，"ホストC"へホストを切り替えません。その時点でCUP.NETのCall()メソッドはErrClientTimedOutExceptionを返します。
(5) 応答電文受信障害時のキャッシュリフレッシュ
CUP.NETが同じサービスに対する2回目以降のRPCをする際は，Client .NETのキャッシュを参照します。キャッシュにサービス情報が格納されていれば，キャッシュ内のサービス情報を使用し，RPCを行います。このとき，CUP.NETがサービス要求先のTP1/Serverからの応答電文を受信する際に障害が発生すると，障害が発生したサービス情報がキャッシュに残るケースがあります。この状態になると，3回目以降のRPCでも，キャッシュに残っているサービス情報を使うため，再び通信障害やタイムアウトが発生する可能性があります。
この現象は，次の1.〜3.のどれかを実施するまで発生し続けます。
-
CloseRpcメソッドを呼び出して，RPC環境を解放
-
キャッシュの有効期限満了によるキャッシュの更新
-
サーバ側のエラー要因の復旧
前述の1.〜3.のどれかを実施しなくても，応答電文受信障害時にキャッシュをリフレッシュすることで，上記の現象が回避できます。
この機能はネームサービスを使用したRPCで，Client .NET構成定義<rpc>要素のextendOpt属性に00000001を指定した場合に使用できます。
この機能を使用して2回目以降のRPCを正常に実行する例を次の図に示します。
|
|
![[図データ]](GRAPHICS/ZU090190.GIF)
-
TP1Clientクラスのインスタンスを作成します。
-
OpenRpcメソッドを呼び出して，CUP.NETのRPC環境を初期化します。
-
Callメソッドを呼び出して，該当するSPPにサービスを要求しますが，応答電文受信時に障害が発生します。Callメソッドでは，次の内部処理を実行します。
-
ホストAへサービス情報の問い合わせを行い，Client .NETのキャッシュに格納します。
-
キャッシュに格納したサービス情報を使用してRPCを行います。
-
RPC応答受信時に通信障害または，タイムアウトが発生したため，Client .NETのキャッシュからサービス情報を削除します。
-
-
Callメソッドを呼び出して，該当するSPPにサービスを要求します。
Callメソッドでは，次の内部処理を実行します。
-
ホストAへサービス情報の問い合わせを行い，最新のサービス情報でClient .NETのキャッシュをリフレッシュします。
-
Client .NETのキャッシュからリフレッシュしたサービス情報を取得します。
-
取得したサービス情報を使用してRPCを行います。
-
-
CloseRpcメソッドを呼び出して，RPC環境を解放します。