TwitterでつぶやいたStormの雑多な情報まとめ（その８

こんにちは。

#stormjp のタグでStormの雑多な情報まとめその７です。
段々、終わりが見えてきたような感はありますｗ

○81.Stormクラスタ自体のアップデートは起動しっぱなしでは無理。
　安全確実を期すなら下記のフロー。
　１．Topology全部落とす
　２．Storm-Nimbus、UI、Supervisorを落とす
　３．ZK上とローカルのファイルを全部削除
　４．Storm-Nimbus、UI、Supervisorを再起動
　尚、Stormにとっては動作しながらのクラスタ自体のアップデートへ対応する優先度は低い。

○82.storm.yamlのworker.childoptsでWorkerプロセス起動時のJVM引数を指定できるが、
　その際「%ID%」と指定すればWorkerプロセスのIDに置換されて実行される。

83.LinearDRPCですとSpout/Boltの生成タイミングが少々特殊なため、
　インスタンスフィールドのデータが次のDRPC実行時に消えてしまうケースもある。
　コンストラクタで生成する際に渡しておけば当然ながら消えない。

○84.StormにおけるHeartBeatはZooKeeperを介するためディスクIOが付随する。
　そのため、ディスクIOが極端に遅くなっている状況ではHeartBeatに失敗することもある。

85.StormのAck/Fail機構において、「Anchor」としてTupleを指定し、
　その下に複数のTupleを子Tupleのようにぶら下げることで、子Tupleが全て処理成功した場合に
　Anchorとして設定したTupleに対してAckを返す・・・ということが可能。
　その際、Ackerの中では子TupleのAckIDは全体で一つのlong値しか保持せず、
　子TupleのAckを受信するごとにAckIDの排他的論理和を計算していく形を取る。
　結果が全て0bitとなれば、子Tupleは全て処理されたと判定される。
　子TupleのIDはLong値のランダムであるため、極々まれに子Tupleが全て処理される前にAckが返ったと誤認する可能性がある。

86.OutputCollectorはスレッドセーフでは無いため、別スレッドで後からアクセスするとエラーとなる
　
87.ZooKeeperは3.3.3〜3.4.2では動くことは確定。
　0.8.0の正式版になると何故かZooKeeperのバージョンが3.4.2→3.3.3と退行しているが、まぁ問題はなさそう。

88.Nimbusの冗長化についてはロードマップには載っているものの、優先度は低い。
　実際Nimbusが死んでも処理は継続する、再起動すれば元に戻るため、困る人間が少ない模様。
　ただし、Nimbusを保持するノードごと吹っ飛んだ場合はNimbusを同じIPアドレスで復旧させる必要があるため厄介。

○89.Clusterモードの場合、Stormの終了メソッド（cleanup）は呼び出されない。
　呼び出すことが保証されないため。
　ただ、保証はできないものの今後呼び出されるようにしようという動きはある模様。

○90.ZooKeeperに不正な状態が残るとStormも影響が出るため、
　どうしても動きが変な場合は全部クリアするべし。

さて、今回はここまで。
・・・いかん、なんか似たような内容を書いたような記憶がある項目がｗ

積み残しＡＩ：
メッセージIDとAck/Failの概念については別途まとめる
さらなるまとめサイトの必要性について
実際の実装を添付してまとめる