RPC 関連の課題整理

Jubatus サーバのタイムアウト機能を使用したくないユーザ (--timeout 0) の救済方法を検討する
- 解決策: クライアントから close できるインタフェースを用意する (Jubatus クライアントを修正)
  - https://gist.github.com/kmaehashi/ab51ae3232e2bb092ad8
Jubatus サーバのタイムアウト機能を使用したいユーザの救済方法を検討する
- サーバから timeout で自動切断(サーバから TCP FIN パケット送信)された後に RPC メソッドを呼んだ際に RPC エラーが起きるのが不親切 (C++/Python/Ruby のみ)
- 解決策の案(松): サーバから受け取った FIN リクエストを正しくハンドリングするように修正 (msgpack-rpc ライブラリを修正)
  - msgpack-rpc-java はこうなっている (イベントループ周りっぱなし)
- 解決策の案(梅): FIN は無視して、次回送信時のエラー回復処理に任せる (次の「タイムアウト・リトライなど、RPC のあるべき姿を検討する」で議論)
タイムアウト・リトライなど、RPC のあるべき姿を検討する
- この gist で議論

RPC のあるべき姿

MessagePack-RPC ライブラリはトランスポート非依存を目指した設計になっていることに留意する必要がある。

外部から与えたいパラメタは [] で示す。

トランスポート層のエラー
- 接続確立失敗
  - [接続リトライ回数] x ([接続タイムアウト時間] + [接続リトライ間隔]) だけ自動リトライし、超過したらクライアントにエラーを通知
- 送信中にエラー
  - サーバから切断
    - クライアントにすぐにエラーを通知
  - クライアント内部のエラー (バッファ溢れ等)
    - 自動リトライ (write() が成功するまで繰り返すなど。 [送信リトライ回数], [送信リトライ間隔] を設ける) し、超過したらクライアントにエラーを通知
- 応答待ち
  - [処理タイムアウト時間] だけ待ち、超過したらクライアントにエラーを通知 (Jubatus ビジー)
- 受信中にエラー
  - クライアントにすぐにエラーを通知?
MessagePack 層のエラー
- クライアントにエラーを通知
MessagePack-RPC 層のエラー
- クライアントにエラーを通知
  - Jubatus クライアントと msgpack-rpc をつなぐ中間レイヤを用意して対処
    - jubatus/jubatus#205
アプリケーション層のエラー
- クライアントにエラーを通知
  - Jubatus クライアントと msgpack-rpc をつなぐ中間レイヤを用意して対処
    - jubatus/jubatus#205

これらの文書の主体は"RPCクライアント"を省略して書いている、と想定して問題ありませんか？

受信中にエラー

クライアントにすぐにエラーを通知
サーバ内のトランザクションは完了していることが保証されているので、自動リトライすべきでない

RPCではトランザクションの完了ということは保証できません。
RPCは、サーバ内で処理が 実行されたか（実行中か、実行待ちか）, 実行して、エラーが発生したか・正しく完了したか はクライアントがサーバから実行結果（レスポンス）を受け取るまで確認できないからです。