Hello, Dima. > Nickolay, could you please raise standalone ticket for U.currentTimeMillis () ?
Yes, I can. > https://issues.apache.org/jira/browse/IGNITE-5963 I will try to make quick fix for issue without change Ignite core code. So fix will not depend to U.currentTimeMillis() implementation. 2017-08-09 14:50 GMT+03:00 Dmitry Pavlov <dpavlov....@gmail.com>: > 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 > > > -- Nikolay Izhikov nizhikov....@gmail.com
