ExpireAfter Max Time

[wxjlibra]

Since expireAfter(Expiry) is using TimeWheel underneath, may I know is there any limit there or it could work till Long.MAX based on the current implementation, and any performance concern in here. Thanks in advance.

[ben-manes]

Yes, it should work with Long.MAX_VALUE as the duration. The internal restrictions apply to how far forward the Ticker can jump, which might occur with a unit test or otherwise fake time source. These constraints were to simplify the logic as considered out of scope as reasonable user behavior, but would not be harmful if violated.

caffeine/caffeine/src/main/java/com/github/benmanes/caffeine/cache/TimerWheel.java

Lines 93 to 95 in 563ff7c

	// If wrapping then temporarily shift the clock for a positive comparison. We assume that the
	// advancements never exceed a total running time of Long.MAX_VALUE nanoseconds (292 years)
	// so that an overflow only occurs due to using an arbitrary origin time (System.nanoTime()).

caffeine/caffeine/src/main/java/com/github/benmanes/caffeine/cache/TimerWheel.java

Lines 129 to 130 in 563ff7c

	// We assume that the delta does not overflow an integer and cause negative steps. This can
	// occur only if the advancement exceeds 2^61 nanoseconds (73 years).

[ben-manes]

I should also add that the timer wheel optimizes for up to one week durations (6.5 days). Any duraton over that is stored in an overflow wheel with a single bucket. The operations are all amortized O(1), where turning a wheel causes it to iterate through that bucket's contents to resort them. In most cases these buckets hold only a few items as they represent hours, minutes, days. As the operations are O(1) so iterating over thousands of entries is still very fast, where the cost is simply that it is walking a linked list so more cpu cache misses. As the overflow is a single bucket, if you had many millions of entries in overflow then after 1 week it would be scanned, likely just reinserting back to that overflow area.

That means the worst case performance is if expiration was pseudo disabled with everything given a Long.MAX_VALUE duration. Once a week it would perform an O(n) scan over all of the contents. This would be done under the eviction lock, so delaying evictions as it performs this maintenance work. However, evictions are typically non-blocking so while that penalizes the thread doing the work the application would not suffer. Thus if you had hundreds of millions of entries then there might be some churn, but it is unlikely to be problematic even in that case.