読者です 読者をやめる 読者になる 読者になる

夢とガラクタの集積場

落ちこぼれ三流エンジニアである管理人の夢想=『夢』と、潰えた夢=『ガラクタ』の集積場です。

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の概念については別途まとめる
さらなるまとめサイトの必要性について