Quartz recovery 及misfired機制的原始碼分析
首先要明確的是：quartz如果在執行具體任務時，在任務執行過程中丟擲異常，那麼不作任何處理，這是使用者程式本身的問題，不需要框架處理。
下面介紹quartz中的兩大類異常情況：
misfired 啞火（*注：筆者自己直譯）
fail-over 故障轉移
1.misfired 啞火
啞火顧名思義，就是quartz在應該觸發（fire）trigger的時候未能及時將其觸發，這將導致trigger的下次觸發時間落在當前時間之前，那麼按照正常的quartz排程流程，該trigger就再也沒有機會被排程了。由於一個排程器例項在每次排程的過程中都會有一定的睡眠時間，存在在一段時間內所有排程器例項都在睡眠，而無人觸發排程的潛在可能。於是排程器需要每隔一段時間（15s~60s）檢視一次各trigger的nextfiretime，檢查出否有tirgger的下一次觸發落在了當前時間之前足夠長的時間，在這裡系統設定了一個60s的域（misfireThreshold），當一個trigger的下一次觸發時間早於當前時間60s之外時，排程器判定該觸發器misfired，在發現有觸發器啞火之後啟動相應的流程回覆trigger至正常狀態。上述這些過程是在排程器初始化時與主排程執行緒類quartzSchedulerThread同時開啟的一個執行緒類MisfireHandler中進行的。
下面是quartz檢測misfired的邏輯：
protected RecoverMisfiredJobsResult
doRecoverMisfires() throws JobPersistenceException
{
boolean transOwner
= false;
Connection
conn = getNonManagedTXConnection();
try {
RecoverMisfiredJobsResult
result = RecoverMisfiredJobsResult.NO_OP;//
Before we make the potentially expensive call to acquire the
//
trigger lock, peek ahead to see if it is likely we would find
//
misfired triggers requiring recovery.
//統計啞火
trigger的個數
int misfireCount
= (getDoubleCheckLockMisfireHandler()) ?
getDelegate().countMisfiredTriggersInState(conn,
STATE_WAITING, getMisfireTime()) :
Integer.MAX_VALUE;
//沒有啞火trigger，do
nothing
if (misfireCount
== 0)
{
getLog().debug(
"Found
0 triggers that missed their scheduled fire-time.");
} else {
transOwner
= getLockHandler().obtainLock(conn, LOCK_TRIGGER_ACCESS);
//檢查到有啞火的tirgger，啟動recovery程式，處理啞火trigger
result
= recoverMisfiredJobs(conn, false);
}
commitConnection(conn);
return result;
} catch (JobPersistenceException
e) {
rollbackConnection(conn);
throw e;
} catch (SQLException
e) {
rollbackConnection(conn);
throw new JobPersistenceException("Database
error recovering from misfires.",
e);
} catch (RuntimeException
e) {
rollbackConnection(conn);
throw new JobPersistenceException("Unexpected
runtime exception: "
+
e.getMessage(), e);
} finally {
try {
releaseLock(LOCK_TRIGGER_ACCESS,
transOwner);
} finally {
cleanupConnection(conn);
相關推薦Quartz recovery 及misfired機制的原始碼分析首先要明確的是：quartz如果在執行具體任務時，在任務執行過程中丟擲異常，那麼不作任何處理，這是使用者程式本身的問題，不需要框架處理。 下面介紹quartz中的兩大類異常情況： misfired 啞火（*注：筆者自己直譯） fail-over 故障轉移 1.misfired 10.深入k8s：排程的優先順序及搶佔機制原始碼分析> 轉載請宣告出處哦~，本篇文章釋出於luozhiyun的部落格：https://www.luozhiyun.com > > 原始碼版本是[1.19](https://github.com/kubernetes/kubernetes/tree/release-1.19) 類載入器 Andrid View事件分發機制原始碼分析Android 的view樹結構大家都清楚，但是事件序列是經過一個怎樣的處理路徑那。今天就帶著疑問來看看原始碼，去尋找答案。 首先我們先看事件如何從Activity開始分發。 public class Activity extends ContextThemeWrapper Android事件分發機制原始碼分析之Activity篇在之前的事件分發分析中，曾提及到View的事件是由ViewGroup分發的，然而ViewGroup的事件我們只是稍微帶過是由Activity分發的。而我們知道，事件產生於使用者按下螢幕的一瞬間，事件生成後，經過一系列的過程來到我們的Activity層，那麼事件是怎樣從Activity傳遞 rest-framework的APIview原始碼分析，Serializer及解析器原始碼分析rest-framework 1.安裝 方式一：pip3 install djangorestframework 方式二：pycharm圖形化介面安裝 方式三：pycharm命令列下安裝（裝在當前工程所用的直譯器下） 2.djangorestframework的APIVi 以太坊p2p網路(五)：P2P模組TCP連線池網路通訊機制原始碼分析上節中通過設定靜態節點BootstrapNodes節點來發現更多全網的其他節點，這部分只是發現節點並找出其中可以ping通的節點，但是還沒有進行使用，還沒建立TCP連線進行資料傳輸，協議處理等。 這裡主要分析P2P系統的TCP連線池的建立，以及是怎麼跟其他節點通 Handler機制原始碼分析經常使用Handler進行子執行緒和UI執行緒的通訊。例如：子執行緒處理資料，通過Handler切換到UI執行緒更新對應UI。 出於對Handler的好奇和知識的渴望，所以研究了一下Handler相關的原始碼。 在講解原始碼之前，應該先了解一下：Handler、 jQuery 事件機制原始碼分析1——jQuery事件機制整體架構之前在網上搜索過一些內容大多都是寫的零散寫出一些方法感覺不是很系統，要不就是文不對題，後來自己debug 一番大概搞清楚了，決定寫個文章記錄下來。 需要說明的有以下幾點： 1 本文不會教你如何使用.on .off .trigger 等方法 2 基於原始碼分析基於 Activiti 流程啟動及節點流轉原始碼分析本文主要是以activiti-study中的xiaomage.xml流程圖為例進行跟蹤分析 具體的流程圖如下： 流程圖對應的XML檔案如下： <?xml version="1.0 Android App啟動時Apk資源載入機制原始碼分析在Andorid開發中我們要設定文字或圖片顯示，都直接通過Api一步呼叫就完成了，不僅是我們工程下res資源以及系統自帶的framwork資源也可以，那這些資源打包成Apk之後是如何被系統載入從而顯示出來的呢。 這裡我要從Apk安裝之後啟動流程開始講起，在桌面 Android Apk資源載入機制原始碼分析以及資源動態載入實現系列文章Android系統中執行Apk時是如何對包內的資源進行載入以及我們開發中設定相關資源後又是如何被加載出來，這個系列我們可以學習系統載入資源的機制原理，然後我們再巧妙的利用學習系統載入技巧來打造我們自己的動態資源載入機制實現。 這個系列主要分為如下3部分內容來講 資源排程機制原始碼分析（schedule方法，兩種排程演算法）sparkContext初始化後會註冊Application，然後會呼叫schedule方法，如何為Application在worker上啟動Executor，Executor啟動後，DAGScheduler和TaskScheduler才能分配task給Executor來進行 Master原理剖析與原始碼分析：資源排程機制原始碼分析（schedule()，兩種資源排程演算法）1、主備切換機制原理剖析與原始碼分析 2、註冊機制原理剖析與原始碼分析 3、狀態改變處理機制原始碼分析 4、資源排程機制原始碼分析（schedule()，兩種資源排程演算法） * Dri Android非同步訊息處理機制原始碼分析宣告：本文是參考了以下幾位大神的文章，自己按照自己的思維習慣整理的筆記，並新增一些相關的內容。如有不正確的地方歡迎留言指出，謝謝！ 郭霖部落格 鴻洋部落格 任玉剛《Android開發藝術探索》 一. Andoid訊息機制概述 Android IPC 通訊機制原始碼分析 一Android IPC 通訊機制原始碼分析----Albertchen Binder通訊簡介： Linux系統中程序間通訊的方式有:socket, named pipe,message queque, signal,share memory。Java系統中的程序間通訊方式有socket, named Android 訊息機制原始碼分析我們知道，當應用啟動的時候，android首先會開啟一個主執行緒，主執行緒管理ui控制元件，進行事件分發，當我們要做一個耗時的操作時，如聯網讀取資料，獲取讀取本地較大的檔案的時候，你應該在子執行緒中操作，因為有ui的更新，android主執行緒是執行緒不安全的，如果將更新介 Android如何在應用層進行截圖及截圖原始碼分析（下）首先，那麼如果朋友你只是來找截圖介面使用在你的專案中的，那麼你就不用繼續往下看了。。。 基於上班時間較忙，另外個人覺得還是將這個截圖流程分析和使用分開總結比較好，於是決定分兩篇文章來講解。好了，那麼上一篇文章主要是從原始碼角度分析講解了Android系統截圖流 Android Handler機制原始碼分析1)Looper: 一個執行緒可以產生一個Looper物件，由它來管理此執行緒裡的MessageQueue(訊息佇列)。 2)Handler: 你可以構造Handler物件來與Looper溝通，以便push新訊息到MessageQueue裡;或者接收Looper從Messa Handler訊息機制原始碼分析public static final Looper myLooper() { return (Looper)sThreadLocal.get(); } 先來個Handler執行過程的總結： 1、 Looper.prepare()方法 |