wenzhenghu commented on code in PR #65126:
URL: https://github.com/apache/doris/pull/65126#discussion_r3656107240
##########
fe/fe-core/src/main/java/org/apache/doris/datasource/metacache/MetaCacheEntry.java:
##########
@@ -107,11 +166,18 @@ public MetaCacheEntry(String name, @Nullable Function<K,
V> loader, CacheSpec ca
maxSize,
true,
null);
- this.loadingData =
cacheFactory.buildCache(this::loadFromDefaultLoader, refreshExecutor);
+ // Build through a dedicated loader so refresh reload can check
generation before publishing.
+ CacheLoader<K, V> cacheLoader = newCacheLoader();
+ if (syncRemovalListener) {
+ this.loadingData =
cacheFactory.buildCacheWithSyncRemovalListener(cacheLoader, removalListener);
+ } else {
+ this.loadingData = cacheFactory.buildCache(cacheLoader,
refreshExecutor);
+ }
this.data = loadingData;
// Initialize striped locks eagerly to keep the hot path
allocation-free.
for (int i = 0; i < loadLocks.length; i++) {
loadLocks[i] = new Object();
+ publishLocks[i] = new Object();
Review Comment:
Fixed in `650788be165`.
`MetaCacheEntry` now groups the load lock, publication monitor, and
generation into a per-stripe `StripeState`. Multi-key entries install stripe
states lazily through `AtomicReferenceArray` CAS, so cold enabled and disabled
database/engine cache entries initialize zero stripe states. The single-key
names entry keeps one eager state. States are retained and never replaced;
`invalidateAll()` bumps only initialized states, while slow loads remain
outside the publication monitor. This preserves the existing
generation/publication protocol without the eager 512-lock allocation.
I added allocation guards for generic multi-key entries, disabled entries,
and real engine cache entries, plus retained the in-flight load vs.
`invalidateAll()` coverage. The focused metadata-cache/deadlock tests pass (47
tests), the external catalog/database/session/HMS-event/editlog-replay
regressions pass (97 tests), and FE checkstyle reports 0 violations.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
