Replies: 1 comment 1 reply
-
In refreshAfterWrite, after the duration has passed the next request to that entry triggers an asynchronous reload. When that occurs is non-deterministic, and often it is combined with expiration so inactive entries fade away. Since this is not a scheduled periodic reload, I don't think the cache should try to perform some type of jitter because it is all reactionary rather than a deterministic action. If you want to introduce jitter then consider adding an artificial delay to the reload future. This could be done by having the @Override public CompletableFuture<? extends V> asyncReload(K key, V oldValue, Executor executor) {
return super.asyncReload(key, oldValue, CompletableFuture.delayedExecutor(
ThreadLocalRandom.current().nextLong(0, 2_000), TimeUnit.MILLISECONDS, executor));
} You might also find batching the reloads to be assist in performance. See coalescing-bulkloader-reactor for an example using a reactive streams library, which makes this fairly trivial. This can buffer over a time/space interval to make more efficient requests, with a max parallelism to throttle the number of queries being made at once. does any of that help? |
Beta Was this translation helpful? Give feedback.
-
We have a problem where a lot of our cache entries all get refreshed at the same time, causing problems for our service and downstream service. An idea is to be able to configure a jitter time interval, for example (0ms to 2000ms) so that the refreshes get spread out in time. Wdyt?
From the Java docs:
Beta Was this translation helpful? Give feedback.
All reactions