> > 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 >> > >> >
