※ 引述《ggg12345 (ggg)》之銘言：
: 這個error message在google網上看見的就類似這種訊息:
: <WebLogicServer> <BEA-000337> <[STUCK] ExecuteThread: '4' for queue:
: 即使是 2014 2月 照樣有這種訊息在發問.
: 這個message說法就是某個thread 在queue 呆太久, 超過設定的default 時限.
: 這現象就是接近教科書說的 dead lock. 最簡單解法就是 "人工進入"宰掉重跑.
可能是我不太懂的關係, 不過我只有在DB的運作裡聽過dead lock......
戶政系統的狀況是到200 or 250 的時候, 所有的thread 除了I/O socket以外
全部都變成block or wait......至於是200還是250 我還沒有確切的消息, 而這個
狀況是kill process也解不了的.
: 對系統管理員是這樣子靠他來救.
: 這種錯是系統分析者的失誤沒考慮到. 但若是太大塊的分工, 寫程式的負責這個
: 功能與算法, 那就是寫程式的寫出錯誤的狀況.
: 再怎麼說, 這就是通稱不知何時何處會冒出問題的 爛code.
: 從2月之後的報導, 都是這現象. 申請者與戶政服務人員等得天荒地老還不來!
: : 我倒不覺得架構有問題, 戶役政系統的Bussiness Logic 也不會牽涉到算法的問題
: : 純粹是PM 不OK 沒有進行適當的風險規避以及沒有足夠的經驗判斷問題點.
我還是不覺得系統分析需要對這一塊負責. 系統分析負責做流程跟架構, 這塊
本來就是PM要請系統工程師進行相容性測試的.
: 新系統與舊系統的差別就反應在最近一系列新公布的規章上.
: 以結婚/離婚為例, 兩造帶了證件, "同時人到" "任一個戶政所" 都可辦理.
: 在人工的時代, 女方會先拿證件就其地遷出戶籍, 再拿到夫家戶政所入籍, 同
: 時依結婚證書登錄雙方關係, 同時更新戶口謄本與身份證.
: 在電子化之後, 各地形成了分散式資料庫. 理論上, 人工的遷移戶口用男方所
: 在地的戶政區公所的電子公文對女方所在地請求遷出, 並傳送戶籍謄本, 就能
: 遠地辦到. 但不論是否集中避免遠近的通訊延遲, 按地區建檔的資料庫還是可
: 以分區做data parallel的分queue各自處理.
電子化以後其實並沒有形成分散式資料庫. 就我所知原來的系統是在離峰時間
跟中心的資料庫進行資料的抄寫. 當然可能有註記的問題. 這一塊可能是用人工調整的
不過起碼在台北市這邊, 戶口的遷移是在遷出地或遷入地任何一方辦理即可. 如印鑑證
明等業務更是在臺北市內任一戶政事務所辦理即可.
: 不過, 這涉及請求與批准的權限, 直白一點就涉及"越權"與"入侵". 因此, 由
: 內政部統一發號施令是可避免一堆點對點的來往.
: 新系統顯然是集中單一權限的概念. 婚姻的登錄規章顯然因新的戶警分立與外
: 配而改了. 事情變成在任何戶政所都能登錄與更改身份證, 但最近新婚的需要
: 雙方同時到場驗證. 在某種程度上, 可能這是防止一夫配多妻的狀況發生.
: 手工時代, 本來從任何一方戶政所憑結婚證書與戶籍謄本, 就可以請求更改身
: 份證的配偶欄位記錄.
: 那時是很單純的.譬如女方, 1.查證 男女證書/原謄本記錄. 2.調出女戶籍原本
: 更新. 3.更新女謄本/身份證.
其實我猜測新系統涵蓋舊系統的流程操作部分, 可能直接用Java包4GL就直接做掉了
裡面的procedure甚至可能直接用原來的4GL
不過這個我完全沒有根據. 只是很好奇新系統幹嘛用informix.
戶政作業流程不是電腦改就可以改的, 內政部這邊要先修改作業辦法、作業細則,
報行政院院會通過, 公佈以後才能修改. 所以我覺得可以不用扯到戶政的作業流程去,
只需要討論戶政系統的作業方式就好.
: 底下這是猜測的一個可能沒分析寫好造成dead lock的一個可能情形.
: 1.查證男女證書 2.向內政部發出配偶欄更新申請. 3.內政部通知更新男女方.
: 3a-1.男方戶政機查閱男方, 女方資料庫戶籍, 並企圖鎖住更新.3a-2.更新男方.
: 3b-1.女方戶政機查閱女方, 男方資料庫戶籍, 並企圖鎖住更新.3b-2.更新女方.
: 最明顯的dead lock 就是互相先等待對方發不了的信息.
: 3a-1開了男方,尚未拿到女方. 但同時3b-1卻已開了女方, 正等待男方. 雙方僵持
: 直到 default time-limit, 再由3.內政部 重新發出通知.
: 因為資料集中, 無法怪罪網路延遲, 通知更新的雙方很快又同時發生, 就等
: time-out 再重來.
: 如果 男女方戶政機因不同負載有一方延遲, 就有可能不會互鎖, 就可能過關.
: 這就形成了time-dependent error, 時有時無, 很難正確查覺.
這個例子可能過於簡單, 不過我承認在某些constrain下, 這是有可能造成dead lock
的. 只是這個dead lock 只會影響相關的資料, 不會在concurrent 250U的狀況下
造成system hang..
: 人工時代需要調閱戶籍謄本, 這是一個read-only 的 copy, 所以分散各地的戶政
: 所可以透過 預取的 read-only copy 各自平行處理, 不容易出這種錯.
: 以上純屬想像狀況. 目前的新系統顯然是有 許多新法規 要求要配合. 問題應該是
: 由這些新狀況引發的.
承上, 我不覺得實際狀況是這樣.
: ========
: 再說, 如果一個系統寫得很好, system admin 可能就沒事彰顯其重要性, 在這裁
: 員精簡的時代, BEA-000337 message 的發生, 可以保證增加幾個重要職缺.
公家機關基本上無此可能. 就算無給職也不可能.
: : 至於分散式平行處理, 坦白說, 基本上台灣都是在local site處理, 沒有人在
: : metro-wide做分散式平行處理. 光network latency就會造成不輸給這次事件的delay
: → lovdkkkk:Thread.sleep(99999999); <-- dead lock? 03/18 14:59
: → saitoh:如果不知道wls判斷stuck thread的條件是什麼就不要亂猜了 03/18 15:14
: → alan3100:..我覺得直接找原文書來貼都比你在那解釋還清楚 03/18 15:17
: stuck 未必來自dead lock, 但只要呆太久超過default值都會出此訊息.
: 那堆戶政機, 在新規範要求相互查核驗證下, 是會互動回饋的, 機會就有.
: 推 asdfghjklasd:問題你想拿學分還要他簽名.. 03/18 15:36
: → gogohata:thread呆太久跟deadlock情況不一樣吧 03/18 15:40
: ※ 編輯: ggg12345 來自: 114.43.229.178 (03/18 15:56)
: → Lordaeron:WL的thread stuck只表示它的THREAD停很久,致於哪個 03/18 16:07
: → Lordaeron:thread為何停這麼久,要看寫的人在寫什麼.跟WL無關. 03/18 16:07
: → Lordaeron:簡單的說,你愛寫一個SLEEP/WAIT 100分鐘的,WL也管不著 03/18 16:25
: 推 luciferii:沒用過WebLogic但是看一行訊息就能斷古論今，不愧是教授 03/19 17:03
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 1.34.160.27