shardingsphere-elasticjob
shardingsphere-elasticjob copied to clipboard
When 2.x is upgraded to 3.x, an error of className inconsistency is reported
The reason is that the 3.x version and 2.x have different structures for storing data in zk. The className of 3.x is stored under the jobRootNode, while the 2.x version is stored under the config node, and the 2.x is upgraded to In 3.x, an error will be reported when judging the className, but I read the source code, and the code for judging the task className is as follows:
private void checkConflictJob(final String newJobClassName, final JobConfiguration jobConfig) {
if (!jobNodeStorage.isJobRootNodeExisted()) {
return;
}
String originalJobClassName = jobNodeStorage.getJobRootNodeData();
if (null != originalJobClassName && !originalJobClassName.equals(newJobClassName)) {
throw new JobConfigurationException(
"Job conflict with register center. The job '%s' in register center's class is '%s', your job class is '%s'", jobConfig.getJobName(), originalJobClassName, newJobClassName);
}
}
Among them, null != originalJobClassName is to judge whether there is a className under the jobRootNode node in zk, but the judgment here is not null. I found that this String will always be referenced in the test, so null != originalJobClassName is always true, even if the string is an empty character string, so I think, is it possible to change to
if (StringUtils.isNotBlank(originalJobClassName) && !originalJobClassName.equals(newJobClassName))
In this way, the desired judgment logic can be achieved. May I ask if the official can modify it in this way? Is there any situation that I have not considered?
升级3.x后 ,job会判断任务根节点下存储className是否和当前任务相同,明显此时是没有的, 但是代码里做了!=null的判断,但这里的originalJobClassName在任务节点存在时不可能为null,且方法开头已经做了任务节点是否存在的判断,所以这里判断!=null是没有意义的,要判断originalJobClassName是不为空,判断逻辑应为 if (StringUtils.isNotBlank(originalJobClassName) && !originalJobClassName.equals(newJobClassName))
- @SuperCarrys you want to submit a PR?