11(金)

@k_oi に NameNode HA の RetryCache の挙動を説明していたら理解に甘いところがあったので，再度設計と意義を確認した．

  1. (Active) UUID + CallID を受け取って処理実行．
  2. (QJM) UUID + CallID 込みで Journal に保存．
  3. (Active) 処理結果を基にレスポンスを作成し，UUID + CallID をキーにしてレスポンスを一定期間 RetryCache に保存．
  4. (Active) もし Client から以前に処理した UUID + CallID のリクエストが飛んできたら，同じ内容を返す．

RetryCache 自体は，Client 側のタイムアウトが発生してしまったが正しく処理された場合に同等の結果を返すもので，これにより限定的に AtMostOnce セマンティクスを実現している．将来的に QJM に保存した Journal から RetryCache を復元する機能が入るかもしれないが，これは必要になったら作るとのこと．