定时调度任务执行失败时，「运行监控」的「任务执行明细」中，对应日志右边会有问号标志。鼠标点击时会显示对应的报错信息。如下图所示：

本文将介绍 定时调度任务 中一些报错及解决方案。

报错信息：

报错信息为Result file creation failed: (附件名称)，如下图所示：

这通常会导致后续附件处理任务时（如邮件发送等）出现找不到文件报错，或发送的附件大小为 0kb 等问题。

原因分析：

定时调度任务执行时会生成.cpr、.pdf、.xls等格式的附件，这些附件的文件名来自定时调度任务设置中的「文件名称」，如下图所示：

文件名称这里可以使用公式，计算后的实际文件名可能超过操作系统对文件名长度的限制（一般为 255 左右），导致文件生成失败。

注：定时调度可以使用的公式请参见：定时调度支持的公式

解决方案：

修改定时调度任务设置，使用更短的文件名称。

报错信息：

报错信息为数据集配置错误Query: wait millis xxxxx, active xx, maxActive xxxx，如下图所示：

原因分析：

定时调度执行模板计算时，需要连接模板用到的数据连接进行取数。当连接超时时，会报上数据集配置错误。

解决方案：

在设计器中点击「服务器>定义数据连接」，选择该模板使用的数据连接，点击「连接池属性」。如下图所示：

将「最大等待时间」适当调大即可，如果还有相同报错，考虑继续调大。若依旧无法解决，建议用户查看网络是否有问题。

报错信息：

报错信息为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）将发件人的邮箱地址添加到邮箱的「通讯录」中，以防被误判成垃圾邮件。

报错信息：

定时任务发送邮件，收件人数量较多时，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）在运行监控中不存在定时调度任务未执行的时间点记录，后台日志也不见该时间点的日志和报错。

原因分析：

多个工程连接了同一 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-12-05 及之后的 FineReport 设计器，在其决策平台上创建「无调度对象」类型的任务后，如果再将 JAR 包回退到 2019-12-05 之前，便会报下面所描述的错误。

在数据决策系统中，点击管理系统>定时调度后，立刻报错「请求服务器数据失败」，且定时调度任务列表显示为空；

同时后台日志报错java.lang.IllegalArgumentException: Non-existent schedule extension modules，如下图所示：

原因分析：

该现象是因为出现了兼容性问题，这种情况下任务正常执行，但任务列表无法正常显示。

解决方案：

需要下载「云端运维-定时调度脏数据删除插件」，自动检查并删除/提示删除脏数据。

注：本文暂不提供下载链接，请需要的客户联系技术支持获取。

插件使用方法：

1）访问平台下的/url/clean，如http://ip:port/webroot/decision/url/clean。如下图所示：

2）提示找到了无调度对象的定时调度任务，名字为「工资表」，共计 1 个，点击下面的链接即可删除该任务，如下图所示：

3）删除 FineDB 数据库中所有 QRTZ 开头的表，重启工程。如下图所示：

注：删除会导致定时任务全部终止，手动重新运行即可。

4）查看 fanruan.log 中有没有连接数据库超时的日志，如果有可以修改\webroot\WEB-INF\config目录下的db.properties文件，把hibernate.maxWait值改为500000（500000=500秒）。如下图所示：

问题描述：

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

注：「自定义用户」介绍请参见：基本设置