There is no objection for a couple of days. I'll send a PR according to
what we have discussed.
Aloys Zhang 于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
>
> > 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
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
>
+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
+1,
The new configuration should be compatible with the existing one.
Penghui
On Wed, Mar 16, 2022 at 9:09 AM 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
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 =
