定时调度常见问题

定时调度任务执行失败时，可以在「运行监控」的「任务执行明细」中看到日志旁的问号标志。

点击该标志即可查看详细的错误信息。本文将介绍定时调度任务中的常见错误及其解决方案。

指定BI定时调度任务执行节点

应用场景：

对于多节点集群工程，用户希望指定bi节点不执行定时调度任务，以确保业务资源

用户可通过添加工程节点启动参数-Dschedule.disable=true实现

• 对于配置了该参数值为true的工程节点，将不执行定时的调度任务，但仍然执行手动触发的调度任务

• 对于未配置该参数，或参数值为false的工程节点，将执行所有调度任务

配置方法（仅面向非运维平台部署的工程）：

• Windows：进入%Tomcat_HOME%\bin目录。寻找名为setenv.bat的文件。如果文件不存在，可以创建一个新的setenv.bat文件。在文件中添加以下行来设置，配置完成后重启工程。

set  JAVA_OPTS=%JAVA_OPTS% -Dschedule.disable=true

• Linux：进入%Tomcat_HOME%\bin目录。寻找名为setenv.sh的文件。如果文件不存在，可以创建一个新的setenv.sh文件。在文件中添加以下行来设置，配置完成后重启工程。

JAVA_OPTS="$JAVA_OPTS -Dschedule.disable=true"

调整BI定时调度任务线程数

应用场景：

当BI定时调度任务并发较高时，任务执行可能出现延迟。

用户可通过调整BI定时调度任务的执行线程数，来改善该情况。

配置方法：

超级管理员可通过V1.9.31及以上版本「fine_conf_entity可视化配置」插件，配置BI定时调度任务并发线程数。

重启服务器后设置生效。

注：修改 FineDB 数据库表字段值的方法请参考  fine_conf_entity可视化配置 。

调整FR定时调度任务线程数

应用场景：

单个FR定时调度任务，可能会对多个用户单独产生结果，因此在调用模板时产生的数据连接数也会增多，

如果数据连接数超出了最大连接数限制，可能会导致数据库压力过大，从而导致定时调度任务失败。

报错：ERROR：dn_6003_6004：[FATAL]Already too many clients

解决方案：

超级管理员可通过「fine_conf_entity可视化配置」插件，降低FR定时调度模块最大线程数和最大连接数，减小数据库的并发压力。

重启服务器后设置生效。

注：修改 FineDB 数据库表字段值的方法请参考  fine_conf_entity可视化配置 。

调整定时调度任务超时提示

原因分析：

定时调度任务在执行超过 5 分钟（默认）时，会有提示：TimeoutException

提示并不会中断任务执行，如果任务后续执行成功了，会正常记录成功日志。

解决方案：

超级管理员可通过「fine_conf_entity可视化配置插件」关闭超时提示或者延长超时提示出现的时间。

重启服务器后设置生效。

注：修改 FineDB 数据库表字段值的方法请参考  FINE_CONF_ENTITY可视化配置 。

修改定时调度附件语言

在「调度对象」步骤中若勾选「附件存档」，定时调度任务结束后生成的附件可修改语言。

超级管理员可通过「fine_conf_entity可视化配置插件」改变定时调度生成附件的语言。重启服务器后设置生效。

注：修改 FineDB 数据库表字段值的方法请参考 FineDB 常用表字段修改 。

Result file creation failed

报错信息：

报错内容：Result file creation failed: (附件名称)

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

原因分析：

定时调度任务可能会生成各类文件，而文件的命名来源于定时调度任务设置中的「文件名称」。

若「文件名称」中使用了公式，计算后的实际文件名可能会超出操作系统对文件名长度的限制（通常为 255 个字符），从而导致文件生成失败。

解决方案：

请修改定时调度任务中的「文件名称」设置，使用更短的文件名称以避免该问题。

Query: wait millis xxxxx, active xx, maxActive xxxx

报错信息：

报错信息：数据集配置错误Query: wait millis xxxxx, active xx, maxActive xxxx

原因分析：

在定时调度任务执行模板计算时，系统需要连接模板所使用的数据源进行取数。

当数据连接超时时，系统将报错提示数据集配置错误。

解决方案：

管理员可登录帆软应用，依次点击「管理系统 > 数据连接」，找到定时调度任务所使用的数据连接，并增大「最大等待时间」。

如下图所示。

535 Error: authentication failed

报错信息：

报错信息：535 Error: authentication failed，如下图所示：

原因分析：

帆软应用「管理系统>系统管理>邮箱」中的发件人设置错误。

发件人的地址或密码不正确。

解决方案：

请参考「邮箱」中的配置步骤，核对邮箱发件人配置。

注意，对于大部分邮箱，SMTP 服务器的用户名密码跟登录邮箱的用户名密码并不相同，请务必仔细检查。

Couldn't connect to host

报错信息：

报错信息为Couldn't connect to host（timeout可能为其他值），如下图所示：

原因分析：

因为网络原因无法连接到 SMTP 服务器。

解决方案：

检查配置的 SMTP 服务器地址和端口是否正确且能联通。可以 ping 地址得到 ip ，然后「telnet ip port」确认能否联通。

1）首先确认所填写的邮件服务器地址和端口都是正确的，并且发送测试邮件。如果测试邮件都无法成功发送，说明邮件服务器有问题。请去邮件客户端再次确认下。

2）如果邮件服务器测试发送邮件成功，但是偶尔还是有任务失败，报错相同，可能原因是当时网络不通畅，连接不上邮件服务器。

3）或者是邮箱服务器的并发过大，导致服务器处于无法响应的状态，从而连接不上服务器。

要么提高邮箱服务器的性能，要么将工程发送邮件的任务时间间隔开，不要并发到一个时间段。

Invalid Addresses

报错信息：

报错信息为Invalid Addresses，如下图所示：

原因分析：

收件人（或抄送、密送）中含有无效邮箱地址，具体地址也会一同提示，如上图中的notexist12345@163.com。

解决方案：

1）检查并删除收件人（或抄送、密送）中的无效邮箱地址。

2）若定时任务中有很多收件人，排查较困难，可以勾选「根据用户单独生成结果」。

在运行监控信息中可以看到只有无效的收件人会失败，其他正常用户会发送成功，将无效的收件剔除或修改正确即可。

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 服务器的频率或者将任务拆分开来解决。

com.sun.mail.smtp.SMTPSendFailedException: 554

报错信息：

com.sun.mail.smtp.SMTPSendFailedException: 554

原因分析：

邮件服务器将邮件当成了垃圾邮件。

解决方案：

由于每个邮箱都有反垃圾邮件的功能，规则各有不同。

1）首先建议点开邮箱的「垃圾箱」，找回邮件。

2）将发件人的邮箱地址添加到邮箱的「通讯录」中，以防被误判成垃圾邮件。

too many recipients

报错信息：

定时任务发送邮件，收件人数量较多时，SMTP 服务器报错，报错内容中含too many recipients字样， 如下图所示：

原因分析：

平台负责将邮件信息（收件人、抄送、密送、主题、正文等）发送给 SMTP 服务器，由 SMTP 服务器根据这些信息发送邮件，平台本身并不进行实际邮件的发送；

造成该报错的实际原因为「收件人」或「抄送」或「密送」的邮箱数量超过了 SMTP 服务器的限制，不同的 SMTP 服务器所限制的数量可能不一样。

解决方案：

方案一：减少默认用户组中用户的数量，由于不同的 SMTP 服务器所限制的数量可能不一样，建议用户数量在 500 以内。

方案二：提高 SMTP 服务器对收件人的限制，需要客户方的 SMTP 服务器管理人员做修改，由于不同的 SMTP 服务器修改方式不相同，本文暂不提供修改方法。

邮件发送成功但收不到邮件

报错信息：

无报错信息，运行监控中显示邮件发送成功，但实际没有收到。

原因分析：

原因一般是 SMTP 服务器投递的邮件被收件人邮箱拒收了。可以登录 SMTP 服务对应的邮箱（即「系统管理」中配置的邮箱），检查是否有退信相关邮件。

解决方案：

根据对应邮箱的退信规则，排查退信原因。

sender thread limit exceeded

报错信息：

邮箱类型为 Outlook 邮箱，报错：STOREDRV.ClientSubmit; sender thread limit exceeded

原因分析：

Microsoft 限制同时间只支持 3 条线程并发发送邮件，超过 3 条则会抛出以上异常，Outlook的邮箱默认会有这个限制。

定时调度的邮箱发送邮件是多线程的，所以可能会出现线程超出3的情况。

解决方案：

JAR 包版本在 2019-08-16 之后的报表服务器，超级管理员可通过「fine_conf_entity可视化配置插件」修改定时调度模块最大线程数。

按照 Microsoft 的限制，把 QuartzConfig.threadCount 的值改为 3 或小于 3 ，就可以避免定时调度由于线程超出而失败。

重启服务器后设置生效。

注：修改 FineDB 数据库表字段值的方法请参考 FineDB 常用表字段修改 。

附件乱码

问题描述：

Linux 系统中，定时任务「调度对象」中对象类型为BI 模板，附件中的 PDF 文件中文乱码，图表组件和表格组件也出现中文乱码的情况。

原因分析：

系统没有安装中文字体。

解决方案：

系统安装对应字体后，定时调度导出的文件正常。

邮件正文空格显示问题

问题描述：

邮件正文内容中的多个空格被合并为一个，行首空格不显示。

解决方案：

邮件正文中若需在行首输入空格，或在行内连续输入多个空格时，要将这些空格替换为同等数量的「 」。如下图所示：

结果链接无法正常跳转

问题描述：

设置定时任务发送邮件时，在「邮件通知」中勾选了「正文加上结果链接」，点击邮件中的结果链接，出现图一或图二的报错，报错内容：非常抱歉，您无法查看该页面，如需访问请联系管理员

如下图所示：

原因分析：

可能是用户在「调度对象」步骤中勾选了「任务结束即清理」。

解决方案：

取消勾选「任务结束即清理」，勾选「仅保留最近一次」、「仅保留最近5次」、「不清理」、「自定义」中任意一个即可。

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

工程共用 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文件。

超时报错

问题描述：

定时调度发送邮件失败，报错如下所示：

com.fr.restriction.MemoryAlarmException:很抱歉，sql 执行时间过长触发保护机制，请稍后重试。若您是管理员，可于智能运维-内存管理-模板限制中更改此项限制。

解决方案：

关闭所有 模板限制

邮件结果链接 URL 以 localhost 开头

问题描述：

定时调度任务「调度对象」步骤中「对象类型」选择「报表模板」，「文件处理」步骤中，处理方式选择「邮件通知」，「邮件内容设置项」中勾选「正文加上结果链接」。收到的邮件点击结果链接，链接 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，将上述参数添加至其中即可。

删除定时任务中用户信息报错提示

定时调度任务设置时，「基本设置>默认用户组」中，支持配置系统中的用户、部门、角色。

若管理员在「用户管理」中删除了该任务配置的相关用户、部门、角色，再次执行定时调度任务，fanruan.log日志文件中显示error级别报错提醒。

具体报错逻辑如下表所示：

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;