SuperCarrys opened a new issue, #2217:
URL: https://github.com/apache/shardingsphere-elasticjob/issues/2217
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?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail:
[email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
