• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Fixed
  • ehcache-core
  • cdennis
  • Reporter: renegrob
  • January 19, 2010
  • 0
  • Watchers: 2
  • May 21, 2010
  • March 26, 2010

Description

After debugging over an hour I finally found out why my five seconds cache is actually a 5-6s cache: When the creation time of a cache element is set, the milliseconds are rounded up to the next second. For short caching time-spans this is a significant difference. In the source code I found the following comment: // Rounding the result to the ceiling, otherwise a // System.currentTimeInMillis that happens right before a new Element // instantiation will be seen as ‘later’ than the actual creation time However, I’m not sure if this really solves the problem:

  • System.currentTimeInMillis = 1263935596000 => This value won’t be rounded up and will still be seen as ‘later’ then the actual creation time
  • System.currentTimeInMillis = 1263935596001 => Creation time will be set to 1263935597000. Well we’ll sure not getting the effect described int the comment, but this seems to be a bit overdone… It seems to be a quick work around for a design problem which hasn’t been solved. With the probability of 1:1000 the workaround will fail. However I’m aware that EHCache is not made for such short-term caches as I use it for. But on the other hand I don’t see a reason to implement those caches differently since the configuration could change any time to 30s, 60s or even minutes.

Comments

Fiona OShea 2010-03-10

Is this already fixed?

Chris Dennis 2010-03-10

Unclustered caches now use millisecond precision. Clustered caches still use seconds. I guess whether or not it is fixed would depend on whether he’s using clustered caching or not…

Rene Grob 2010-03-12

Please, note that the main issue is that the effective cache expiry differs up to one second from the configured value.

Fiona OShea 2010-03-16

Hi Rene Are you using clustered caching?

Rene Grob 2010-03-17

No, we’re not doing any clustering. I understand that a cluster could not be replicated that fast and it’s not fitted for short time caching.

Chris Dennis 2010-03-17

We changed the unclustered caches back to use millisecond precision on timestamps in 2.0.0 I believe. The only place that my IDE claims calls TimeUtil.toSecs(long millis) is called from the core is in the Element serialization code which is only used in disk stores. Have you seen the same problem in 2.0.0?

Chris Dennis 2010-03-26

Closing this as fixed, as unclustered caches returned to millisecond precision with the 2.0.0 release.