反馈已提交

网络繁忙

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

定时调度常见问题

  • 文档创建者:Wendy123456
  • 编辑次数:22次
  • 最近更新:知识库 于 2021-04-19
  • 1. 概述

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

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

    15.png

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

    报错信息:

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

    image.png

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

    原因分析:

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

    16.png

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

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

    解决方案:

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

    3. 数据集配置错误

    报错信息:

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

    image.png

    原因分析:

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

    解决方案:

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

    1592884270847427.png

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

    1592884297733142.png

    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)在运行监控中不存在定时调度任务未执行的时间点记录,后台日志也不见该时间点的日志和报错。

    原因分析:

    多个工程连接了同一 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-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秒)。如下图所示:

    17. 点击结果链接图表数据空白

    问题描述:

    JAR 包为 2019-09-27 之后的 FineReport 设计器,在其决策平台上新建定时调度任务,如果再将 JAR 包回退到之前版本(2019-05-20 至 2019-09-27,包括 2019-09-27 ),不重新执行此定时调度任务查看之前执行时挂载的结果链接,图表不可见,如下图所示:

    解决方案:

    已回退到的版本再次执行此任务,生成新结果链接,可查看图表。

    注:不建议用户回退,由于版本间不向上兼容,回退后可能会出现一些问题。

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

    2020-06-08 及之后的 JAR 中,定时调度任务配置完成后,在 用户管理 中删除 基本设置 步骤「默认用户组」中的用户角色部门职务再次执行定时调度任务,fanruan.log日志文件中显示error级别报错提醒。

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

    注:fanruan.log 日志文件存储路径为:%FR_HOME%\logs

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

    删除内容具体场景报错提醒
    用户被删除

    平台用户:

    删除一个用户:一行报错

    删除 200 个用户:一行报错,200 个用户都提示被删除

    删除超过 200 个用户:一行报错,只提示 200 个用户被删除

    自定义用户:

    只要字段中匹配不到的用户都报错,最多 200 个

    格式:

    默认用户组中部分用户不存在,请核对定时调度任务:[pp(pp)]

    示例:

    默认用户组中部分用户不存在,请核对定时调度任务:[孙建成(Billy), 王国强(Cherry)]

    角色被删除

    删除一个角色:一行报错

    删除多个角色:一行报错

    默认用户组中部分角色不存在,请核对定时调度任务

    部门被删除

    删除一个部:一行报错

    门删除多个部门:一行报错

    默认用户组中部分部门职务不存在,请核对定时调度任务

    职位被删除

    删除一个职位:一行报错

    删除多个职位:一行报错

    默认用户组中部分部门职务不存在,请核对定时调度任务

    附件列表


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

    售前咨询电话

    400-811-8890转1

    在线技术支持

    在线QQ:800049425

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

    总裁办24H投诉

    热线电话:173-1278-1526