以下の目的を達成するための指針をこの文書でまとめる。 Action Itemは末尾に書いた。
- Jubatusクライアントの正しい使い方を示す
- これには、ラップしたMessagePack-RPCクライアントの設定やエラー処理も含める
対象:
- RPCサーバ:jubatus-msgpack-rpc(C++)のJubatus
- Jubatus及びラップするRPCクライアントの言語
- Ruby
- Python
- Java
- C++
- 言語実装ごとのまとめはこちら: https://gist.github.com/suma/5298923
- クライアントのインスタンス(オブジェクト)を作る
- タイムアウトの値を指定したり、パラメータを変更してもよい
- RPCを呼ぶ
- 成功したときは結果の値を見る(か無視する)
- エラーが発生したときは、エラー処理
- 無視(プログラムのクラッシュ)・再試行する・握りつぶすかなど、どう扱うかは開発者の責任となる
- → 処理すべきエラー一覧/サンプルが必要
- → エラー一覧とは、MessagePack-RPCライブラリと、Jubatusの各サーバが発生させるものが必要
- C++以外の実装では、RPCが一度成功してから、次にタイムアウトエラーが起こったとき何が原因か例外からは判別できない。RPC再度呼び出すまでにラグがあるのであれば or エラーの種類を見分けたいのであれば、逐一closeすることをオススメする。
- 1行で:MessagePack-RPCライブラリごと + Jubatusごとに調査し、サンプルを作ってまとめる
-
各言語ごとにサンプルを作る
-
通常の使い方
-
パラメータ(タイムアウト等)の変更
-
エラー処理
-
JubatusのRPCサーバ(keeper含む)が返すエラーをまとめる
-
jubatus-msgpack-rpc 実装(のエラー定義)によるもの
-
エラー処理のサンプル作る
- JubatusのRPCサーバ(keeper含む)が返す可能性のあるエラーをまとめる
- どのサーバでも共通で発生するもの: NO_METHOD_ERRORやARGUMENT_ERRORとか
- C++のstd::bad_allocが発生したらどうなるか、とか
- エラー処理のサンプル作る
- Jubatus各サーバ(アルゴリズム)特有のエラーをまとめる・サンプルを作る
- anomaly
- classifier
- recommender
- graph
- regression
- stat
各言語・各サーバでまとめると、4*6という数だけに大変な作業量になるので、以下の程度に共通部分はいっしょにしてまとめてしまってよいと思う。
- 各言語ごとにベストプラクティス, サンプル(MessagePack-RPC特化 + JubatusのRPCサーバ共通)
- Jubatus各サーバごとのエラー処理