Thank you Brent for the pointer!
I think that using nanoTime() is simpler in this situation.
We don't really have to use currentTimeMillis(), so no need to make it
more reliable.
Sincerely yours,
Ivan
On 14.04.2014 21:22, Brent Christian wrote:
Hi, Ivan
This sounds like an issue we saw in FX a while ago with imprecise
timers on Windows. If it is, you might check out:
https://bugs.openjdk.java.net/browse/JDK-6435126
It describes a workaround to enable higher-precision timing on Windows
(using a long-sleeping daemon thread). That might be a third
alternative solution...
-Brent
On 4/14/14 6:21 AM, Ivan Gerasimov wrote:
Hello!
The test EarlyTimeout.java failed again, now with message "elapsed time
981 is less than timeout 1000."
The root cause seems to be non-accurate time measurement in Windows:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724397(v=vs.85).aspx
Because of this we can achieve this result:
long start1 = System.currentTimeMillis();
long start2 = System.nanoTime();
~~~~~~~~
long elapsed2 = (System.nanoTime() - start2) / 1000000;
long elapsed1 = System.currentTimeMillis() - start1;
assert elapsed2 < elapsed1; // can fail
There might be two ways to address the issue:
- add a tolerance > 15 ms, or
- use System.nanoTime() for the measurement.
I did both.
Would you please help review the test fix?
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8038982
WEBREV: http://cr.openjdk.java.net/~igerasim/8038982/0/webrev/
Sincerely yours,
Ivan
