排程管理常見問題

排程管理任務執行失敗時，「運作監視」的「任務執行明細」中，對應日誌右邊會有問號標籤。滑鼠點選時會顯示對應的報錯資訊。如下圖所示：

本文將介紹 排程管理任務 中一些報錯及解決方案。

報錯資訊：

報錯資訊為Result file creation failed: (附件名稱)，如下圖所示：

這通常會導致後續附件處理任務時（如郵件傳送等）出現找不到檔案報錯，或傳送的附件大小為 0kb 等問題。

原因分析：

排程管理任務執行時會生成.cpr、.pdf、.xls等格式的附件，這些附件的檔案名稱來自排程管理任務設定中的「檔案名稱稱」，如下圖所示：

檔案名稱稱這裏可以使用公式，計算後的實際檔案名稱可能超過作業系統對檔案名稱長度的限制（一般為 255 左右），導致檔案生成失敗。

注：排程管理可以使用的公式請參見：排程管理支援的公式

解決方案：

修改排程管理任務設定，使用更短的檔案名稱稱。

3.1 Query: wait millis xxxxx, active xx, maxActive xxxx

報錯資訊：

報錯資訊為資料集配置錯誤Query: wait millis xxxxx, active xx, maxActive xxxx，如下圖所示：

原因分析：

排程管理執行範本計算時，需要連結範本用到的資料連結進行取數。當連結逾時時，會報上資料集配置錯誤。

解決方案：

在設計器中點選「伺服器>定義資料連結」，選擇該範本使用的資料連結，點選「更多設定」。如下圖所示：

將「最大等待時間」適當調大即可，如果還有相同報錯，考慮繼續調大。若依舊無法解決，建議使用者查看網路是否有問題。

3.2 Already too many clients

報錯資訊：

報錯資訊為ERROR：dn_6003_6004：[FATAL]Already too many clients，如下圖所示：

原因分析：

排程管理任務對很多使用者單獨生成結果，呼叫範本時產生的資料連結數過多，超出了最大連結數限制，資料庫壓力過大導致排程管理任務失敗。

解決方案：

超級管理者可透過「fine_conf_entity視覺化配置插件」修改排程管理模組最大執行緒數和最大連結數，減小資料庫的併發壓力。

• QuartzConfig.threadCount 的參數值改為 10，定時任務同時執行的執行緒數將受到限制。

• QuartzConfig.maxConnections 的參數值改為 5，限制最大連結數。

重啟伺服器後設定生效。

注：修改 FineDB 資料庫表欄位值的方法請參考 FineDB 常用表欄位修改 。

報錯資訊：

報錯資訊為TimeoutException，如下圖所示：

原因分析：

排程管理任務在執行超過 5 分鐘（預設）時，會有上述提示。上述提示並不會中斷任務執行，如果任務後續執行成功了，會正常記錄成功日誌。

解決方案：

超級管理者可透過「fine_conf_entity視覺化配置插件」關閉逾時提示或者延長逾時提示出現的時間。重啟伺服器後設定生效。

注：修改 FineDB 資料庫表欄位值的方法請參考 FineDB 常用表欄位修改 。

5.1 535 Error: authentication failed

報錯資訊：

報錯資訊為535 Error: authentication failed，如下圖所示：

原因分析：

連結到 SMTP 伺服器的帳號或密碼錯誤。

解決方案：

覈對連結到 SMTP 伺服器的帳號和密碼。注意對於大部分信箱，SMTP 伺服器的帳號密碼跟登入信箱的帳號密碼不同，一般在信箱的設定頁面會有配置。

5.2 Couldn't connect to host

報錯資訊：

報錯資訊為Couldn't connect to host（timeout可能為其他值），如下圖所示：

原因分析：

因為網路原因無法連結到 SMTP 伺服器。

解決方案：

檢查配置的 SMTP 伺服器地址和埠是否正確且能聯通。可以 ping 地址得到 ip ，然後「telnet ip port」確認能否聯通。

1）首先確認所填寫的郵件伺服器地址和埠都是正確的，並且傳送測試郵件。如果測試郵件都無法成功傳送，說明郵件伺服器有問題。請去郵件使用者端再次確認下。

2）如果郵件伺服器測試傳送郵件成功，但是偶爾還是有任務失敗，報錯相同，可能原因是當時網路不通暢，連結不上郵件伺服器。

3）或者是信箱伺服器的併發過大，導致伺服器處於無法迴應的狀態，進而連結不上伺服器。

要麼提高信箱伺服器的效能，要麼將工程傳送郵件的任務時間間隔開，不要併發到一個時間段。

5.3 Invalid Addresses

報錯資訊：

報錯資訊為Invalid Addresses，如下圖所示：

原因分析：

收件人（或複本、密送）中含有無效信箱地址，具體地址也會一同提示，如上圖中的「notexist12345@163.com」。

解決方案：

1）檢查並刪除收件人（或複本、密送）中的無效信箱地址。

2）若定時任務中有很多收件人，排查較困難，可以勾選「根據使用者單獨生成結果」。

在運作監視資訊中可以看到只有無效的收件人會失敗，其他正常使用者會傳送成功，將無效的收件剔除或修改正確即可。

5.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 伺服器的頻率或者將任務拆分開來解決。

5.5 com.sun.mail.smtp.SMTPSendFailedException: 554

報錯資訊：

com.sun.mail.smtp.SMTPSendFailedException: 554

原因分析：

郵件伺服器將郵件當成了垃圾郵件。

解決方案：

由於每個信箱都有反垃圾郵件的功能，規則各有不同。

1）首先建議點開信箱的「垃圾箱」，找回郵件。

2）將寄件人的信箱地址新增到信箱的「通訊錄」中，以防被誤判成垃圾郵件。

5.6 Message size exceeds fixed

問題描述：

排程管理傳送郵件，附件大於2M時郵件傳送失敗，日誌報錯：Message size exceeds fixed

原因分析：

信箱伺服器限制了附件大小

解決方案：

請根據你的信箱類型，自行百度修改信箱配置

報錯資訊：

定時任務傳送郵件，收件人數量較多時，SMTP 伺服器報錯，報錯內容中含too many recipients字樣， 如下圖所示：

原因分析：

平台負責將郵件資訊（收件人、複本、密送、主題、正文等）傳送給 SMTP 伺服器，由 SMTP 伺服器根據這些資訊傳送郵件，平台本身並不進行實際郵件的傳送。

造成該報錯的實際原因為「收件人」或「複本」或「密送」的信箱數量超過了 SMTP 伺服器的限制，不同的 SMTP 伺服器所限制的數量可能不一樣。

解決方案：

方案一：減少預設使用者組中使用者的數量，由於不同的 SMTP 伺服器所限制的數量可能不一樣，建議使用者數量在 500 以內。

方案二：提高 SMTP 伺服器對收件人的限制，需要客戶方的 SMTP 伺服器管理人員做修改，由於不同的 SMTP 伺服器修改方式不相同，本文暫不提供修改方法。

報錯資訊：

無報錯資訊，運作監視中顯示郵件傳送成功，但實際沒有收到。

原因分析：

原因一般是 SMTP 伺服器投遞的郵件被收件人信箱拒收了。可以登入 SMTP 服務對應的信箱（即「系統管理」中配置的信箱），檢查是否有退信相關郵件。

解決方案：

根據對應信箱的退信規則，排查退信原因。

報錯資訊：

信箱類型為 Outlook 信箱，報錯：STOREDRV.ClientSubmit; sender thread limit exceeded

原因分析：

Microsoft 限制同時間只支援 3 條執行緒併發傳送郵件，超過 3 條則會丟擲以上異常，Outlook的信箱預設會有這個限制。

10.0 排程管理的信箱傳送郵件是多執行緒的，所以可能會出現執行緒超出3的情況。

解決方案：

JAR 包版本在 2019-08-16 之後的報表伺服器，超級管理者可透過「fine_conf_entity視覺化配置插件」修改排程管理模組最大執行緒數。

按照 Microsoft 的限制，把 QuartzConfig.threadCount 的值改為 3 或小於 3 ，就可以避免排程管理由於執行緒超出而失敗。

重啟伺服器後設定生效。

注：修改 FineDB 資料庫表欄位值的方法請參考 FineDB 常用表欄位修改 。

問題描述：

郵件正文內容中的多個空格被合併為一個，行首空格不顯示。

解決方案：

郵件正文中若需在行首輸入空格，或在行內連續輸入多個空格時，要將這些空格更換為同等數量的「 」。如下圖所示：

問題描述：

設定定時任務傳送郵件時，在「郵件通知」中勾選了「正文加上結果連結」，點選郵件中的結果連結，出現圖一或圖二的報錯，報錯內容：非常抱歉，您無法查看該頁面，如需存取請交握管理者

如下圖所示：

原因分析：

可能是使用者在「調度物件」步驟中勾選了「任務結束即清理」 。

解決方案：

取消勾選「任務結束即清理」，勾選「僅保留最近一次」、「僅保留最近5次」、「不清理」、「自訂」中任意一個即可。

問題描述：

定時任務傳送郵件，沒有「運作監視」，也沒有收到簡訊，後臺報錯：

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%';」 語句查看是否修改成功。

問題描述：

1）排程管理任務手動執行正常，比如立即執行一次這種，還有剛建立任務立即執行也正常。

2）排程管理任務定時執行，偶爾不執行或一直不執行，但任務下次執行時間正常變化。

3）排程管理任務定時執行，郵件傳送成功，但是附件為 0kb。

4）在運作監視中不存在排程管理任務未執行的時間點記錄，後臺日誌也不見該時間點的日誌和報錯。

5）排程管理任務設定了開始時間，但在開始時間後任務停止且沒有繼續任務的按鈕，或者偶爾執行成功，但再次點選執行時會提示任務已被刪除。

原因分析：

多個工程連結了同一 FineDB 資料庫，導致排程管理的定時執行，可能執行到其他工程上去了。

排查步驟：

1）排查有幾臺機器連結着平台的FineDB資料庫

使用對應SQL語句查詢有幾臺機器連結了 finedb 資料庫，當有多個機器連結時，排查下其他機器上是否也有部署工程。

• MySQL：

select * from information_schema.processlist where DB like '%遷移的資料庫名%';

• Oracle：

select sid,serial#,username,program,machine,terminal,osuser,process,client_info from v$session where username is not null order by username,program,machine;

• SqlServer：

select t2.name, t3.client_net_address, t1.host_name, t1.login_time, t1.status, t1.last_request_start_time from master.sys.dm_exec_sessions t1 inner join master.dbo.SYSDATABASES t2 on t1.database_id=t2.dbid inner join master.sys.dm_exec_connections t3 on t1.session_id=t3.session_id where t2.name = '資料庫名';

2）排查該機器下是否有多個運作着平台的容器

使用ps -ef | grep java檢查伺服器下是否有多個容器開啟了報表工程，若有，則一一排查對應的 finedb 資料庫

3）排查虛擬目錄配置情況

僅限Tomcat、Resin等可以配置虛擬目錄的容器。

webapps 下的 webroot 項目會被 tomcat 自動啟動，如果又配了虛擬目錄指向這個 webroot，就會被啟動 2 次。

• conf/server.xml裏搜一下Context，看有沒有docBase指向webroot的Context。

• conf/Catalina/localhost下有沒有指向webroot的xml檔案。

問題描述：

排程管理傳送郵件失敗，報錯如下所示：

com.fr.restriction.MemoryAlarmException:很抱歉，sql 執行時間過長觸發保護機制，請稍後重試。若您是管理者，可於智慧維運-記憶體管理-範本限制中更改此項限制。

解決方案：

關閉所有 範本限制

問題描述：

排程管理任務「檔案處理」步驟中，處理方式選擇「郵件通知」，「郵件內容設定項」中勾選「正文加上結果連結」。收到的郵件點選結果連結，連結 URL 以localhost開頭。如下圖所示：

使用者希望localhost轉成實際 IP 。

解決方案：

1）將數據決策系統的 URL 改成實際 IP ，例如：http://ip:埠/工程名/decision，如下圖所示：

2）在平台建立排程管理任務或重新編輯儲存之前任務，點選郵件中的結果連結，連結 URL 開頭改變。如下圖所示：

問題描述：

排程管理任務總是提前/延後數小時執行，且該值恆定，常見的為 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，將上述參數新增至其中即可。

問題描述：

JAR 包為 2019-09-27 之後的 FineReport 設計器，在其決策平台上建立排程管理任務，如果再將 JAR 包回退到之前版本（2019-05-20 至 2019-09-27，包括 2019-09-27 ），不重新執行此排程管理任務查看之前執行時掛載的結果連結，圖表不可見，如下圖所示：

解決方案：

已回退到的版本再次執行此任務，生成新結果連結，可查看圖表。

注：不建議使用者回退，由於版本間不向上相容，回退後可能會出現一些問題。

2020-06-08 及之後的 JAR 中，排程管理任務配置完成後，在 使用者管理 中刪除 基本設定 步驟「預設使用者組」中的使用者、角色、部門、職務，再次執行排程管理任務，fanruan.log日誌檔案中顯示error級別報錯提醒。

具體報錯邏輯如下表所示：

注：fanruan.log 日誌檔案儲存路徑為：%FR_HOME%\logs

注：「自訂使用者」介紹請參見：基本設定

問題描述：

排程管理執行失敗，錯誤日誌：java.lang.RuntimeException: 存在報表塊或圖表重疊，匯出失敗。

原因分析：

排程管理推播決策報表時，如需匯出附件，是按照決策報表匯出邏輯匯出的。即將決策報表所有組件轉換到複合式報表，最終藉助複合式報表匯出。

因此，當前決策報表匯出所不支援的功能，在排程管理推播決策報表時同樣不支援。

排程管理推播決策報表附件時，如果決策報表存在組件互相重疊，則無法轉換到複合式報表，並藉助複合式報表匯出，也因此排程管理失敗。

解決方案：

調整決策報表組件間隔，確定不發生重疊。

問題描述：

排程管理時範本web屬性設定的自訂事件不生效，例如設定的定時填報，發現範本web屬性設定的填報成功事件沒有執行。

原因分析：

排程管理目前不會觸發範本web屬性設定的自訂事件。

解決方案：

調整範本設定，尋找替代方案。

問題描述：

排程管理所呼叫的決策報表範本，使用的自適應佈局，直接預覽時也可以正常自適應展示。

但是透過排程管理生成的結果報表檔案，不自適應，範本存在空白間隙，存在各種捲軸。

原因分析：

排程管理結果報表檔案是按固定大小匯出的，所以會出現捲軸，有空白。

解決方法：

在排程管理檔案處理裏，用連結的形式查看範本，而不要直接查看生成的結果報表檔案。

報錯資訊：

報錯資訊為Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation '='

原因分析：

MySQL 資料庫中資料表的編碼方式不一致，在取數後無法進行比較，導致定時任務執行失敗。

解決方案：

將 MySQL 資料庫以及資料表的編碼統一修改為 uft8。

1）檢查 MySQL 資料庫的編碼和排序規則。

查看字元集：SHOW VARIABLES LIKE 'character%';

查看排序方式：SHOW VARIABLES LIKE 'collation_%';

2）若 MySQL 資料庫的字元集編碼為非 uft8，透過以下步驟修改字元集編碼：

修改 MySQL 的 my.ini 檔案中的字元集鍵值。

default-character-set = utf8 character_set_server = utf8

修改完後，重啟 MySQL 的服務

service mysql restart

使用命令查看，發現資料庫編碼均已改成 UTF-8。

mysql> SHOW VARIABLES LIKE 'character%';

3）資料庫編碼正常的情況下，檢查資料表中所有列的編碼和排序規則。

show full COLUMNS from 表名; 

4）檢查出異常編碼的資料表後，修改編碼為 utf8 即可。

ALTER TABLE `表名` CONVERT TO CHARACTER SET utf8;

問題描述：編輯、新增、刪除、執行排程管理任務，沒有任何反應，提示任務新增失敗

原因分析：排程管理的get請求被攔截

解決方案：檢查防火牆，釋放請求