Apache Curator Framework のリトライ処理について調べてみる - 社内se × プログラマ × ビッグデータ

zookeeper サーバと接続出来なかった場合、そのリトライ処理はどのように実装されるのか？

概要

・ Curator とは、Zookeeper 上に構築された一連の高レベルライブラリ

→複雑な接続処理を容易にするAPIを提供してくれるもの

前提

・ローカル環境で Zookeeper サーバを起動していない状態において、Curator を使用したアプリを起動してみる。

→当然、接続はされないはず

→設定されたタイムアウト時間、リトライ回数後に終了してくれるはず？

実践

・新しい curator クライアントを生成する。

→新しい curator クライアント生成時において、セッションタイムアウト時間、コネクションタイムアウト時間、リトライ回数などを定義出来るようだ。

まとめ

・セッションタイムアウト時間は、一度はコネクションはされたものの、サーバと通信出来なくなった場合のタイムアウト時間っぽい。

・コネクションタイムアウト時間は、サーバに初めて接続を試みたが、サーバと通信出来ない場合のタイムアウト時間と思う。

・セッションタイムアウト時間、コネクションタイムアウト時間はそれぞれ１試行内の猶予時間。タイムアウトしたとしても、リトライ回数が残って入れば改めてタイムアウト時間まで接続を試みる。

応用

・curator を生成するだけでは、zookeeper への接続は必ずしも発生しない？

→curator 生成するだけなら、 zookeeper 停止していてもエラーにならないかも

→znode を作成するタイミングで zookeeper に接続しにいくから、そこでエラーになる

・デフォルトのセッションタイムアウト時間、コネクションタイムアウト時間は？

→バージョンによって異なるとは思うが、セッションタイムアウトは６０秒で、コネクションタイムアウトは１５秒。

・リトライが終了したら、例えば ConnectionLossException が発生する（はず）

参考リンク

http://curator.apache.org/curator-client/