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
On Wed, Aug 9, 2017 at 2:41 PM, Yakov Zhdanov <yzhda...@apache.org> 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