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

夢とガラクタの集積場

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

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を流し込むのはLinuxWindowsどちらからでも可能。

○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の概念については別途まとめる