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

こんにちは。

#stormjp のタグでStormの雑多な情報まとめその２です。
ちなみに呟きの過去から情報は追っていっていますが、呟いた後に判明した情報も
芋づる式に記述しています。
そのため、単に過去わかった情報だけではない・・・という構成になっています。

では、始めますか。

○10.Stormでは一定時間処理されなかったメッセージについてはタイムアウトとなり、
　Spoutにfailメソッドの呼び出しという形で戻ってくる。
　ただし、Spoutのack/failの機構が有効になるのは下記のようにTupleemit時にMessageIDを指定した場合のみ。

○11.タイムアウトが発生するタイミングはtopology.message.timeout.secsで決まる。
　ただし、「topology.message.timeout.secs」丁度ではタイムアウトしない。
　「topology.message.timeout.secs」はTupleがタイムアウトしたかどうかチェックする間隔。
　２回チェックされた結果、連続で処理待ちとして残っていたTupleがタイムアウトとして扱われる。
　そのため、タイムアウトは「topology.message.timeout.secs」の１倍より大きく、２倍未満の時間で発生する。

○12.Spoutのfailが呼ばれるのはタイムアウトするか、明示的にBolt側でfailメソッドを呼び出した場合。

○13.途中のBoltで単にTupleをackしてしまうとその時点でSpoutにackが返り、
　最後のBoltまで処理されたかどうかはわからない。
　途中のBoltでは、下記の順で処理を行う。
　１．受信Tupleをanchorとして次Bolt向けのTupleをemit
　２．受信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でも立ててみましょうかねぇ。

積み残しＡＩ：メッセージIDとAck/Failの概念については別途まとめる