TwitterでつぶやいたStormの雑多な情報まとめ(その2
こんにちは。
#stormjp のタグでStormの雑多な情報まとめその2です。
ちなみに呟きの過去から情報は追っていっていますが、呟いた後に判明した情報も
芋づる式に記述しています。
そのため、単に過去わかった情報だけではない・・・という構成になっています。
では、始めますか。
○10.Stormでは一定時間処理されなかったメッセージについてはタイムアウトとなり、
Spoutにfailメソッドの呼び出しという形で戻ってくる。
ただし、Spoutのack/failの機構が有効になるのは下記のようにTupleemit時にMessageIDを指定した場合のみ。
○11.タイムアウトが発生するタイミングはtopology.message.timeout.secsで決まる。
ただし、「topology.message.timeout.secs」丁度ではタイムアウトしない。
「topology.message.timeout.secs」はTupleがタイムアウトしたかどうかチェックする間隔。
2回チェックされた結果、連続で処理待ちとして残っていたTupleがタイムアウトとして扱われる。
そのため、タイムアウトは「topology.message.timeout.secs」の1倍より大きく、2倍未満の時間で発生する。
○12.Spoutのfailが呼ばれるのはタイムアウトするか、明示的にBolt側でfailメソッドを呼び出した場合。
○13.途中のBoltで単にTupleをackしてしまうとその時点でSpoutにackが返り、
最後のBoltまで処理されたかどうかはわからない。
途中のBoltでは、下記の順で処理を行う。
1.受信Tupleをanchorとして次Bolt向けのTupleをemit
2.受信Tupleに対してackする
○14.storm.yaml他Stormで使用するyamlで数値として扱いたい場合は値を 1 のように直接記述する。
文字列として扱いたい場合は'1'のようにシングルクォートで囲んで記述する。
#Stormというわけではありませんね。これは^^;
○15.StormクラスタはLinuxで構築する。
ただし、Stormクラスタに対してTopologyを流し込むのはLinux、Windowsどちらからでも可能。
○16.Stormにおいて、WorkerプロセスはTopologySubmit時に明示的に渡した設定と、
ローカルのyamlファイルに記述されている設定両方を読み込む。
重複した場合はTopologySubmit時に指定した値が優先となる。
▽17.Rebalanceコマンドは下記のオプションを指定可能。
−TopologyがDeactivateとなる時間
−Worker数
−各Taskに割り振るスレッド(Executor)数。但し、最大はTaskの並列度まで。
○18.ZeroMQ、JZMQの最新版を導入した場合動作しない。
Stormのページに書かれたバージョンを使用すること。
尚StormではZeroMQを使用せずに純粋なJavaプロセスとして動作させることも検討ポイントに入っている。
と、今回はこの辺で一段落です。
・・・え?
既にこのまとめ自体が流れていくように存在になっているって?
・・・とりあえず、対処は考えます。
どこかにWikiでも立ててみましょうかねぇ。
積み残しAI:メッセージIDとAck/Failの概念については別途まとめる