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

こんにちは。

#stormjp のタグでStormの雑多な情報まとめその３です。
段々前置きとかが思いつかなくなってきましたが、とりあえず入ります＾＾；

○19.StormとKestrelを組み合わせることで『Kestrelから取得したメッセージをStormで処理完了したことを保証する』
　アプリケーションが構築可能。
　Kestrelは「Transaction」という仕組みを持っており、
　ackが返されなかったメッセージは一定時間でメッセージを復旧させるため。
　そのため、Storm側で成功したらackを返し、失敗／タイムアウトしたらfailを返すように
　Kestrelとやり取りをすればＯＫ。
　上記の動作をする雛形はStorm-Kestrelにある。

○20.Nimbus、Supervisor、workerは各々ローカルに一時ファイルを出力する。
　出力先は【STORM_HOME】ディレクトリ配下のnimbus、supervisors、workers。
　そのため、その配下にファイル出力できない場合は正常動作しない。

○21.Spout/Boltのライフサイクルは下記。（これまでの話と被っているかも）
　１．トポロジを起動したクライアントにおいて生成される（コンストラクタが呼び出される）
　２．シリアライズされ、各Workerプロセスに配分される
　３．各Workerプロセスでデシリアライズされる
　４．Taskは実行前にprepareを呼ぶ（prepareメソッドが呼びだされる）

○22.FieldGrouping で違うBoltからのタプルも同じ名前のフィールドを持っていればグループ化出来る。
　このことを利用して異なるBoltの結果を同じグルーピングの中に落とし込んで動作させることが可能。

○23.Storm開発後数ヶ月でよくフォーラムに上がっていた質問は下記。
　気を付けること。
　−ZeroMQのバージョン違い
　−IPアドレス未指定（加えて、名前がDNSでひける必要があるため、hostsファイルにも書く）
　　後は　トラブルシューティングページ　https://github.com/nathanmarz/storm/wiki/Troubleshooting　参照

○24.StormのWorkerで使用できるクラスは、『起動時にlibディレクトリ配下にあったライブラリ』と、
　Topologyを起動したときのJar。
　さすがに依存ライブラリを自動検知してWorkerに流すことはできない。

○25.Stormは標準出力をサブプロセスと通信を行うために使用する。
　そのため、標準出力を基本的には使用しないこと。

○26.Error on initialization of server xxxx java.lang.UnsatisfiedLinkError: /usr/local/lib/libjzmq.so.0.0.0: というようなエラーの場合はZeroMQの問題

○27.Spoutで付与するmessageidはStorm内部の管理でのみ使用されるので、タプルのAPIで取得できるidとは違うもの

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