## 執行時topology的task列表中報"task is dead"錯誤
有幾個原因可能導致出現這個錯誤：
1. task心跳超時，導致nimbus主動kill這個task所在的worker
2. task對應的 bolt/spout 中的open/prepare/execute/nexttuple等，沒有對異常做try...catch，導致丟擲異常，導致task掛掉。**這裡要注意一下，乙個worker中任意乙個task如果沒有做異常處理，會導致整個worker掛掉，會導致該worker中其他task也報task is dead**，所以在jstorm的應用**中，**強烈建議在所有的方法中都加上try...catch**。
具體排查可以這麼來做：
1. 如果task是每隔4分鐘左右有規律地掛掉，那麼基本可以確定是task心跳超時導致的，可以直接跳到3
2. 檢視worker日誌，在掛掉的時間點是否有異常。但是注意要看掛掉的那個worker的日誌，而不是重新起來之後新的worker的日誌，因為worker重新起來之後可能位於不同的機器上。
3. 如果worker日誌沒有異常，那麼可以看一下集群nimbus的日誌，搜一下："update taskheartbeat"，然後找到掛掉的worker所對應的topology id，看看最後更新心跳的時間是什麼時候。對比一下task心跳超時的配置（nimbus.task.timeout.secs），如果worker掛掉的時間 - 最後一次更新心跳的時間 > task心跳超時，那麼基本上可以確定是因為task心跳超時被kill了。這有幾種可能：
* 執行佇列被阻塞了，一直沒有返回；
* worker發生了fgc，這會導致正常的執行緒都被停住，從而導致心跳超時。這時要檢視一下對應的gc日誌，看那個時間點附近有沒有fgc；
* worker/task丟擲了未處理的異常，如outofmemoryerror之類的
* 最後也有可能是worker一直沒起來, worker心跳超時
flip close Oops問題排查
1 問題描述 oops 1 cpu 0 0 00000000 00000001 64206e6f 838ceae0 4 838ceae0 83816140 00000001 00000007 8 0000080f 00000004 00000020 83934668 12 82fdb128 ffff...
404問題排查
當tomcat沒有日誌的時候，不一定訪問沒有到達tomcat 我們可以通過web.xml中的filter來攔截請求，把斷點打到第乙個filter smartfilterdispatcher 上，確定請求，然後檢視問題在 resource name add cust topic destination...
GC問題排查
一 使用jps檢視執行緒id 二 使用jstat gc 3331 250 20檢視gc情況，一般比較關注perm區的情況，檢視gc的增長情況。三 使用jstat gccause 額外輸出上次gc原因 四 使用jmap dump format b,file heapdump 3331生成堆轉儲檔案 五...