github-actions[bot] commented on code in PR #63602:
URL: https://github.com/apache/doris/pull/63602#discussion_r3352853537
##########
be/src/io/cache/block_file_cache.cpp:
##########
@@ -841,7 +1166,13 @@ FileBlocksHolder BlockFileCache::get_or_set(const
UInt128Wrapper& hash, size_t o
file_blocks = get_impl(hash, context, range, cache_lock);
}
- if (file_blocks.empty()) {
+ if (_clear_file_cache_sync_running && file_blocks.empty()) {
Review Comment:
This barrier only makes misses/holes return `SKIP_CACHE`; it still returns
existing blocks even if `clear_file_cache_async_impl()` has already marked them
deleting. A reader that starts after `clear_file_cache_sync:barrier_ready` and
requests a hot block that was held by an earlier reader will get that deleting
`FileBlock` from `get_impl()`, take a new holder, and extend the clear wait.
Under continuous traffic to that block, sync clear can be starved indefinitely
even though no new cache blocks are inserted. Please filter `is_deleting()`
blocks while `_clear_file_cache_sync_running` is true (for example, replace
those ranges with transient `SKIP_CACHE` blocks or otherwise detach them from
`_files`) so new readers cannot pin blocks that sync clear is trying to drain.
--
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]
