luchunliang opened a new issue, #12139:
URL: https://github.com/apache/inlong/issues/12139
### What happened
Description
When the Manager returns DataFlowConfig entries with a null version field,
SortConfigUtil.checkUpdate() throws a NullPointerException because
Comparator.comparing() does not accept null keys. This NPE propagates through
the config reload chain and causes SortConfigHolder.finalConfig to be
permanently stuck at the initial startup snapshot — all subsequent config
updates fail silently.
Root Cause
DataFlowConfig.version is declared as Integer (nullable wrapper type):
private Integer version;
SortConfigUtil.checkUpdate uses Comparator.comparing(versionExtractor) which
throws NPE when the extracted key is null:
Comparator<T> comparator = Comparator.comparing(versionExtractor);
return comparator.compare(lastElement, currentElement) < 0 ? currentElement
: null;
The same issue exists in SortConfigUtil.checkNoUpdate.
Impact
Once the NPE occurs during a config reload cycle,
SortConfigHolder.finalConfig is never updated again
New data flows added after startup never appear in the sort config
Only a full process restart can recover, because the first load succeeds (no
lastConfig to compare against)
Reproduction
Start sort-standalone with Manager returning valid config (first load
succeeds)
Add a new DataFlowConfig via Manager with version = null
On the next reload cycle, SortConfigUtil.checkUpdate throws NPE
All subsequent reloads also fail — config is permanently stale
Stack Trace
java.lang.NullPointerException: null
at java.util.Comparator.lambda$comparing$77a9974f$1(Comparator.java:469)
at
org.apache.inlong.common.util.SortConfigUtil.lambda$checkUpdate$0(SortConfigUtil.java:86)
at java.util.stream.ReferencePipeline ...
at
org.apache.inlong.common.pojo.sort.dataflow.DataFlowConfig.batchCheckUpdate(DataFlowConfig.java:55)
at
org.apache.inlong.common.pojo.sort.ClusterTagConfig.checkUpdate(ClusterTagConfig.java:70)
at
org.apache.inlong.common.pojo.sort.SortConfig.checkUpdate(SortConfig.java:...)
Fix
Use Comparator.nullsFirst / Comparator.nullsLast to handle null version
values:
// Before
Comparator<T> comparator = Comparator.comparing(versionExtractor);
// After
Comparator<T> comparator = Comparator.comparing(versionExtractor,
Comparator.nullsFirst(Comparator.naturalOrder()));
Applied to both checkUpdate() and checkNoUpdate() in SortConfigUtil.
Affected Versions
inlong-common (all versions containing SortConfigUtil)
inlong-sort-standalone (all versions using SortConfigHolder with v2 config
loader)
### What you expected to happen
Description
When the Manager returns DataFlowConfig entries with a null version field,
SortConfigUtil.checkUpdate() throws a NullPointerException because
Comparator.comparing() does not accept null keys. This NPE propagates through
the config reload chain and causes SortConfigHolder.finalConfig to be
permanently stuck at the initial startup snapshot — all subsequent config
updates fail silently.
Root Cause
DataFlowConfig.version is declared as Integer (nullable wrapper type):
private Integer version;
SortConfigUtil.checkUpdate uses Comparator.comparing(versionExtractor) which
throws NPE when the extracted key is null:
Comparator<T> comparator = Comparator.comparing(versionExtractor);
return comparator.compare(lastElement, currentElement) < 0 ? currentElement
: null;
The same issue exists in SortConfigUtil.checkNoUpdate.
Impact
Once the NPE occurs during a config reload cycle,
SortConfigHolder.finalConfig is never updated again
New data flows added after startup never appear in the sort config
Only a full process restart can recover, because the first load succeeds (no
lastConfig to compare against)
Reproduction
Start sort-standalone with Manager returning valid config (first load
succeeds)
Add a new DataFlowConfig via Manager with version = null
On the next reload cycle, SortConfigUtil.checkUpdate throws NPE
All subsequent reloads also fail — config is permanently stale
Stack Trace
java.lang.NullPointerException: null
at java.util.Comparator.lambda$comparing$77a9974f$1(Comparator.java:469)
at
org.apache.inlong.common.util.SortConfigUtil.lambda$checkUpdate$0(SortConfigUtil.java:86)
at java.util.stream.ReferencePipeline ...
at
org.apache.inlong.common.pojo.sort.dataflow.DataFlowConfig.batchCheckUpdate(DataFlowConfig.java:55)
at
org.apache.inlong.common.pojo.sort.ClusterTagConfig.checkUpdate(ClusterTagConfig.java:70)
at
org.apache.inlong.common.pojo.sort.SortConfig.checkUpdate(SortConfig.java:...)
Fix
Use Comparator.nullsFirst / Comparator.nullsLast to handle null version
values:
// Before
Comparator<T> comparator = Comparator.comparing(versionExtractor);
// After
Comparator<T> comparator = Comparator.comparing(versionExtractor,
Comparator.nullsFirst(Comparator.naturalOrder()));
Applied to both checkUpdate() and checkNoUpdate() in SortConfigUtil.
Affected Versions
inlong-common (all versions containing SortConfigUtil)
inlong-sort-standalone (all versions using SortConfigHolder with v2 config
loader)
### How to reproduce
Description
When the Manager returns DataFlowConfig entries with a null version field,
SortConfigUtil.checkUpdate() throws a NullPointerException because
Comparator.comparing() does not accept null keys. This NPE propagates through
the config reload chain and causes SortConfigHolder.finalConfig to be
permanently stuck at the initial startup snapshot — all subsequent config
updates fail silently.
Root Cause
DataFlowConfig.version is declared as Integer (nullable wrapper type):
private Integer version;
SortConfigUtil.checkUpdate uses Comparator.comparing(versionExtractor) which
throws NPE when the extracted key is null:
Comparator<T> comparator = Comparator.comparing(versionExtractor);
return comparator.compare(lastElement, currentElement) < 0 ? currentElement
: null;
The same issue exists in SortConfigUtil.checkNoUpdate.
Impact
Once the NPE occurs during a config reload cycle,
SortConfigHolder.finalConfig is never updated again
New data flows added after startup never appear in the sort config
Only a full process restart can recover, because the first load succeeds (no
lastConfig to compare against)
Reproduction
Start sort-standalone with Manager returning valid config (first load
succeeds)
Add a new DataFlowConfig via Manager with version = null
On the next reload cycle, SortConfigUtil.checkUpdate throws NPE
All subsequent reloads also fail — config is permanently stale
Stack Trace
java.lang.NullPointerException: null
at java.util.Comparator.lambda$comparing$77a9974f$1(Comparator.java:469)
at
org.apache.inlong.common.util.SortConfigUtil.lambda$checkUpdate$0(SortConfigUtil.java:86)
at java.util.stream.ReferencePipeline ...
at
org.apache.inlong.common.pojo.sort.dataflow.DataFlowConfig.batchCheckUpdate(DataFlowConfig.java:55)
at
org.apache.inlong.common.pojo.sort.ClusterTagConfig.checkUpdate(ClusterTagConfig.java:70)
at
org.apache.inlong.common.pojo.sort.SortConfig.checkUpdate(SortConfig.java:...)
Fix
Use Comparator.nullsFirst / Comparator.nullsLast to handle null version
values:
// Before
Comparator<T> comparator = Comparator.comparing(versionExtractor);
// After
Comparator<T> comparator = Comparator.comparing(versionExtractor,
Comparator.nullsFirst(Comparator.naturalOrder()));
Applied to both checkUpdate() and checkNoUpdate() in SortConfigUtil.
Affected Versions
inlong-common (all versions containing SortConfigUtil)
inlong-sort-standalone (all versions using SortConfigHolder with v2 config
loader)
### Environment
_No response_
### InLong version
master
### InLong Component
InLong Sort
### Are you willing to submit PR?
- [x] Yes, I am willing to submit a PR!
### Code of Conduct
- [x] I agree to follow this project's [Code of
Conduct](https://www.apache.org/foundation/policies/conduct)
--
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]
