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
ср, 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