• Bug
  • Status: Closed
  • Resolution: Fixed
  • drb
  • Reporter: sourceforgetracker
  • September 21, 2009
  • 0
  • Watchers: 0
  • September 22, 2009
  • September 22, 2009

Description

I’ve been getting the ehcache 1.4-beta2 build to work on my box. Mostly no trouble but some unit tests failed. Afte3r investigation, it seemed to be that Thread.sleep wasn’t waiting long enough for elements to expire. I ran a test, running sleep 1000 times and yes, it’s under: long start = System.currentTimeMillis(); Thread.sleep(1001); long end = System.currentTimeMillis(); long delta = end - start;

Running java 1.5.0_11 on a dual processor Windows XP box.

When I run the test, I see values 999, 1000, 1015, 1016. Most of them are 1000 - the closest value under 1001. Other tests with different sleep timesconfirm this behaviour: I haven’t experimented extensively by any means, but if you set all the sleep times in unit tests to be about 16 milliseconds longer than you expect it should make them run more reliably. When I get a chance, I’ll run the test on some linux boxes and see what I get. Mostly because I run my production code on linux and now I’m curious. Sourceforge Ticket ID: 1880042 - Opened By: nobody - 25 Jan 2008 22:18 UTC

Comments

Sourceforge Tracker 2009-09-21

Logged In: YES user_id=693320 Originator: NO

Hi

Yes, I know of this issue. The problem is unique to Windows and is caused by their timing service not being precise. I did go through the tests last year and upped these. In addition there is a net.sf.ehcache.speedAdjustmentFactor which can be used to tune the tests for your machine. See http://ehcache.sourceforge.net/documentation/building.html on how to use it.

I had upped the times by 10ms to account for windows. Based on your testing I have upped a few by 20ms. Thanks for letting me know about your research.

Greg Comment by: gregluck - 30 Jan 2008 07:04 UTC

Fiona OShea 2009-09-22

Re-opening so that I can properly close out these issues and have correct Resolution status in Jira