佔著茅坑不拉屎，排隊的人急到死

DeadLock 死結，發生的條件基本上就是有限的資源共用，同時多個事件並行等等，最終資源耗盡只能等待事件完成釋放，而事件等待新的資源發放。這個是Jenkins常發生的逾時情況之一，解法就只能對事件進行仲裁。

我對Jenkins最納悶的問題：Jenkins預設沒有逾時設定，但發生逾時確很頻繁？

本篇同步發表於：http://www.gibar.co/2014/10/jenkins-build-timeout-plugin.html

當然資源競爭的問題無法請Jenkins解決，也不能期待GC解決。而且造成逾時的問題，還有像網路環境不穩定、機房乖乖過期等。但是造成的結果有一點是相同的，後面多的人在排隊呢！我們可以先看看一個有趣的單位，目前他們 Hudson(Jenkins)運行的情況。

https://hudson.jboss.org/hudson/ 以下是寫這篇文章時的取材狀態

10天前開始，這是什麼巫術阿

排隊的在幹嘛阿？在等阿！前面的到底要不要出來阿！？

還好Jenkins的外掛很厲害，作業逾時這種基本需求，肯定有外掛可用，就是Build-timeout Plugin。我們可以利用Build-timeout，來定義各種可能是造成逾時的情況，來中止作業佔用資源無限等待。

本篇相關外掛

• Build-timeout Plugin

目標情境

我們要模擬幾種逾時的情況，測試驗證 Build-timeout 是否有正常運作

第一步：認識build-timeout 設定內容

安裝build-timeout後，設定會出現在各個專案的組態設定中

Time-out strategy 逾時模式

• Absolute 在指定的時間內沒有完成就算逾時，但設定不可少於三分鐘
• Elastic 提取先前建置成功時間平均數，當超過150% ~ 400%時算逾時，或超過指定的上限值，無論計算結果為何，逾時最小值為是三分鐘
• Likely stuck 好像卡住了？定義不明確不建議使用。
• No Activity 畫面的輸出靜止超過指定秒數，視為逾時

Time-out actions 逾時處理

• Abort the build 取消建置
• Fail the build 建置失數，會觸發各種失敗時的事件，建議使用

第二步： 測試 Absolute模式 + Fail the build

測試的方法很簡單，我們只會使用兩個SHELL指令，

• echo 輸出內容
• sleep 等待指定的秒數

測試內容，指定超過3分鐘時算逾時，並用sleep模擬200秒的等待。

第三步：測試 Elastic + Abort the build

我們先用sleep指令，做出三次平均90秒的成功建置。指定超過平均150%算逾時，再模擬185秒的等待，反應的結果要為取消建置。

第四步：測試No Activity+Abort the build

指定超過30秒沒有輸出，就算逾時，測試15秒/25秒/35秒各輸出一次，應該要在35秒出現中止。

作業逾時強制中止作業，只是為了讓系統不要全面性停工的手段。如果作業有資源超用的情況，應該還是要用其它手段來防治。例如讓高資源需求的作業到指定的slave進行。或是將他們的排程時間安排於不同時段進行。

中止作業很簡單，很爆力，很強大。但如果被中止作業很重要，我們也要想辦法重新讓他再運行一次。重試，就是中止最佳配套方案，但要注意必需是要有限的重試。

下一篇：砍掉重練 - 我總是相信下一次就會好了

本篇同步發表於：http://www.gibar.co/2014/10/jenkins-build-timeout-plugin.html