Hitachi

インメモリデータグリッド uCosminexus Elastic Application Data store ユーザーズガイド


9.3.1 通信を監視するタイマの設定

TCPプロトコルを使用するEADsクライアント・EADsサーバ間の通信では,次に示す時間を監視することによって,通信障害を検知しています。

データの読み込みについては,1つの電文を受信する際に複数回発生することがあります。

考え方

監視時間を短くすることで通信障害を検知するスピードを早めたり,長くすることで頻繁にタイムアウトが発生するのを防いだりします。

〈この項の構成〉

(1) EADsクライアント・EADsサーバ間での通信タイムアウトの設定

EADsクライアント・EADsサーバ間の通信では,次の図に示す通信タイムアウトが設定できます。

図9‒1 EADsクライアント・EADsサーバ間での通信タイムアウトの設定

[図データ]

通信タイムアウトの設定で使用するパラメタを次の表に示します。表の項番は,図9-1の(1)〜(6)に対応しています。

表9‒3 通信タイムアウトの設定で使用するパラメタ

項番

設定するタイムアウト

定義ファイル

パラメタ名

1

EADsサーバへの接続

クライアント定義ファイル

eads.connection.send.timeout

2

EADsサーバへのデータ送信

3

EADsサーバからのデータ受信

eads.connection.receive.timeout

4

EADsクライアントからのデータ受信

サーバ定義ファイル

eads.connection.timeout

5

EADsクライアントへのデータ送信

6

通信のない常設コネクションの切断

eads.server.session.keepAlive.timeout

EADsクライアント・EADsサーバ間の通信で,タイムアウトが設定できる個所を次の図に示します。

図9‒2 EADsクライアント・EADsサーバ間の通信で,タイムアウトが設定できる個所

[図データ]

各タイムアウト(図中の(1)〜(6))に設定する値の考え方については,次の個所で説明します。

また,ポイントとなる項目(★1〜★5)については,「9.3.1(4) タイムアウトに設定する値を考慮する際のポイント」で説明します。

(2) 通信タイムアウトに設定する値の考え方

通信タイムアウト(図9-2の(1)〜(5))は,設定したタイムアウト時間内に処理が完了することを期待するものではなく,次のような状態を検知するための機能です。

そのため,期待する時間内に応答がない場合でも,通信タイムアウトの機能で通信を切断することは推奨しません。

EADsサーバの処理は,EADsクライアントとの通信路の状態とは関係なく進みます。EADsクライアントへの応答時に通信路の切断を検知しても,データのロールバックは行いません。そのため,通信タイムアウトの機能で通信を切断してしまうと,EADsクライアントでは,データ操作の結果がわからなくなります。

処理の遅延やネットワークの遅延ではなく,通信先の障害や通信路の切断などを正しく検知できるように,通信タイムアウトの時間をチューニングすることを推奨します。

(3) 常設コネクション切断までのタイムアウト値の設定

常設コネクション切断までのタイムアウト値の設定(図9-2の(6))は,AP(ユーザプログラム)が動作するOS,またはホストがダウンした場合にEADsサーバが気づくことができない場合に,OSに設定されたTCPのkeep-aliveのアイドル時間までコネクション,およびスレッドが占有されることを防ぐためのものです。

設定する際は次の3点を考慮して,ほかの機能に問題のない範囲で,かつむだな通信の切断やエラーを避けられるように,大きめの値を設定することを推奨します。

(4) タイムアウトに設定する値を考慮する際のポイント

タイムアウトに設定する値を考慮する際に,ポイントとなる項目について説明します。なお,このポイントは図9-2の★1〜★5に対応しています。

ポイント1(★1)

EADsクライアントからの通信は,通常,常設コネクションを使用します。そのため,初回接続時や,クライアントライブラリを使用するスレッドが増加した場合にだけ接続処理が発生します。接続タイムアウトには送信タイムアウトと同じ値(クライアント定義のeads.connection.send.timeoutパラメタの値)が使用されます。

ポイント2(★2)

データ送信処理は送信側の送信バッファにデータを格納した時点で送信完了とみなされます。そのため,送信バッファに収まるサイズの送信処理では,受信側プロセスや通信路の状態に関係なく,データの送信処理が成功します(通信路に問題がある場合は,次の受信処理でエラーになります)。

送信バッファより大きいサイズのデータを送信する場合,FullGCなど受信側プロセスの問題で送信エラーが発生することがあります。送信バッファのサイズを超えるような大きなデータを送信する場合は,受信側プロセスのFullGCなどに掛かる時間を考慮する必要があります。

ポイント3(★3)

送信処理,受信処理は,内部では複数回に分けて実行されます。その際,それぞれの処理でタイムアウト値が適用されます。そのため,タイムアウト値は応答が戻るまでの時間を保証するものではありません。

ポイント4(★4)

EADsクライアントは,EADsクライアント側の送信処理が終わった時点から次の読み込み処理に移ります。このとき,送信したデータをEADsサーバが受信しているかどうかは考慮されません。

また,EADsクライアントの受信タイムアウトに含まれる時間には,EADsサーバ上のデータ操作やユーザファンクションの実行時間が含まれます。処理に時間が掛かるユーザファンクションが存在する場合,ユーザファンクションの処理時間に合わせてクライアント定義を設定すると,通常の通信には適さない値となるおそれがあります。そのような場合には,クライアント定義でタイムアウト値を設定するのではなく,タイムアウトつきのAPIの使用を推奨します。

ポイント5(★5)

EADsクライアントへのレスポンス送信を終えたEADsサーバは,次のリクエスト待ちとなります。この受信処理には,通常の通信タイムアウト(サーバ定義のeads.connection.timeoutパラメタで指定した値)ではなく,常設コネクションのタイムアウト(サーバ定義のeads.server.session.keepAlive.timeoutパラメタで指定した値)が適用されます。常設コネクションのタイムアウトの設定値については,「9.3.1(3) 常設コネクション切断までのタイムアウト値の設定」を参照してください。