API change in EHCache 1.3

Type: New Feature
Status: Closed
Priority: 1 Critical
Resolution: Fixed
Component/s: Integration Modules
Labels:

Assignee: hhuynh
Reporter: kbhasin
Created: January 02, 2008
Votes: 0
Watchers: 0
Updated:
January 31, 2008
Resolved:
January 24, 2008

Description

I got this from Passenger:

We have been doing testing and found that in 2.4.6 and even in 2.4.8 the API used in the TimeExpiryMemoryStore.java is not up to date with EHCache 1.3 when getting the configuration information. We have made the change in the class to make our application work. Please add this to the main branch so future releases do not needed to be patched.

Following code changed:

  long threadIntervalSec = cache.getCacheConfiguration().getDiskExpiryThreadIntervalSeconds();
  long timeToIdleSec = cache.getCacheConfiguration().getTimeToIdleSeconds();
  long timeToLiveSec = cache.getCacheConfiguration().getTimeToLiveSeconds();

Original code:

  long threadIntervalSec = cache. getDiskExpiryThreadIntervalSeconds();
  long timeToIdleSec = cache. getTimeToIdleSeconds();
  long timeToLiveSec = cache. getTimeToLiveSeconds();

Comments

Fiona OShea 2008-01-02

http://www.terracotta.org/confluence/display/integrations/EHCache

2.4.8 has clustered ehcache 1.3 fix in 2.5 for 2.5.1

Alex Miller 2008-01-03

TimeExpiryMemoryStore is in clustered-ehcache-commons-1.0 and is (presumably) used for both ehcache 1.3 and 1.2.4. The description mentions only 1.3, so will this change break 1.2.4?

Kunal Bhasin 2008-01-03

I haven’t looked at the source yet but my understanding is that the API change happened in 1.3. So, this class should probably moved from ehcache-commons to ehcache.

Alex Miller 2008-01-11

I’ve been working on this jira and actually have everything working and all tests passing but I wanted to mention something before I commit. From getting our unit tests to work, I found that there seems to be a difference in behavior in 1.3 and I just wanted to mention it in case it raises any flags.

It seems that calling Ehcache.getDiskExpiryThreadIntervalSeconds() will return the defaultCache setting overlaid by the specific cache setting. However, Ehcache.getCacheConfiguration().getDiskExpiryThreadIntervalSeconds() seems to just return the value from the specific cache. So, this change could cause you to see a different value for at least this variable. Haven’t experimented with the others, but I’m guessing they are similar.

We had one test that was relying on the value set in the default cache and not overriding it. I had to apply the setting to the test cache as well to get it to show up.

Fiona OShea 2008-01-11

Alex can you ask Antonio and Tim to review this comment. thanks

Alex Miller 2008-01-11

I think the problem I commented on earlier was due to a bug in the code which I’ve fixed. Anyhow, tests all seem to be working and I think it’s ok now.

Just for good measure I posted the question on the ehcache forums in case that problem is real.

Fiona OShea 2008-01-24

From: Alex Miller [mailto:[email protected]]

Sent: Wednesday, January 23, 2008 7:47 PM To: Tim Eck Cc: Steven Harris; Antonio Si; Fiona O’Shea Subject: Re: r6668 has been erased in 2.5 branch?

Yeah, looks like the change got undone in the merge from the lock-jmx branch. Looks like the last merge from 2.5 to lock-jmx was 6664 a couple hrs before that. 6668 and 6669 were done about 1.5 hr apart.

The change is in trunk.

Fiona, this was the fix for DEV-1204 - looks like it’s not in 2.5.1 as expected.

Fiona OShea 2008-01-24

refixed 6819