解決したい問題

解決方針

/jubatus/actors/classifier/[NAME]/activeを追加
- これはnodesと異なり「ProxyがRPCを投げても良いプロセス」を意味するEphemeralノード
- これに伴いnodesは「ZKから生きていると認識されているプロセスとなるよう意味を変更
save/load時のデータ非互換
- バージョン番号のメンバを加えた分、save/load時に型が合わない
  - masterとして公開する際にコンバータを用意するなどで対処予定(別のパッチ)
put_diffの戻り値をvoidからboolへ変更
- これまでput_diffは成功シナリオのみしか想定していなかったが、バージョン番号埋め込みと共に失敗するパターンを考慮する必要がある
- フレームワークとしてのJubatusは個々のアルゴリズム内部に踏み込まない為、アルゴリズム側から「put_diffに失敗した」と教えてもらう必要がある
- classifier以外のすべてのアルゴリズムは暫定的にput_diffはすべてtrueを返す。これはこれまでの挙動を全く変更しない。
  - それらのアルゴリズムでモデルの最新バージョン獲得機能を使いたい場合にはput_diffにfalseを返せば良い(regressionもできるがやるとしたら別のパッチ)

他のプロセスにモデル全部を要求するget_modelの送信側と受信側を実装
mixer_loopは、「mix」のみの無限ループだったがこの処理を「mix」及び「必要なら他のプロセスからモデルを全部もらってくる」の2つの処理を行うループへと変更。それに伴って名前をstabilizer_loopに変更
put_diff適用時にfalseが帰ってきたら、自身のモデルが世代遅れになっていることを意味するので、is_obsolete_フラグを立て、activeとして保存したZKのエントリを消去
stabilizer_loop内で、is_obsolete_フラグが立っている事を検知したら他のプロセスからモデルを獲得しにいく
- モデル獲得時(get_model)は自分以外のプロセスからランダムに一つ選んでget_model RPCを投げる。獲得したら即Mixして最新であるか試す。
晴れてモデルが最新になっていればis_obsolete_フラグを折り、put_diffの成功時にactiveとしてZooKeeperに保存。
- これによりproxy経由でリクエストが来るようになる。

1プロセスのみしか居ない場合、get_modelは諦めて即座にactiveとして昇格する。
どこかのタイミングで最新のモデルを持つプロセスがすべて死んだ場合、古いモデル同士のmix時に採用するバージョン番号は必ずその古いモデルに合成可能なものとなるため、いずれ何らかの形で可能な限り最新なモデルが共有されるはず − get_modelをリクエストする先をランダムで決定しているが、性能的にはランダムではなくバージョン確認RPCを別で用意するなどの最適化が考えられるが、その場合いくつか問題がある
- RPCコマンドが更に増えてしまう
- フレームワークがバージョン番号というアルゴリズム固有のデータに踏み込んだ情報を管理する必要がある
なぜモデル側に番号を持たせるのか。フレームワーク側ではダメなのか
- linear_mixerの用例によっては古いものをput_diffしても問題なく動いて欲しいタイプの物もあると想定し、フレームワーク側ですべてを吸収するのは避けた。将来的にはフレームワーク側で吸収するモードのlinear_mixerを作り分けても良いかもしれない