TwitterでつぶやいたStormの雑多な情報まとめ(その3
こんにちは。
#stormjp のタグでStormの雑多な情報まとめその3です。
段々前置きとかが思いつかなくなってきましたが、とりあえず入ります^^;
○19.StormとKestrelを組み合わせることで『Kestrelから取得したメッセージをStormで処理完了したことを保証する』
アプリケーションが構築可能。
Kestrelは「Transaction」という仕組みを持っており、
ackが返されなかったメッセージは一定時間でメッセージを復旧させるため。
そのため、Storm側で成功したらackを返し、失敗/タイムアウトしたらfailを返すように
Kestrelとやり取りをすればOK。
上記の動作をする雛形はStorm-Kestrelにある。
○20.Nimbus、Supervisor、workerは各々ローカルに一時ファイルを出力する。
出力先は【STORM_HOME】ディレクトリ配下のnimbus、supervisors、workers。
そのため、その配下にファイル出力できない場合は正常動作しない。
○21.Spout/Boltのライフサイクルは下記。(これまでの話と被っているかも)
1.トポロジを起動したクライアントにおいて生成される(コンストラクタが呼び出される)
2.シリアライズされ、各Workerプロセスに配分される
3.各Workerプロセスでデシリアライズされる
4.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とは違うもの
積み残しAI:
メッセージIDとAck/Failの概念については別途まとめる
さらなるまとめサイトの必要性について