Storm-源碼分析-Topology Submit-Task

mk-task, 比較簡單, 因為task隻是概念上的結構, 不象其他worker, executor都需要建立程序或線程 

是以其核心其實就是mk-task-data, 

1. 建立topologycontext對象, 其實就是把之前的topology對象和worker-data混合到一起, 便于task在執行時可以取到需要的topology資訊. 

2. 建立task-object, spout-object或bolt-object, 封裝相應的邏輯, 如nexttuple, execute 

3. 生成tasks-fn, 名字起的不好,讓人誤解執行了task的功能, 其實就是做些emit之間的準備工作, 其中最重要的就是調用grouper去産生targets task, 當然還包含些metrics, hooks的調用.

說白了其實mk-tasks, 沒做啥事

<a href="http://www.cnblogs.com/fxjwind/p/3217352.html">storm-源碼分析-topology submit-task-topologycontext</a>

:system-context, :user-context, 隻是context中的topology對象不同, system為system-topology!

這裡的builtin-metrics用來記錄spout或bolt的執行狀況的metrics

<a href="http://www.cnblogs.com/fxjwind/p/3225057.html">storm-源碼分析- metric</a>

傳回tasks-fn, 這個函數主要用于做emit之前的準備工作, 傳回target tasks list 

1. 調用grouper, 産生target tasks 

2. 執行emit hook 

3. 滿足sampler條件時, 更新stats和buildin-metrics

task-fn, 兩種不同參數版本

[^string stream ^list values], 這個版本好了解些, 就是将stream對應的component的target tasks都算上(一個stream可能有多個out component, 一份資料需要發到多個bolt處理)

[^integer out-task-id ^string stream ^list values], 指定out-task-id, 即direct grouping 

這裡對out-task-id做了驗證 

out-task-id (if grouping out-task-id), 即out-task-id-&gt;component-&gt;grouper不為nil(為:direct?), 即驗證這個stream确實有到該out-task-id對應component 

如果驗證失敗, 将out-task-id置nil

取出component的對象, 

比如對于spout, 取出spoutspec中的componentobject spout_object, 包含了spout的邏輯, 比如nexttuple()