Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update JobCompleteHelper.java #3362

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

oddityyyy
Copy link
Contributor

@oddityyyy oddityyyy commented Dec 15, 2023

    com/xxl/job/core/thread/TriggerCallbackThread.java中的doCallback()方法的处理逻辑是,找到第一个可用的调度中心(AdminBiz),执行批量任务回调。 此处若调度中心集群,执行器任务执行完毕,进行回调过程, 
    adminBiz.callback(callbackParamList)向调度中心发送请求的时候,amdin端做了校验。它首先会根据 
    `XxlJobLog log = XxlJobAdminConfig.getAdminConfig().getXxlJobLogDao().load(handleCallbackParam.getLogId()); `
    检查log是否在本地数据库中存在,而数据库xxl_job又是持久化在调度中心机器上的,不在本调度中心调度的任务不会在本调度中心的数据库中的xxl_job_log表中存放该条log记录,最终会返回失败结果,会报"log item not found."错误。 
    但是,注意! ! 
    此处仅仅是根据handleCallbackParam.getLogId(), 也就是log_id来校验的。如果是不同调度中心在同一时刻调度同一个jobId的任务,仍然会有并发调度会造成回调数据返回错乱的风险(即一个调度中心会收到另一个调度中心调度任务产生的回调结果,而恰好log_id又相同,会误处理并确认成功另一个调度中心调度任务产生的回调结果)。 
    实际生产环境中这种使用场景很少见,也不容易发生log_id碰撞。但是任务数量少的话,log_id就比较容易撞车,因此就需要更为严格的校验逻辑。 admin端可以加入更为严格的校验逻辑(验证代表本admin身份的参数<Trigger_time/LogDateTime >),日期时间精确到秒级,不容易出现碰撞。具体修改如下

What kind of change does this PR introduce? (check at least one)

  • Bugfix
  • Feature
  • Code style update
  • Refactor
  • Build-related changes
  • Other, please describe:

The description of the PR:
### 优化调度中心集群时,同时刻调度同一任务会产生的回调处理错乱问题
com/xxl/job/core/thread/TriggerCallbackThread.java中的doCallback()方法的处理逻辑是,找到第一个可用的调度中心(AdminBiz),执行批量任务回调。 此处若调度中心集群,执行器任务执行完毕,进行回调过程,
adminBiz.callback(callbackParamList)向调度中心发送请求的时候,amdin端做了校验。它首先会根据
XxlJobLog log = XxlJobAdminConfig.getAdminConfig().getXxlJobLogDao().load(handleCallbackParam.getLogId());
检查log是否在本地数据库中存在,而数据库xxl_job又是持久化在调度中心机器上的,不在本调度中心调度的任务不会在本调度中心的数据库中的xxl_job_log表中存放该条log记录,最终会返回失败结果,会报"log item not found."错误。
但是,注意! !
此处仅仅是根据handleCallbackParam.getLogId(), 也就是log_id来校验的。如果是不同调度中心在同一时刻调度同一个jobId的任务,仍然会有并发调度会造成回调数据返回错乱的风险(即一个调度中心会收到另一个调度中心调度任务产生的回调结果,而恰好log_id又相同,会误处理并确认成功另一个调度中心调度任务产生的回调结果)。
实际生产环境中这种使用场景很少见,也不容易发生log_id碰撞。但是任务数量少的话,log_id就比较容易撞车,因此就需要更为严格的校验逻辑。 admin端可以加入更为严格的校验逻辑(验证代表本admin身份的参数<Trigger_time/LogDateTime >),日期时间精确到秒级,不容易出现碰撞。具体修改如下

com/xxl/job/core/thread/TriggerCallbackThread.java中的doCallback()方法的处理逻辑是,找到第一个可用的调度中心(AdminBiz),执行批量任务回调。
此处若调度中心集群,执行器任务执行完毕,进行回调过程,adminBiz.callback(callbackParamList)向调度中心发送请求的时候,amdin端做了校验。它首先会根据
XxlJobLog log = XxlJobAdminConfig.getAdminConfig().getXxlJobLogDao().load(handleCallbackParam.getLogId());
检查log是否在本地数据库中存在,而数据库xxl_job又是持久化在调度中心机器上的,不在本调度中心调度的任务不会在本调度中心的数据库中的xxl_job_log表中存放该条log记录,最终会返回失败结果,会报"log item not found."错误。
但是,注意! ! 
此处仅仅是根据handleCallbackParam.getLogId(), 也就是log_id来校验的。如果是不同调度中心在同一时刻调度同一个jobId的任务,仍然会有并发调度会造成回调数据返回错乱的风险(即一个调度中心会收到另一个调度中心调度任务产生的回调结果,而恰好log_id又相同,会误处理并确认成功另一个调度中心调度任务产生的回调结果)。
实际生产环境中这种使用场景很少见,也不容易发生log_id碰撞。但是任务数量少的话,log_id就比较容易撞车,因此就需要更为严格的校验逻辑。
admin端可以加入更为严格的校验逻辑(验证代表本admin身份的参数<Trigger_time/LogDateTime >),具体修改如下
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant