Welcome! Please see the About page for a little more info on how this works.

+2 votes
in core.cache by

TTLCacheQ is built on top of System/currentTimeMillis which is not monotonic, the behavior of the cache could be affected by clock adjustments (ex NTP). My suggestion was to change it to System/nanoTime which is monotonic and therefore more consistent to calculate the elapsed time.

If this clock adjustments effect is desired on the ttl cache maybe it should become another cache strategy with a doc on this behavior.

PS: I've created a .patch to fix this, signed the CA but I don't know where to ask for a JIRA account to open an issue.

1 Answer

0 votes

This makes me a bit concerned about just switching to nanoTime https://www.geeksforgeeks.org/java-system-nanotime-vs-system-currenttimemillis/ but I understand why using currentTimeMillis might also be problematic in some edge case situations.

I've created https://clojure.atlassian.net/browse/CCACHE-62 for this but it will need careful analysis before any action is taken. A reasonable approach might be to add a new type of TTL cache that is based on using nanoTime instead of currentTimeMillis, rather than switching the current implementation.

Agreed, since both timers has some pros and cons adding another type of TTL cache using System/nanoTime would be the best.
edited by
That geeksforgeeks link seems to have outdated info. Other sources like https://stackoverflow.com/a/4588605 and https://stackoverflow.com/a/54566928 have more detail. It seems that (hopefully) running patched Java 8 or later should result in a consistent System/nanoTime. That's a big improvement over System/currentTimeMillis, which can be inconsistent (for TTL purposes) without any JVM or OS bugs.

I'm fine with either solution, just sharing data.
Thanks, John. I'll have a read through all of this when I go back to working on core.cache next.