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

こんにちは。

最近 Twitter上で #stormjp のタグでStormの雑多な情報を呟いているのですが、
ひたすら流れていくばかりだったため、この後ちょこちょこまとめていきます。

・・・ええ、私自身さっぱり覚えていられなくなりましたので（汗

とりあえずは古い方から・・・気が付いたら #stormjp の呟きだけで900回近いつぶやきになっていました。

○1.StormのLocalModeはWindows+Eclipseからでも起動可能
　→　ただし、TempディレクトリにZookeeperのゴミファイルが残るので注意。
　　　特にCIサーバ。

○2.StormのTupleにはObjectが投入可能だが、プロセスをまたがる際にはシリアライズが行われるため、
　独自エンティティクラスは全てシリアライズ可能としておくこと
　Tupleにはシリアライズ可能なオブジェクトのみ設定すること。

○3.独自エンティティクラスはTopology起動時にConfig#registerSerializationメソッドでシリアライズ可能と
　登録をしておくか、storm.yamlファイルに記述しておく必要がある。

○4.StormのLocalModeでもWorker数を複数に指定すればエンティティのシリアライズが行われるため、
　実際に複数プロセスで動作させた場合に問題が発生しないかはわかる

○5.Spout/Boltで例外が発生してユーザが開発したコード部でキャッチされなかった場合は
　そのSpout/Boltはダウンし、所属するWorkerプロセスごとフェールオーバーされる
　キャッチされなかった例外情報はStorm-UIで確認可能。
　ReportedFailedExceptionを投げた場合はSpout/Boltをダウンさせずに例外情報をStorm-UIに表示させることが可能

○6.StormではAck/Failの機構を上手く使用すると全メッセージを「少なくとも１回」処理することが可能。
　ただし、重複処理したメッセージをフィルタリングする機能は持っていないため、
　それはStormとは別口で対処すること。

○7.StormクラスタでTopology起動時、Workerのスロットが足りない場合には
　確保できるだけWorkerプロセスを確保してTopologyは起動される。
　ただし、その場合Spout/Boltが一部しかそろわないケースもあるため、処理が全て実行可能とは限らない。

○8.Spout/BoltはTopologySubmit時に作成されたインスタンスが「シリアライズ」されて
　各Workerプロセスに配分される。
　そのため、TopologySubmit時にシリアライズ可能なフィールドに値を設定しておけば、
　Workerプロセスに分散した後でも設定された値を使うことが可能。
　つまりはTopologySubmit時に必要な設定値を全て設定しておくことも可能。

○9.Spout/Boltが落ちた場合、Spout/Boltが保持していたフィールドの情報は消滅する。

・・・とまぁ、とりあえず書き出してみましたが、
このあたり全て書ききった後で再度まとめる必要がありそうですねぇ。

積み残しＡＩ：メッセージIDとAck/Failの概念については別途まとめる