core.cache: TTLCacheQ timer is not monotonic

Question

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.

Answer 1

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.

Comments

Agreed, since both timers has some pros and cons adding another type of TTL cache using System/nanoTime would be the best.

---

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.