• Bug
  • Status: Open
  • 2 Major
  • Resolution:
  • cdennis
  • Reporter: teck
  • February 17, 2011
  • 0
  • Watchers: 0
  • October 11, 2011

Description

In org.terracotta.cache.TerracottaDistributedCache.getNonExpiredEntry(K, boolean, GetType) the expiration checks are only based on this (line 234):

  if (isEvictionEnabled() || isCapacityEvictionEnabled()) {

It should probably be this:

  if (isEvictionEnabled() || isCapacityEvictionEnabled() || entry.hasCustomLifespan()) {

Clustered ehcache isn’t affected by this since there are additional expiration checks and subsequent remove calls up in ehcache-core.

Comments

Tim Eck 2011-02-18

Since I don’t think this bug affects ehcache I’m not sure how critical this is for fremantle, but then again the fix and a test are probably pretty easy so perhaps we can knock this out

Chris Dennis 2011-02-18

After putting a fix for this in to trunk, I realized that it had some downsides. Since I couldn’t add a TimestampedValue.hasCustomLifespan() method due to API constraints the only root open is to avoid the lifespan check only when I know the element can’t have a custom lifespan, this means when the concrete type of the TimestampedValue is one of the known toolkit implementations. Unfortunately Ehcache uses it’s own TimestampedValue implementations, that wouldn’t pass this test, and so the expiry check would be done every time for Ehcache (a perf degredation).

Since fixing this will either be mucho ugly, or cause a pref degredation in Ehcache, I’ve instead decided (with the agreement of Tim) to move this in to the scope of the API 2.0 JIRA.

Steve Harris 2011-02-18

I think I misunderstood this jira. What is the circumstance where a user can run into this?

Chris Dennis 2011-02-18

A toolkit user creates a TerracottaDistributedCache with an ‘infinite’ (aka 0) TTI and TTL. If they then add either a CustomLifespanSerializedEntry object in to the cache, or they add their own TimestampValue subclass that has some expiry behavior then they will not see this behavior taking effect. For an example have a look at the code in the EternalCacheMortalElementTest class that I just added to the toolkit source in trunk.

Just to reiterate: this problem cannot hit an Ehcache user, only direct toolkit users are affected.

Chris Dennis 2011-07-01

When this JIRA is fixed, the associated test in terracotta-toolkit (EternalCacheMortalElementTest) should be re-enabled.