Java could do some heavy stuff when doing currentTimeMillis, depending on the platform or vendor. I remember I saw some articles about performance issues caused by currentTimeMillis (something about high contention on certain OS configuration). So I do not see a reason why we should remove it. It is not very good in terms of resolution, but AFAIK we do need it anyway.
On Wed, Aug 9, 2017 at 2:41 PM, Yakov Zhdanov <[email protected]> wrote: > 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 >
