Hi all, I've submitted PR #24363 that refactors the broker entry cache eviction algorithm to fix some correctness and performance issues in the current implementation.
The current EntryCacheDefaultEvictionPolicy has a few problems. The size-based eviction doesn't guarantee that the oldest entries are removed first - it sorts caches by size and evicts proportionally, which can leave older entries while removing newer ones. The timestamp eviction iterates through all cache instances every 10ms by default, which creates unnecessary CPU overhead, especially with many topics. There are also correctness issues when entries aren't ordered by both position and timestamp, which happens with catch-up reads and mixed read patterns. The refactored implementation introduces a centralized RangeCacheRemovalQueue that tracks entry insertion order using JCTools MpscUnboundedArrayQueue. This ensures both size-based and timestamp-based eviction process entries from oldest to newest, guaranteeing proper FIFO behavior. The approach also consolidates eviction handling to a single thread to avoid contention and removes some unnecessary generic type parameters from RangeCache. The key difference is that instead of the complex size-sorting algorithm, entries are simply processed in insertion order until the eviction target is met. This should improve cache hit rates and reduce CPU overhead from the frequent iterations. This work prepares the broker entry cache for further improvements to efficiently handle catch-up reads and Key_Shared subscription scenarios. The current cache has limitations around unnecessary BookKeeper reads during catch-up scenarios, poor cache hit rates for Key_Shared subscriptions with slow consumers, and cascading performance issues under high fan-out catch-up reads. The centralized eviction queue design provides a foundation for addressing these issues in future work. Would appreciate reviews, particularly around the eviction logic and any potential edge cases I might have missed. PR: https://github.com/apache/pulsar/pull/24363 Thanks, Lari
