反馈已提交

网络繁忙

当前为10.0版本文档,只有最新版本的文档支持在线编辑修改,如果想创建/编辑文档,请移步至 最新版帮助文档

定时调度常见问题

  • 文档创建者:Wendy123456
  • 历史版本:27
  • 最近更新:Carly 于 2023-10-25
  • 1. 概述

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

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

    15.png

    2. 文件名称过长导致附件生成失败

    报错信息:

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

    image.png

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

    原因分析:

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

    16.png

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

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

    解决方案:

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

    3. 数据集配置错误

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

    报错信息:

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

    image.png

    原因分析:

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

    解决方案:

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

    1592884270847427.png

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

    1592884297733142.png

    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,如下图所示:

    image.png

    原因分析:

    定时调度任务在执行超过 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,如下图所示:

    image.png

    原因分析:

    连接到 SMTP 服务器的用户名或密码错误。

    解决方案:

    核对连接到 SMTP 服务器的用户名和密码。注意对于大部分邮箱,SMTP 服务器的用户名密码跟登录邮箱的用户名密码不同,一般在邮箱的设置页面会有配置。

    5.2 Couldn't connect to host

    报错信息:

    报错信息为Couldn't connect to host(timeout可能为其他值),如下图所示:

    image.png

    原因分析:

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

    解决方案:

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

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

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

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

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

    5.3 Invalid Addresses

    报错信息:

    报错信息为Invalid Addresses,如下图所示:

    image.png

    原因分析:

    收件人(或抄送、密送)中含有无效邮箱地址,具体地址也会一同提示,如上图中的「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字样, 如下图所示:

    01.png

    原因分析:

    平台负责将邮件信息(收件人、抄送、密送、主题、正文等)发送给 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. 邮件正文空格显示问题

    问题描述:

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

    解决方案:

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

    1571110858914828.png

    10. 结果链接无法正常跳转

    问题描述:

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

    如下图所示:

    28.png

    原因分析:

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

    解决方案:

    取消勾选「任务结束即清理」,勾选「仅保留最近一次」、「仅保留最近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.

    如下图所示:

    12.png

    原因分析:

    用户将内置 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开头。如下图所示:

    2.png

    用户希望localhost转成实际 IP 。

    解决方案:

    1)将数据决策系统的 URL 改成实际 IP ,例如:http://ip:端口/工程名/decision,如下图所示:

    3.png

    2)在平台新建定时调度任务或重新编辑保存之前任务,点击邮件中的结果链接,链接 URL 开头改变。如下图所示:

    4.png

    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.vmoptionsfinebi.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;

    附件列表


    主题: 数据决策系统
    • 有帮助
    • 没帮助
    • 只是浏览

    售前咨询电话

    400-811-8890转1

    在线技术支持

    请前往「服务平台」,选择「在线支持」

    热线电话:400-811-8890转2

    总裁办24H投诉

    热线电话:173-1278-1526