• Bug
  • Status: Closed
  • 2 Major
  • Resolution: Not a Bug
  • ehcache-core
  • cdennis
  • Reporter: cduicu
  • June 17, 2010
  • 0
  • Watchers: 1
  • July 27, 2012
  • June 22, 2010

Description

I am using ehcache core 2.1.0 with JDK6. I create a cache with a given size and eternal set to true. I expect that once the maximum size is reached the new objects are discarded and objects in cache preserved. Note that this worked in 2.0.1. Here is a short code excerpt to test it:

CacheConfiguration cfg = new CacheConfiguration(“quickTest”, 5).overflowToDisk(false).eternal(true); Cache cache = new Cache(cfg); CacheManager.getInstance().addCache(cache);
for (int i = 0; i < 7; i++) { cache.put(new Element(i, “value” + i)); } Assert.assertEquals(“value3”, cache.get(3)); Assert.assertNull(cache.get(7)); CacheManager.getInstance().removeCache(“quickTest”);

Normally, elements 6 and 7 should be discarded and element 3 should still be in cache.

Comments

Fiona OShea 2010-06-22

Chris can you check this out and see if we have a regression?

Chris Dennis 2010-06-22

What I think you’re seeing here is combination of some timing vagaries, and a faulty test.

First of all let me stress that the behavior you describe seeing in 2.0.1 is not at all what is intended. Unless you specify otherwise Ehcache by default will give you LRU based eviction (it will try to evict the element that was retrieved least recently).

There are two assertions in your test, the second one ‘Assert.assertNull(cache.get(7))’ will always be true since you never put an element in the cache for key ‘7’, since the upper bound on your loop is exclusive.

The first assertion (which I think must be a typo since I think you meant getValue() as well since a String should never equal an Element) ‘Assert.assertEquals(“value3”, cache.get(3).getValue())’ is passing in 2.0.1 as you state correctly and failing in 2.1.0. If we adapt the test and instead of asserting things just print the set of keys left in the cache, alongside the creation times for the mapped Elements, things become a little clearer…

Ehcache 2.0.1: 6 : 1277231723437 4 : 1277231723430 3 : 1277231723430 2 : 1277231723430 1 : 1277231723430

Ehcache 2.1.0: 6 : 1277231747743 5 : 1277231747743 4 : 1277231747743 2 : 1277231747743 1 : 1277231747743

As you can see (nearly) every element present (and presumably the evicted ones too) have the same creation time. Basically the cache sees the 7 elements as being added all at the same time. This means that when we evict, which element we choose depends only the vagaries of our sample selection algorithm and possibly whether our sort operation is stable.

If we introduce a 1 second sleep between puts (to force different put times for the cache elements) then things behave as we would expect:

Ehcache 2.0.1 6 : 1277231924620 5 : 1277231923616 4 : 1277231922616 3 : 1277231921616 2 : 1277231920615

Ehcache 2.1.0 6 : 1277232032285 5 : 1277232031284 4 : 1277232030284 3 : 1277232029283 2 : 1277232028283

Hope this explains things for you.

Chris

Cristian Duicu 2010-06-22

Thanks for the comments Chris. It is true there were a few typos in the code. I modified the code after I pasted here which wasn’t a very bright idea. Here is the fixed code:

CacheConfiguration cfg = new CacheConfiguration(“quickTest”, 5).overflowToDisk(false).eternal(true); Cache cache = new Cache(cfg); CacheManager.getInstance().addCache(cache); for (int i = 0; i <= 7; i++) { cache.put(new Element(i, “value” + i)); } Element el = cache.get(3); Assert.assertNotNull(el); if (el != null) Assert.assertEquals(“value3”, el.getObjectValue()); Assert.assertNull(cache.get(7)); CacheManager.getInstance().removeCache(“quickTest”);

I do understand the argument of the timing with respect to the LRU eviction strategy.

However, I am still left confused about the meaning of “eternal” configuration attribute. My expectation was that if I configure the cache to be eternal (cfg.eternal(true)) then cache entries never expire, and therefore are never evicted from cache. This would result in a cache that once filled would simply drop the additional puts until elements are specifically removed in code.

If my understanding of “eternal” is wrong, how can I achieve the behavior described above?

Fiona OShea 2010-07-28

EHC-747 is a jira which deals with the confusion around the eternal attribute