There is no objection for a couple of days. I'll send a PR according to what we have discussed.
Aloys Zhang <aloyszh...@apache.org> 于2022年3月18日周五 21:53写道： > > > > What's more, the evict task is executed once, and then sleep > waitTimeMillis > > > before the next round, we can use a ScheduledExecutorService to > replace it. > > > +1, Currently it works like scheduleAtFixDelay, but I think we may need > scheduleAtFixRate. > > Currently, the eviction interval is controlled by `Thread.sleep()` > > ```java > doCacheEviction(); > Thread.sleep(waitTimeMillis); > ``` > > > Aloys Zhang <aloyszh...@apache.org> 于2022年3月18日周五 21:44写道： > >> Hi penghui, >> >> The new configuration should be compatible with the existing one. >>> >> >> Agree that the compatible should be concerned. And the compatibility >> strategery has been posted in the first email. >> >> For compatibility >>> >>> - >>> >>> if only evictionFrequency is configed, keep using current logic >>> - >>> >>> if boty evictionFrequency and managedLedgerCacheEvictionIntervalMs >>> are configed, managedLedgerCacheEvictionIntervalMs is aprior choice >>> - >>> >>> if only managedLedgerCacheEvictionIntervalMs appears, use the >>> managedLedgerCacheEvictionIntervalMs >>> >>> What do you think about this? >> >> >> Haiting Jiang <jianghait...@apache.org> 于2022年3月17日周四 15:31写道： >> >>> +1 >>> >>> managedLedgerCacheEvictionIntervalMs is easier to understand. >>> >>> > What's more, the evict task is executed once, and then sleep >>> waitTimeMillis >>> > before the next round, we can use a ScheduledExecutorService to >>> replace it. >>> >>> +1, Currently it works like scheduleAtFixDelay, but I think we may need >>> scheduleAtFixRate. >>> >>> >>> Thanks, >>> Haiting >>> >>> On 2022/03/16 01:09:47 Aloys Zhang wrote: >>> > Hi all, >>> > >>> > Pulsar uses an EntryCache to support entry caching for tailing-read. >>> and >>> > there is a periodic task to evict entry from the cache. >>> > >>> > The task period is calculated by >>> > >>> > double evictionFrequency = >>> > Math.max(Math.min(config.getCacheEvictionFrequency(), 1000.0), 0.001); >>> > long waitTimeMillis = (long) (1000 / evictionFrequency); >>> > >>> > First, we should set a evictionFrequency which means how many times >>> evict >>> > task will be executed per second. >>> > >>> > Then, get the waitTimeMillis (task interval in milliseconds) by 1000 / >>> > evictionFrequency. >>> > >>> > It's a little complicated and confusing, what we need is just the evict >>> > task interval, I didn't see the benefits of evictionFrequency . >>> > >>> > So I think it's better to set the evict task interval (maybe called >>> > managedLedgerCacheEvictionIntervalMs) directly and deprecate the >>> > evictionFrequency. >>> > >>> > For compatibility >>> > >>> > - >>> > >>> > if only evictionFrequency is configed, keep using current logic >>> > - >>> > >>> > if boty evictionFrequency and managedLedgerCacheEvictionIntervalMs >>> are >>> > configed, managedLedgerCacheEvictionIntervalMs is aprior choice >>> > - >>> > >>> > if only managedLedgerCacheEvictionIntervalMs appears, use the >>> > managedLedgerCacheEvictionIntervalMs >>> > >>> > What's more, the evict task is executed once, and then sleep >>> waitTimeMillis >>> > before the next round, we can use a ScheduledExecutorService to >>> replace it. >>> > >>> > >>> > Any suggestions are appreciated. >>> > >>> > >>> > Thanks, >>> > >>> > Aloys >>> > >>> >>
