書き込みメッセージを停止しないでdroonga-engine-joinできるようにする

[piroor]

現状で既に、メッセージ転送のバッファ（転送先ノードが死亡していたらバッファに溜めておいて、復活したらバッファのメッセージを送る）は可能となっている。
あとは、「サービスは生きていて、Droongaのメッセージ転送の仕組みに則ったメッセージ送受信も可能」というノードに対してどうやって「書き込みメッセージをバッファに溜めておき、復活したらバッファのメッセージを送る」をどのようにして実現するかが問題である。

プラン1：現状のバッファ機構（BufferedTCPSocket）を使う。

• 概要：
  • DROONGA_BASE_DIR/state/status.json あたりを使って「データ移行中」のようなフラグを保持できるようにし、データ移行中のdroonga-engine（送り出し側、受け側両方とも）は、droonga-engine.yamlで決められているポート番号とは違うポートをlistenする・メッセージの宛先に使うようにする。
• メリット：
  • 送り出し側にオーバーヘッドが生じない。
• デメリット：
  • クラスタ構成変更時に、起動ポートの変更、catalog.jsonの更新など、コピー元になるノードとコピー先になるノード（クラスタ）の全ノードが一斉に自身の状態の変更と再起動を繰り返すことになる。

プラン2：DispatcherとForwarderの間に新たにバッファ機構を挟み込む。

• 概要：
• メリット：
  • 変更箇所がDispatcherとForwarderの間だけにとどまる。
• デメリット：
  • 送り出し側にオーバーヘッドが生じる。

[kou]

プラン3：「サービスは生きていて、Droongaのメッセージ転送の仕組みに則ったメッセージ送受信も可能」というノードがバッファする。

というのはどうだろう。

Droonga::Engine#process で、自分のステータスがsuspendとかcopyingとか（「サービスは生きていて、Droongaのメッセージ転送の仕組みに則ったメッセージ送受信も可能」というノード）という状態になったら、dispatcherにメッセージを送らずにバッファする。で、ステータスがactiveとかに戻ったらまずはバッファしているメッセージから処理する。

というイメージ。

[piroor]

メッセージを受信した側のノードが、dispatcherの所で堰き止めるということでしょうか？

送信側Dispatcher(1)→送信側Forwarder(2)→送信側BufferedTCPSocket(3)→受信側Dispatcher(4)→...

とある時に、

• プラン1：3の後で堰き止める
• プラン2：1の後で堰き止める。
• プラン3：4の後で堰き止める。

ということでしょうか。

プラン3は、その上でdump系のコマンドだけ堰き止めずに通すようにするという事なのだと思いますが、送信側ノードが自分の受信したdumpをForwardしてしまった時にまでそれを処理してしまうということはないでしょうか？
そういう事が起こらないように特例を設けて……とやっていくと、普通のコマンドの取り扱いの中で特例がどんどん増えてしまう気がして、自分は不安が大きいです。

[piroor]

プラン3：3と4の間、受け側のEngine（Dispatcherより手前）で書き込み系メッセージを堰き止めるという案。

しかしこの方法だと、dumpによるデータコピーのためのメッセージまで堰き止めてしまう。
よって、このプランは不採用とする。