Expiry after Access / Time to Idle

[cruftex]

Expiry after an entry is accessed. This is (should be) primarily intended for freeing resources if not used, while expiry after modification is an optimization versus business decision (how old is okay?).

For efficiency reasons I intend to do it not 100% on time but with a defined maximum lag.

expiryAfterAccessDuration

Time an entry expires after an access. By default there is lag of 10%, which means the actual expiry might be later then specified. Example: Configured value is 1h, the item may stay in the cache and keep visible for a maximum of 1 hour and 6 minutes after an access.

expiryAfterAccessLag

Configure a different lag time. The minimum lag time is 1 minute.

[ricardojlrufino]

What status of this implementation?
The main feature I needed was this ...

[quaff]

Ilde in title should be idle

[cruftex]

@quaff Oops, thanks, I changed the title!

[cruftex]

@ricardojlrufino Thanks for reaching out! Its good timing, since I have now stabilized the next version (1.2) and need to do some planing what important stuff to put the focus on next.

Two reasons it's not there yet: We rarely need it, there needs to be always a compromise on the performance we have achieved to provide/enable this feature.

To drive it in the right direction, I'd love to hear from people who actually need it. Can you share something about the scenario you want to use it for?

[ricardojlrufino]

@cruftex My application is from IoT and I cache the Devices in use and, after a while, I need to remove it from memory.
I ended up using the Guava library, unfortunately it is very large (2MB), and I only use it for cache.

Ref: https://github.com/google/guava/wiki/CachesExplained

[detohaz]

@cruftex This is a very important feature that I need now. I have more than 100 million elements to cache, but not all of them are accessed continuously (~ 5 millions). The cache eats my ram (> 70Gbs) so I cannot run two instances simultaneously (total 125Gbs).
I have divided into smaller partitions (32 partitions) to improve access time, and now I'm dealing with memory problems.
Hope that this feature will be implemented as soon as possible.
Thank @cruftex.

[cruftex]

@detohaz, @ricardojlrufino: Thanks for your feedback! Unfortunately, I am a bit held up with other activities but there will be some progress here during 2019... For the use cases you describe I still wonder whether TTI is really the best solution. So I like to move in two directions here: Implement TTI but also maybe come up with a better cache feature for 90% of the use cases that use TTI now.

@detohaz: You know that around 5 million entries are accessed continuously and should therefore be cached. What about limiting the cache size to 8 million entries and keep the ram usage in check?

[cruftex]

@detohaz: Did my suggestion to limit the cache size help and solve your problem?

In case you use a TTI like feature, the actual cache size would depend on the usage pattern. This can lower your heap memory usage, in times when you have low utilization. However, you don't have a guarantee for an upper memory limit.