• Patch
  • Status: Closed
  • 2 Major
  • Resolution: Duplicate
  • ehcache-core
  • alexsnaps
  • Reporter: cedelire
  • April 29, 2011
  • 0
  • Watchers: 1
  • July 27, 2012
  • May 19, 2011



We are currently changing our website to implement caches as we are currently using hibernate.

We found an issue during our tests and found the solution.

So, it appears when system clock has changed due to global network clock update or a Daylight Saving Time, an infernal loop stuck our website …

Is it possible for your team on the next released version to do that change :

on net.sf.ehcache.util.Timestamper

we had to change the line ( 63 ) from :

        long base = System.currentTimeMillis() << BIN_DIGITS;


        long base = System.nanoTime() << BIN_DIGITS;

thanks in advance

Best regards


Fiona OShea 2011-05-03

Merge to Ehcache-core-2.4.x

cedric masset 2011-05-05

okay …

About this issue … it seems that the solution i found is not the right one as in about 3 JVMs, one of them failed at start time …

The way i found to solve that is very simple …

my new next() method introduce a new variable which contains the last time returned … in the way that clock back in time … it increase the new variable and send it as result … and the issue disappear as returned time will slow down till to be up to date.

see my new method :

first create variable :

private static long previousTime = 0;

then change next() as following :

public static long next() { int runs = 0; while (true) { if (runs++ > 0 && LOG.isInfoEnabled()) { LOG.info(“Thread continue. Clock has changed, time will move slowly”); previousTime++; return previousTime; } long base = System.currentTimeMillis() « BIN_DIGITS; long maxValue = base + ONE_MS - 1;

        for (long current = VALUE.get(), update = Math.max(base, current + 1); update < maxValue;
             current = VALUE.get(), update = Math.max(base, current + 1)) {
            if (VALUE.compareAndSet(current, update)) {
            	previousTime = update;
                return update;

And the issue disappear.

what do you think about that ?

thank you


Alexander Snaps 2011-05-19

Is a duplicate for EHC-853

Alexander Snaps 2011-05-19

Can you give more information on your topology (OS, VMs), as switching to DST shouldn’t impact currentTimeMillis (as it is supposed to return millis since epoch (midnight, January 1, 1970) UTC…

cedric masset 2011-05-19


Here is the current OS : Windows XP.

I’m using tomcat v6.0 and jdk1.6.0_14. Same issue using last version jdk1.6.0_25.

our production environment is quite different as we are using Unix / Weblogic but we didn’t use that at all for our test.


Alexander Snaps 2011-05-19

Thanks. I look into this DST issue and XP then… for my personal knowledge :) trunk has a solution for dealing with time “ticking backwards” now. Hope that helps!

cedric masset 2011-05-19

okay. Could you tell me if the trunk’s solution could work fine on my System? ;-)

is this solution already available or will it be available on the next version of eh-cache?

So I could make my own test as well.

Thank you


Alexander Snaps 2011-05-19

It will be in 2.4.3, but you could build it using maven, just by checking out trunk http://svn.terracotta.org/svn/ehcache/trunk/ (or http://svn.terracotta.org/svn/ehcache/trunk/core) I committed the fix today (r4001 iirc), so it won’t be in a SNAPSHOT until tomorrow, but I don’t think we do publish SNAPSHOT to a public repo

cedric masset 2011-05-19

thanks !

Well done :-)

If i have enough time this week I’ll have a look and tell you if it’s work fine on my System. Holidays are not so far … May i’ll use 2.4.3 and see what’s happen … ;-)


Alexander Snaps 2011-05-19

Snapshots are actually published to this repo: http://www.terracotta.org/download/reflector/snapshots You’ll have to add it to your config, but you should get ehcache-core-2.4.3-SNAPSHOT from there.

cedric masset 2011-07-20

Hi !

to follow my last comment, i tried 2.4.3 and it works perfectly now.

thank you !!!