1. 概述
2. 文件名称过长导致附件生成失败
报错信息：
报错信息为Result file creation failed: (附件名称)，如下图所示：
这通常会导致后续附件处理任务时（如邮件发送等）出现找不到文件报错，或发送的附件大小为 0kb 等问题。
原因分析：
定时调度任务执行时会生成.cpr、.pdf、.xls等格式的附件，这些附件的文件名来自定时调度任务设置中的「文件名称」，如下图所示：
文件名称这里可以使用公式，计算后的实际文件名可能超过操作系统对文件名长度的限制（一般为 255 左右），导致文件生成失败。
注：定时调度可以使用的公式请参见：定时调度支持的公式
解决方案：
修改定时调度任务设置，使用更短的文件名称。
3. 数据集配置错误
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 常用表字段修改 。
| 配置项 | 含义 | 修改规则 |
|---|---|---|
| QuartzConfig.threadCount | 定时调度模块最大线程数 | 参数值需为正整型 默认值为100 |
| QuartzConfig.maxConnections | 定时调度模块最大连接数 | 参数值需为正整型 |
4. 定时调度任务超时
报错信息：
报错信息为TimeoutException，如下图所示：
原因分析：
定时调度任务在执行超过 5 分钟（默认）时，会有上述提示。上述提示并不会中断任务执行，如果任务后续执行成功了，会正常记录成功日志。
解决方案：
超级管理员可通过「fine_conf_entity可视化配置插件」关闭超时提示或者延长超时提示出现的时间。重启服务器后设置生效。
注：修改 FineDB 数据库表字段值的方法请参考 FineDB 常用表字段修改 。
| 配置项 | 含义 | 修改规则 |
|---|---|---|
| ScheduleSettingConfig.taskTimeout | 设置定时任务超过时间，默认5分钟，单位为毫秒 如果配了 Nginx 等转发，不可超过 Nginx 内配置的转发超时时间。 | 参数值需为正长整型 默认值为300000 |
| ScheduleSettingConfig.timeoutRemind | 定时调度任务是否开启监控日志超时提醒 取消超时检查和提醒后不影响任务本身的执行流程 2020-01-15 及之后的 JAR 支持 | 参数值需为布尔型，默认为false false：定时调度任务不开启监控日志超时提醒 true：定时调度任务开启监控日志超时提醒 |
5. 邮件发送报错
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）将发件人的邮箱地址添加到邮箱的「通讯录」中，以防被误判成垃圾邮件。
6. SMTP 服务器报错
报错信息：
定时任务发送邮件，收件人数量较多时，SMTP 服务器报错，报错内容中含too many recipients字样， 如下图所示：
原因分析：
平台负责将邮件信息（收件人、抄送、密送、主题、正文等）发送给 SMTP 服务器，由 SMTP 服务器根据这些信息发送邮件，平台本身并不进行实际邮件的发送。
造成该报错的实际原因为「收件人」或「抄送」或「密送」的邮箱数量超过了 SMTP 服务器的限制，不同的 SMTP 服务器所限制的数量可能不一样。
解决方案：
方案一：减少默认用户组中用户的数量，由于不同的 SMTP 服务器所限制的数量可能不一样，建议用户数量在 500 以内。
方案二：提高 SMTP 服务器对收件人的限制，需要客户方的 SMTP 服务器管理人员做修改，由于不同的 SMTP 服务器修改方式不相同，本文暂不提供修改方法。
7. 邮件发送成功但收不到邮件
报错信息：
无报错信息，运行监控中显示邮件发送成功，但实际没有收到。
原因分析：
原因一般是 SMTP 服务器投递的邮件被收件人邮箱拒收了。可以登录 SMTP 服务对应的邮箱（即「系统管理」中配置的邮箱），检查是否有退信相关邮件。
解决方案：
根据对应邮箱的退信规则，排查退信原因。
8. 邮箱线程限制
报错信息：
邮箱类型为 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 常用表字段修改 。
| 配置项 | 修改规则 |
|---|---|
| QuartzConfig.threadCount | 参数值需为正整型 默认值为100 |
9. 邮件正文空格显示问题
问题描述：
邮件正文内容中的多个空格被合并为一个，行首空格不显示。
解决方案：
邮件正文中若需在行首输入空格，或在行内连续输入多个空格时，要将这些空格替换为同等数量的「 」。如下图所示：
10. 结果链接无法正常跳转
问题描述：
设置定时任务发送邮件时，在「邮件通知」中勾选了「正文加上结果链接」，点击邮件中的结果链接，出现图一或图二的报错，报错内容：非常抱歉，您无法查看该页面，如需访问请联系管理员
如下图所示：
原因分析：
可能是用户在「调度对象」步骤中勾选了「任务结束即清理」 。
解决方案：
取消勾选「任务结束即清理」，勾选「仅保留最近一次」、「仅保留最近5次」、「不清理」、「自定义」中任意一个即可。
11. 迁移 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%';」 语句查看是否修改成功。
12. 工程共用 FineDB 数据库导致定时任务执行失败
问题描述：
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文件。
13. 超时报错
问题描述：
定时调度发送邮件失败，报错如下所示：
com.fr.restriction.MemoryAlarmException:很抱歉，sql 执行时间过长触发保护机制，请稍后重试。若您是管理员，可于智能运维-内存管理-模板限制中更改此项限制。
解决方案：
关闭所有 模板限制
14. 邮件结果链接 URL 以 localhost 开头
问题描述：
定时调度任务「文件处理」步骤中，处理方式选择「邮件通知」，「邮件内容设置项」中勾选「正文加上结果链接」。收到的邮件点击结果链接，链接 URL 以localhost开头。如下图所示：
用户希望localhost转成实际 IP 。
解决方案：
1）将数据决策系统的 URL 改成实际 IP ，例如：http://ip:端口/工程名/decision，如下图所示：
2）在平台新建定时调度任务或重新编辑保存之前任务，点击邮件中的结果链接，链接 URL 开头改变。如下图所示：
15. 定时调度任务总是提前/延后固定小时数执行
问题描述：
定时调度任务总是提前/延后数小时执行，且该值恒定，常见的为 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，将上述参数添加至其中即可。
16. 点击结果链接图表数据空白
问题描述：
JAR 包为 2019-09-27 之后的 FineReport 设计器，在其决策平台上新建定时调度任务，如果再将 JAR 包回退到之前版本（2019-05-20 至 2019-09-27，包括 2019-09-27 ），不重新执行此定时调度任务查看之前执行时挂载的结果链接，图表不可见，如下图所示：
解决方案：
已回退到的版本再次执行此任务，生成新结果链接，可查看图表。
注：不建议用户回退，由于版本间不向上兼容，回退后可能会出现一些问题。
17. 删除定时任务中用户信息报错提示
2020-06-08 及之后的 JAR 中，定时调度任务配置完成后，在 用户管理 中删除 基本设置 步骤「默认用户组」中的用户、角色、部门、职务，再次执行定时调度任务，fanruan.log日志文件中显示error级别报错提醒。
具体报错逻辑如下表所示：
注：fanruan.log 日志文件存储路径为：%FR_HOME%\logs
注：「自定义用户」介绍请参见：基本设置
| 删除内容 | 具体场景 | 报错提醒 |
|---|---|---|
| 用户被删除 | 平台用户： 删除一个用户：一行报错 删除 200 个用户：一行报错，200 个用户都提示被删除 删除超过 200 个用户：一行报错，只提示 200 个用户被删除 自定义用户： 只要字段中匹配不到的用户都报错，最多 200 个 | 格式： 默认用户组中部分用户不存在，请核对定时调度任务：[pp(pp)] 示例： 默认用户组中部分用户不存在，请核对定时调度任务：[孙建成(Billy), 王国强(Cherry)] |
| 角色被删除 | 删除一个角色：一行报错 删除多个角色：一行报错 | 默认用户组中部分角色不存在，请核对定时调度任务 |
| 部门被删除 | 删除一个部：一行报错 门删除多个部门：一行报错 | 默认用户组中部分部门职务不存在，请核对定时调度任务 |
| 职位被删除 | 删除一个职位：一行报错 删除多个职位：一行报错 | 默认用户组中部分部门职务不存在，请核对定时调度任务 |
18. 决策报表导出失败
问题描述：
定时调度执行失败，错误日志：java.lang.RuntimeException: 存在报表块或图表重叠，导出失败。
原因分析：
定时调度推送决策报表时，如需导出附件，是按照决策报表导出逻辑导出的。即将决策报表所有组件转换到聚合报表，最终借助聚合报表导出。
因此，当前决策报表导出所不支持的功能，在定时调度推送决策报表时同样不支持。
定时调度推送决策报表附件时，如果决策报表存在组件互相重叠，则无法转换到聚合报表，并借助聚合报表导出，也因此定时调度失败。
解决方案：
调整决策报表组件间隔，确保不发生重叠。
19. 定时调度时模板web属性设置的自定义事件不生效
问题描述：
定时调度时模板web属性设置的自定义事件不生效，例如设置的定时填报，发现模板web属性设置的填报成功事件没有执行。
原因分析：
定时调度目前不会触发模板web属性设置的自定义事件。
解决方案：
调整模板设置，寻找替代方案。
20. 定时调度结果报表不自适应
问题描述：
定时调度所调用的决策报表模板，使用的自适应布局，直接预览时也可以正常自适应展示。
但是通过定时调度生成的结果报表文件，不自适应，模板存在空白间隙，存在各种滚动条。
原因分析：
定时调度结果报表文件是按固定大小导出的，所以会出现滚动条，有空白。
解决方法：
在定时调度文件处理里，用链接的形式查看模板，而不要直接查看生成的结果报表文件。
21. MySQL中数据表编码不一致
报错信息：
报错信息为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;