jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Debugging Windows-specific timing issues (or: how starting Google Chrome magically fixes bugs in Java code)
Date Sat, 22 Mar 2014 11:38:55 GMT
Hi there,

we recently had a mini flood of bugs that only surfaced on Windows, and 
even not reproducibly. I finally figured out the reason, and this mail 
attempts to summarize the facts for future reference.

The short answer is: if you have see spurious problems on Windows, and 
nobody can reproduce them on a *nix platform, it may be caused by 
differences in how System.currentTimeMillis() works. You can verify that 
this is the case by HAVING CHROME RUNNING ON THE SAME MACHINE. When the 
problems go away, it's for the reasons I'll describe below.

The long explanation:

On Windows, Java's System.currentTimeMillis() is implemented in terms of 
a Windows system call which returns the current time. That Windows 
system time has a *configurable* granularity, where the historical 
default is ~15ms (1000 / 64).

Programs can request a better granularity, and that effects the clock 
behavior for *all* programs running on that machine. It also affects the 
performance of the machine, though!

Programs known to do this are: Google Chrome, MS SQL server, IntelliJ 
Idea, ...


- a related OAK bug: <https://issues.apache.org/jira/browse/OAK-1564> -- 
this is actually about Jukka's work on a Clock class that might help us 
get rid of System.currentTimeMillis()

- an article explaining the issue: 

For debugging purposes, I recommend running Sysinternals's ClockRes tool 
(<http://technet.microsoft.com/en-us/sysinternals/bb897568.aspx>) which 
reports the current settings, and/or to run Windows' "powercfg" tool 
("powercfg -energy duration 5"), which even reports what program caused 
the current setting (note that that tool requires admin privileges and 
for some reason doesn't work when invoked from Cygwin's bash).

Finally: never write code that expects System.currentTimeMillis() to 
change more frequently than every ~15ms. That includes checks for 
timestamps having changed, and also code that assumes that no two 
timestamps are ever the same (by using them as key in a map).

Best regards, Julian

View raw message