1. 概述
本文介紹 定時調度任務 中一些報錯及解決方案。
2. 運行監控報錯整理
定時調度任務執行失敗時，「運行監控」的「任務執行明細」中，對應日志右邊會有問号标志。鼠标點擊時會顯示對應的報錯信息。如下圖所示：
本節提供「運行監控」處常見報錯信息及對應原因、排查方法。
2.1 文件名稱過長導緻附件生成失敗
報錯信息：
報錯信息爲Result file creation failed: (附件名稱)，如下圖所示：
這通常會導緻後續附件處理任務時（如郵件發送等）出現找不到文件報錯，或發送的附件大小爲 0kb 等問題。
原因分析：
定時調度任務執行時會生成.cpr、.pdf、.xls等格式的附件，這些附件的文件名來自定時調度任務設置中的「文件名稱」，如下圖所示：
文件名稱這裏可以使用公式，計算後的實際文件名可能超過操作系統對文件名長度的限制（一般爲 255 左右），導緻文件生成失敗。
注：定時調度可以使用的公式請參見：定時調度支持的公式
解決方案：
修改定時調度任務設置，使用更短的文件名稱。
2.2 數據集配置錯誤
報錯信息：
報錯信息爲數據集配置錯誤Query: wait millis xxxxx, active xx, maxActive xxxx，如下圖所示：
原因分析：
定時調度執行模板計算時，需要連接模板用到的數據連接進行取數。當連接超時時，會報上數據集配置錯誤。
解決方案：
在設計器中點擊「服務器>定義數據連接」，選擇該模板使用的數據連接，點擊「連接池屬性」。如下圖所示：
将「最大等待時間」适當調大即可，如果還有相同報錯，考慮繼續調大。若依舊無法解決，建議用戶查看網絡是否有問題。
2.3 定時調度任務超時
報錯信息：
報錯信息爲TimeoutException，如下圖所示：
原因分析：
定時調度任務在執行超過 5 分鍾（默認）時，會有上述提示。上述提示并不會中斷任務執行，如果任務後續執行成功了，會正常記錄成功日志。
解決方案：
超級管理員可通過「fine_conf_entity可視化配置插件」關閉超時提示或者延長超時提示出現的時間。重啓服務器後設置生效。
注：修改 FineDB 數據庫表字段值的方法請參考 FineDB 常用表字段修改 。
| 配置項 | 含義 | 修改規則 |
|---|---|---|
| ScheduleSettingConfig.taskTimeout | 設置定時任務超過時間，默認5分鍾，單位爲毫秒 如果配了 Nginx 等轉發，不可超過 Nginx 内配置的轉發超時時間。 | 參數值需爲正長整型 默認值爲300000 |
| ScheduleSettingConfig.timeoutRemind | 定時調度任務是否開啓監控日志超時提醒 取消超時檢查和提醒後不影響任務本身的執行流程 2020-01-15 及之後的 JAR 支持 | 參數值需爲布爾型，默認爲false false：定時調度任務不開啓監控日志超時提醒 true：定時調度任務開啓監控日志超時提醒 |
2.4 郵件發送報錯
2.4.1 535 Error: authentication failed
報錯信息：
報錯信息爲535 Error: authentication failed，如下圖所示：
原因分析：
連接到 SMTP 服務器的用戶名或密碼錯誤。
解決方案：
核對連接到 SMTP 服務器的用戶名和密碼。注意對於大部分郵箱，SMTP 服務器的用戶名密碼跟登錄郵箱的用戶名密碼不同，一般在郵箱的設置頁面會有配置。
2.4.2 Couldn't connect to host
報錯信息：
報錯信息爲Couldn't connect to host（timeout可能爲其他值），如下圖所示：
原因分析：
因爲網絡原因無法連接到 SMTP 服務器。
解決方案：
檢查配置的 SMTP 服務器地址和端口是否正确且能聯通。可以 ping 地址得到 ip ，然後「telnet ip port」确認能否聯通。
2.4.3 Invalid Addresses
報錯信息：
報錯信息爲Invalid Addresses，如下圖所示：
原因分析：
收件人（或抄送、密送）中含有無效郵箱地址，具體地址也會一同提示，如上圖中的「notexist12345@163.com」。
解決方案：
檢查并删除收件人（或抄送、密送）中的無效郵箱地址。
2.4.4 response: 421
報錯信息：
com.fr.schedule.output.EmailException: javax.mail.MessagingException: Could not connect to SMTP host: SMTP.163.com, port: 25, response: 421；
原因分析：
郵箱服務器地址和端口配置存在問題。
SMTP 主機已達最大聯機數量。
解決方案：
請收信者和郵件管理者确認收信端郵件服務器是否正常作業。
收件者 SMTP 主機拒絕提供服務，因爲已經超過其能提供的最大服務量。可通過提高 SMTP 服務器的頻率或者将任務拆分開來解決。
2.5 郵件發送成功但收不到郵件
報錯信息：
無報錯信息，運行監控中顯示郵件發送成功，但實際沒有收到。
原因分析：
原因一般是 SMTP 服務器投遞的郵件被收件人郵箱拒收了。可以登錄 SMTP 服務對應的郵箱（即「系統管理」中配置的郵箱），檢查是否有退信相關郵件。
解決方案：
根據對應郵箱的退信規則，排查退信原因。
2.6 SMTP 服務器報錯
報錯信息：
定時任務發送郵件，收件人數量較多時，SMTP 服務器報錯，報錯内容中含too many recipients字樣， 如下圖所示：
原因分析：
平台負責将郵件信息（收件人、抄送、密送、主題、正文等）發送給 SMTP 服務器，由 SMTP 服務器根據這些信息發送郵件，平台本身并不進行實際郵件的發送。
造成該報錯的實際原因爲「收件人」或「抄送」或「密送」的郵箱數量超過了 SMTP 服務器的限制，不同的 SMTP 服務器所限制的數量可能不一樣。
解決方案：
方案一：減少默認用戶組中用戶的數量，由於不同的 SMTP 服務器所限制的數量可能不一樣，建議用戶數量在 500 以内。
方案二：提高 SMTP 服務器對收件人的限制，需要客戶方的 SMTP 服務器管理人員做修改，由於不同的 SMTP 服務器修改方式不相同，本文暫不提供修改方法。
3. 其他
3.1 郵件正文空格顯示問題
問題描述：
郵件正文内容中的多個空格被合并爲一個，行首空格不顯示。
解決方案：
郵件正文中若需在行首輸入空格，或在行内連續輸入多個空格時，要将這些空格替換爲同等數量的「 」。如下圖所示：
3.2 結果鏈接無法正常跳轉
問題描述：
設置定時任務發送郵件時，在「郵件通知」中勾選了「正文加上結果鏈接」，點擊郵件中的結果鏈接，出現圖一或圖二的報錯，報錯内容：非常抱歉，您無法查看該頁面，如需訪問請聯系管理員
如下圖所示：
原因分析：
可能是用戶在「調度對象」步驟中勾選了「任務結束即清理」 。
解決方案：
取消勾選「任務結束即清理」，勾選「僅保留最近一次」、「僅保留最近5次」、「不清理」、「自定義」中任意一個即可。
3.3 遷移 FineDB 數據庫後郵件發送失敗
問題描述：
定時任務發送郵件，沒有「運行監控」，也沒有收到短信，後台報錯：
couldn't store job:Packet for query is too large (35045785>4194304).You can change this value on the server by setting the max_allowed_packet' variable.
如下圖所示：
原因分析：
用戶将内置 FineDB 數據庫遷移到本地 MySQL 數據庫中，本地 MySQL 數據庫中「max_allowed_packet」值設置過小導緻單個記錄超過限制後寫入數據庫失敗，且後續記錄寫入也會失敗。
解決方案：
方案一：
MySQL 安裝目錄下的「my.ini」文件中的[mysqld] 字段中的「max_allowed_packet = 1M」修改爲 500M ，重啓 MySQL 即可。
方案二：
1）使用「set global max_allowed_packet = 524288000;」 語句将「max_allowed_packet」的值設置爲 500 M。
2）使用「show VARIABLES like '%max_allowed_packet%';」 語句查看是否修改成功。
3.4 超時報錯
問題描述：
定時調度發送郵件失敗，報錯如下所示：
com.fr.restriction.MemoryAlarmException:很抱歉，sql 執行時間過長觸發保護機制，請稍後重試。若您是管理員，可於智能運維-内存管理-模板限制中更改此項限制。
解決方案：
關閉所有 模板限制
3.5 郵件結果鏈接 URL 以 localhost 開頭
問題描述：
定時調度任務「文件處理」步驟中，處理方式選擇「郵件通知」，「郵件内容設置項」中勾選「正文加上結果鏈接」。收到的郵件點擊結果鏈接，鏈接 URL 以localhost開頭。如下圖所示：
用戶希望localhost轉成實際 IP 。
解決方案：
1）将數據決策系統的 URL 改成實際 IP ，例如：http://ip:端口/工程名/decision，如下圖所示：
2）在平台新建定時調度任務或重新編輯保存之前任務，點擊郵件中的結果鏈接，鏈接 URL 開頭改變。如下圖所示：
3.6 定時調度任務總是提前/延後固定小時數執行
問題描述：
定時調度任務總是提前/延後數小時執行，且該值恒定，常見的爲 8 小時等。
原因分析：
首先排查 FineDB 所在機器時區是否正确，Windows 則在命令提示符下使用tzutil /g，回顯China Standard Time則爲正常，Linux 則在 Bash 下使用date -R，回顯中包含 +0800 則爲正常。
其次排查平台工程所在機器時區是否正确，方法同上。
最後排查平台所在工程 JVM 時區是否正确，可新建類 Test ，内容爲下述代碼，編譯成Test.class文件上傳至平台工程所在機器，執行java Test，若回顯Asia/Shanghai則爲正确。
import java.util.TimeZone;
public class Test{
public static void main(String[] args) {
System.out.println(TimeZone.getDefault());
}
}
上述回顯的具體時區，以客戶實際所在時區爲準。
解決方案：
若機器時區不正确，則聯系客戶修改系統時區。
若 JVM 時區不正确，則需要添加-Duser.timezone=Asia/Shanghai的 JVM 啓動參數：如果是 Tomcat 等容器啓動，則添加至容器的JAVA_OPTS位置，與設置内存大小的 -Xmx/-Xms 位置相同；如果是設計器/安裝版 BI 直接啓動，在啓動器同目錄下有designer.vmoptions或finebi.vmoptions，将上述參數添加至其中即可。
