lhotari commented on code in PR #24363: URL: https://github.com/apache/pulsar/pull/24363#discussion_r2117698465
########## managed-ledger/src/main/java/org/apache/bookkeeper/mledger/impl/cache/RangeCache.java: ########## @@ -0,0 +1,287 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ +package org.apache.bookkeeper.mledger.impl.cache; + +import io.netty.util.IllegalReferenceCountException; +import java.util.ArrayList; +import java.util.Collection; +import java.util.List; +import java.util.Map; +import java.util.concurrent.ConcurrentNavigableMap; +import java.util.concurrent.ConcurrentSkipListMap; +import java.util.concurrent.atomic.AtomicLong; +import java.util.function.Function; +import lombok.extern.slf4j.Slf4j; +import org.apache.bookkeeper.mledger.Position; +import org.apache.commons.lang3.tuple.Pair; + +/** + * Special type of cache where get() and delete() operations can be done over a range of keys. + * The implementation avoids locks and synchronization by relying on ConcurrentSkipListMap for storing the entries. + * Since there are no locks, it's necessary to ensure that a single entry in the cache is removed exactly once. + * Removing an entry multiple times could result in the entries of the cache being released multiple times, + * even while they are still in use. This is prevented by using a custom wrapper around the value to store in the map + * that ensures that the value is removed from the map only if the exact same instance is present in the map. + * There's also a check that ensures that the value matches the key. This is used to detect races without impacting + * consistency. + */ +@Slf4j +class RangeCache { + private final ConcurrentNavigableMap<Position, RangeCacheEntryWrapper> entries; + private final RangeCacheRemovalQueue removalQueue; Review Comment: > 1. what happens if some entries are reused repeatedly? Do we move them to the tail of the removal queue? Shouldn't we deprioritize evicting those entries?(e.g large fanout cases, subscriptions with many consumers) This PR doesn't make changes to the algorithm itself. There's a possibility to improve later. The queue remains the most efficient way to evict entries that aren't going to be reused. The experiment in lhotari/pulsar#209 contains changes where there would be a "stash" besides the queue where this "deprioritizing" of eviction could happen. Keeping the eviction algorithm simple will help avoid overhead caused by eviction. a priority queue could be one possibility, but the challenge is that priorities change dynamically and that's why a scanning based solution for longer retention could be a better algorithm later. However it's not included in this PR intentionally since this PR is focusing on addressing the problems described in the PR description. -- 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: commits-unsubscr...@pulsar.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
