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

夢とガラクタの集積場

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

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

こんにちは。

#stormjp のタグでStormの雑多な情報まとめその7です。
お、思ったより手ごわいw


71.単一のBoltからイベントの内容を見て違うBoltに分岐させたい場合、
 違うStreamに書きこめば分岐が可能。Stormの開発者もその方式を推奨している。
 尚、受信側で送信元を見て処理を変えたい場合はgetSourceComponent/getSourceTaskで取得して対応する。

72.Spoutはack/fail/nextTupleメソッドが全て同じスレッドから呼ばれている。
 そのため、どれか1か所でブロックした場合、それ以外のメソッドも呼ばれなくなる。

73.StormUIで表示される、Complete latencyは「はじめのSpoutでemitされた瞬間」から、
 「最後のBoltでの処理が完了し、Ackerがackを処理した瞬間」の時間を示している。
 そのため、Bolt内部で計測した合計処理時間とComplete latencyの差分が大きい場合は、
 『Spoutから取得するTupleの数が多すぎて、処理しきれない』状態に陥っている可能性が大きい。

74.Bolt間(つまりはStormの内部)で待ちが発生したり、タイムアウトが発生する状況だと
 Bolt内部の処理時間合計とComplete latencyの差分が大きくなる。
 その場合はStorm内部のどこかでイベントが詰まって処理時間を遅らせているということ。
 Workerプロセスで「gc overhead limit exceed exception」が頻発する場合も同様の症状が疑われる。

75.Spout→Boltで実際素早く処理されているのに、妙にComplete latencyが大きくなる場合は、
 『Ackerの処理が間に合っていない』という可能性もある。

76.Ackerも他のSpout/Boltと同じように並列度、Executorの数が設定可能。

77.Spoutのopenメソッド、Boltのprepareメソッド
 Taskを実行するスレッド(executeメソッドを呼ぶスレッド)から呼び出される。

○78.Storm-UIのポート番号はデフォルト8080だが、ui.port: 1234・・・という形で変更可能
 そのためTomcat等8080ポートを良く使うサービスが起動しているサーバでも使用することはできる。

79.StormはJava6以上で動作のため、Java7でも問題なく動作する。

80.Topologyは再起動/Rebalance時に停止時間が発生するため完全な無停止更新は不可能。
 Topologyをdeactivate状態でsubmitして、どこかのタイミングで
 古いTopologyをdeactivate→新しいTopologyをactivateとすれば近いことは可能。

さて、今回はここまで。
段々背景としてのStormに対する知識がないと何が何やらわからない内容になってきていますねぇw

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