It seems System.currentTimeMillis () is now in intrinsic list. This means on modern JVMs performance penalty will not be so significiant.
Nickolay, could you please raise standalone ticket for U.currentTimeMillis () ? Could you also please check if system.nanoTime / system.currentTimeMs can fix https://issues.apache.org/jira/browse/IGNITE-5963 When you create a PR, I can start several run for Ignite Cache 6 suite to check if issue is still reprodacible. ср, 9 авг. 2017 г. в 14:41, Yakov Zhdanov <yzhda...@apache.org>: > Nickolay, IgniteUtils#currentTimeMillis() is some kind of an old heritage. > I guess nobody remembers when this method has been introduced. I agree that > we can use System.currentTimeMillis(). I would suggest you file a ticket > and replace this method calls with System.currentTimeMillis(). Sounds good? > > As far as reliable elapsed time measurement I agree with you that > nanoTime() is better here, but it is definitely not a reason for mentioned > failure, since that test is launched in single JVM on a machine that most > probably does not do any ntp syncs during the test to make Ignite's timeout > machinery fail. > > Please file a ticket to switch Ignite's timeouts to nanoTime() at some > point. > > --Yakov >
