EHC ❯ Last retrieved element is evicted from cache
-
Bug
-
Status: Closed
-
2 Major
-
Resolution: Fixed
-
ehcache-core
-
-
cdennis
-
Reporter: jandam
-
June 06, 2011
-
0
-
Watchers: 0
-
July 27, 2012
-
July 07, 2011
Description
Last retrieved element is immediately evicted from memory cache (mem cache is full) because accessTime is read from disk store -> older than any access time from memory cache.
Config: Eternal LRU cache with overflow to disk. (LFU doesn’t work too)
More info: http://lists.terracotta.org/pipermail/ehcache-list/2011-June/000397.html
Comments
Fiona OShea 2011-06-07
Chris Dennis 2011-06-07
He’s right that this is a bug (exposed partly because of his small in-memory size). This won’t affect 2.5.0 because of the work being done to the stores under RMP-565. I think it’s worth fixing in the 2.4.x line, but I don’t think it’s a good idea to try and squeeze it in to the 2.4.3 release. Not sure how that means this should be targeted.
Chris Dennis 2011-06-07
You’re right this behavior is definitely a bug. It’s revealed in your code as you have a relatively small in-memory size, and the eviction algorithm preferentially picks the ‘random’ sample from the currently in use segment, which makes it more likely that the just faulted key gets in to the sample.
Unfortunately we’re too late to get a fix for this in to the 2.4.3 release, but the good news is that with the development work going on in trunk, this won’t be an issue when the next major release comes out (2.5.0). In the meantime I will fix this in the 2.4.x branch sometime soon, which will ensure that it will be fixed in 2.4.4. Currently there isn’t a timeframe for when that release will happen, however once 2.4.3 is released we will start building 2.4.4-SNAPSHOT nightlies which will obviously contain the fix once it is checked in.
Fiona OShea 2011-06-10
Chris targeting this to 2.4.x branch so that it can be checked in whenever you get a chance
Chris what are your thoughts on this? Is is a big problem? 3.5.2/2.4.3 worthy?