排程管理常見問題

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

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

1. 報錯資訊：報錯資訊為【Result file creation failed: (附件名稱)】。

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

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

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

5. 解決方案：修改排程管理任務設定，使用更短的檔案名稱稱。

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

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

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

3. 解決方案：在設計器中點選【伺服器】→【定義資料連結】，選擇該範本使用的資料連結。如下圖2所示。

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

1. 報錯資訊：報錯資訊為【TimeoutException】，如下圖所示。

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

3. 解決方案：超級管理者可透過【fine_conf_entity視覺化配置插件】關閉逾時提示或者延長逾時提示出現的時間。重啓伺服器後設定生效。

注：修改 FineDB 資料庫表欄位值的方法請參考 B14-07 FINE_CONF_ENTITY視覺化配置 。

1

535 Error: authentication failed。

1. 報錯資訊：報錯資訊為【535 Error: authentication failed】，如下圖所示。

2. 原因分析：連結到 SMTP 伺服器的帳號或密碼錯誤。

3. 解決方案：核對連結到 SMTP 伺服器的帳號和密碼。注意對於大部分郵箱，SMTP 伺服器的帳號密碼跟登入郵箱的帳號密碼不同，一般在郵箱的設定頁面會有配置。

2

Couldn't connect to host。

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

2. 原因分析：因為網路原因無法連結到 SMTP 伺服器。

3. 解決方案：檢查配置的 SMTP 伺服器位址和埠是否正確且能聯通。可以 ping 位址得到 ip ，然後【telnet ip port】應答能否聯通。

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

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

   3）或者是郵箱伺服器的並發過大，導緻伺服器處於無法響應的狀態，進而連結不上伺服器。

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

3

Invalid Addresses。

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

2. 原因分析：收件人（或副本、密送）中含有無效郵箱位址，具體位址也會一同提示，如上圖2中的【notexist12345@163.com】。

3. 解決方案：

   1）檢查並刪除收件人（或副本、密送）中的無效郵箱位址。

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

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

4

response: 421。

1. 報錯資訊：com.fr.schedule.output.EmailException: javax.mail.MessagingException: Could not connect to SMTP host: SMTP.163.com, port: 25, response: 421；

2. 原因分析：①郵箱伺服器位址和埠配置存在問題。②SMTP 主機已達最大聯機數量。

3. 解決方案：①請收信者和郵件管理者應答收信端郵件伺服器是否正常工件。②收件者 SMTP 主機拒絕提供服務，因為已經超過其能提供的最大服務量。可透過提高 SMTP 伺服器的頻率或者將任務拆分開來解決。

5

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

1. 報錯資訊：com.sun.mail.smtp.SMTPSendFailedException: 554

2. 原因分析：郵件伺服器將郵件當成了垃圾郵件。

3. 解決方案：由於每個郵箱都有反垃圾郵件的功能，規則各有不同。

   1）首先建議點開郵箱的【垃圾箱】，找回郵件。

   2）將發件人的郵箱位址新增到郵箱的【通訊錄】中，以防被誤判成垃圾郵件。

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

2. 原因分析：①平台負責將郵件資訊（收件人、副本、密送、主題、正文等）傳送給 SMTP 伺服器，由 SMTP 伺服器根據這些資訊傳送郵件，平台本身並不進行實際郵件的傳送。②造成該報錯的實際原因為【收件人】或【副本】或【密送】的郵箱數量超過了 SMTP 伺服器的限制，不同的 SMTP 伺服器所限制的數量可能不一樣。

3. 解決方案：方案一：減少預設使用者組中使用者的數量，由於不同的 SMTP 伺服器所限制的數量可能不一樣，建議使用者數量在 500 以內。方案二：提高 SMTP 伺服器對收件人的限制，需要客戶方的 SMTP 伺服器管理人員做修改，由於不同的 SMTP 伺服器修改方式不相同，本文暫不提供修改方法。

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

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

3. 解決方案：根據對應郵箱的退信規則，排查退信原因。

1. 報錯資訊：郵箱型別為 Outlook 郵箱，報錯：STOREDRV.ClientSubmit; sender thread limit exceeded

2. 原因分析：Microsoft 限制同時間只支援 3 條執行緒並發傳送郵件，超過 3 條則會丟擲以上異常，Outlook的郵箱預設會有這個限制。10.0 排程管理的郵箱傳送郵件是多執行緒的，所以可能會出現執行緒超出3的情況。

3. 解決方案：JAR 包版本在 2019-08-16 之後的報表伺服器，超級管理者可透過【fine_conf_entity視覺化配置插件】修改排程管理模組最大執行緒數。按照 Microsoft 的限制，把 QuartzConfig.threadCount 的值改為 3 或小於 3 ，就可以避免排程管理由於執行緒超出而失敗。重啓伺服器後設定生效。

注：修改 FineDB 資料庫表欄位值的方法請參考 B14-07 FINE_CONF_ENTITY視覺化配置 。

1. 問題描述：郵件正文內容中的多個空格被合併為一個，行首空格不顯示。

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

1. 問題描述：設定定時任務傳送郵件時，在【郵件通知】中勾選了【正文加上結果連結】，點選郵件中的結果連結，出現圖一或圖二的報錯，報錯內容：【非常抱歉，您無法查看該頁面，如需存取請聯系管理者】。如下圖所示。

2. 原因分析：可能是使用者在【調度物件】步驟中勾選了【任務結束即清理】。

3. 解決方案：取消勾選【任務結束即清理】，勾選【僅保留最近一次】、【僅保留最近5次】、【不清理】、【自訂】中任意一個即可。

1. 問題描述：定時任務傳送郵件，沒有【運作監視】，也沒有收到簡訊，後臺報錯：【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.】如下圖所示。

2. 原因分析：使用者將內建 FineDB 資料庫遷移到本地 MySQL 資料庫中，本地 MySQL 資料庫中【max_allowed_packet】值設定過小導緻單個記錄超過限制後寫入資料庫失敗，且後續記錄寫入也會失敗。

3. 解決方案：

   方案一：MySQL 安裝目錄下的【my.ini】檔案中的【mysqld】 欄位中的【max_allowed_packet = 1M】修改為 500M ，重啓 MySQL 即可。

   方案二：①使用【set global max_allowed_packet = 524288000;】 語句將【max_allowed_packet】的值設定為 500 M。②使用【show VARIABLES like '%max_allowed_packet%';】 語句查看是否修改成功。

1. 問題描述：

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

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

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

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

2. 原因分析：多個工程連結了同一 FineDB 資料庫，導緻排程管理的定時執行，可能執行到其他工程上去了。

3. 排查步驟：

   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檔案。

1. 問題描述：排程管理傳送郵件失敗，報錯如下所示：【com.fr.restriction.MemoryAlarmException:很抱歉，sql 執行時間過長觸發保護機制，請稍後重試。若您是管理者，可於智慧維運-記憶體管理-範本限制中更改此項限制。】

2. 解決方案：關閉所有 範本限制。

1. 問題描述：排程管理任務【檔案處理】步驟中，處理方式選擇【郵件通知】，【郵件內容設定項】中勾選【正文加上結果連結】。收到的郵件點選結果連結，連結 URL 以【localhost】開頭。如下圖1所示。使用者希望【localhost】轉成實際 IP 。

2. 解決方案：①將數據決策系統的 URL 改成實際 IP ，例如：【http://ip:埠/工程名/decision】，如下圖2所示。②在平台建立排程管理任務或重新編輯儲存之前任務，點選郵件中的結果連結，連結 URL 開頭改變。如下圖3所示。

1. 問題描述：排程管理任務總是提前/延後數小時執行，且該值恆定，常見的為 8 小時等。

2. 原因分析：首先排查 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()); 
     }
   }
   

   上述回顯的具體時區，以客戶實際所在時區為準。

3. 解決方案：若機器時區不正確，則聯系客戶修改系統時區。若 JVM 時區不正確，則需要新增【-Duser.timezone=Asia/Shanghai】的 JVM 啟動參數：如果是 Tomcat 等容器啟動，則新增至容器的【JAVA_OPTS】位置，與設定記憶體大小的 -Xmx/-Xms 位置相同；如果是設計器/安裝版 BI 直接啟動，在啟動器同目錄下有【designer.vmoptions或finebi.vmoptions】，將上述參數新增至其中即可。

1. 問題描述：JAR 包為 2019-12-05 及之後的 FineReport 設計器，在其決策平台上建立【無調度物件】型別的任務後，如果再將 JAR 包回退到 2019-12-05 之前，便會報下面所描述的錯誤。在【數據決策系統】中，點選【管理系統】→【排程管理】後，立刻報錯【請求伺服器資料失敗】，且排程管理任務列表顯示為空；同時後臺日志報錯【java.lang.IllegalArgumentException: Non-existent schedule extension modules】，如下圖1所示。

2. 原因分析：該現象是因為出現了相容性問題，這種情況下任務正常執行，但任務列表無法正常顯示。

3. 解決方案：需要下載「雲端健檢分析-排程管理髒資料刪除插件」，自動檢查並刪除/提示刪除髒資料。

   插件使用方法：

   1）存取平台下的【/url/clean】，如【http://ip:port/webroot/decision/url/clean】。如下圖2所示；

   2）提示找到了無調度物件的排程管理任務，名稱為【工資表】，共計 1 個，點選下面的連結即可刪除該任務，如下圖3所示；

   3）刪除 FineDB 資料庫中所有 QRTZ 開頭的表，重啓工程。如下圖4所示；

   4）查看 fanruan.log 中有沒有連結資料庫逾時的日誌，如果有可以修改【\webroot\WEB-INF\config】目錄下的【db.properties】檔案，把【hibernate.maxWait】值改為【500000】（500000=500秒）。如下圖5所示。

注1：本文暫不提供下載連結，請需要的客戶聯系技術支援獲取。

注2：刪除會導緻定時任務全部終止，手動重作即可。

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

2. 解決方案：【已回退到的版本】再次執行此任務，生成新結果連結，可查看圖表。

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

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

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

注2：【自訂使用者】介紹請參見：基本設定。

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

2. 原因分析：排程管理派送決策報表時，如需匯出附件，是按照決策報表匯出邏輯匯出的。即將決策報表所有組件轉換到複合式報表，最終藉助複合式報表匯出。因此，當前決策報表匯出所不支援的功能，在排程管理派送決策報表時同樣不支援。排程管理派送決策報表附件時，如果決策報表存在組件互相重疊，則無法轉換到複合式報表，並藉助複合式報表匯出，也因此排程管理失敗。

3. 解決方案：調整決策報表組件間隔，確定不發生重疊。