Re: IgniteUtils#currentTimeMillis

Well, then let's leave it as is for now. --Yakov

Re: IgniteUtils#currentTimeMillis

Yakov, For example: http://pzemtsov.github.io/2017/07/23/the-slow-currenttimemillis.html >>> We’ve learned that the slow execution of currentTimeMillis() was caused by two factors: >>> - JVM using gettimeofday() instead of clock_gettime() >>> - gettimeofday() being very slow if HPET time source

Re: IgniteUtils#currentTimeMillis

I assume that Vladimir mention this mesurements: https://shipilev.net/blog/2014/nanotrusting-nanotime/ can we simple measure with JMH x86 and arm our realization vs system call? As Dmitry P mentioned System.currentTimeMillis() is JVM intrinsic. Moreover, there is a daemon thread that updates

Re: IgniteUtils#currentTimeMillis

As Dmitry P mentioned System.currentTimeMillis() is JVM intrinsic. Moreover, there is a daemon thread that updates the internal value which will not be needed after the change. If we remove U.currentTimeMillis() code will become more clear and consistent. Why we think that we can implement this

Re: IgniteUtils#currentTimeMillis

Nikolay, As far as I understand U.currentTimeMillis() should be used where time is not a major value (metrics for example). But in test with transaction (that you are mentioned) we should use System.currentTimeMillis(). In general we should think about U.currentTimeMillis() and avoid it usage

Re: IgniteUtils#currentTimeMillis

In short, the reason is avoiding potential performance problems. On Wed, Aug 9, 2017 at 3:49 PM, Николай Ижиков wrote: > Dmitry, > > > So, if you change the call to System.currentTimeMillis(), the test > passes? > > Yes > > > I would propose to either increase TX_TIMEOUT

Re: IgniteUtils#currentTimeMillis

Dmitry, > So, if you change the call to System.currentTimeMillis(), the test passes? Yes > I would propose to either increase TX_TIMEOUT or sleep multiplier to make test more reliable. Yes, I fix test in that way. For me the goal of this discussion is to understand reasons to keep current

Re: IgniteUtils#currentTimeMillis

On Wed, Aug 9, 2017 at 5:32 AM, Николай Ижиков wrote: > Vladimir, > > As far as I can understand behaviour of U.currentTimeMillis() breaks > transaction timeout test: > So, if you change the call to System.currentTimeMillis(), the test passes?

Re: IgniteUtils#currentTimeMillis

ut this issue. But do we know if it is still actual > for > > > new > > > > > > VMs? > > > > > > > > > > > > ср, 9 авг. 2017 г. в 14:50, Dmitry Pavlov <dpavlov@gmail.com > >: > > > > > > > > > &g

Re: IgniteUtils#currentTimeMillis

; > > means > > > > > > on modern JVMs performance penalty will not be so significiant. > > > > > > > > > > > > Nickolay, could you please raise standalone ticket for > > > > > U.currentTimeMillis > > > > > > (

Re: IgniteUtils#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 r

Re: IgniteUtils#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 sui

Re: IgniteUtils#currentTimeMillis

ase 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 &

Re: IgniteUtils#currentTimeMillis

3 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, Ign

Re: IgniteUtils#currentTimeMillis

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

Re: IgniteUtils#currentTimeMillis

se/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 h

Re: IgniteUtils#currentTimeMillis

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

Re: IgniteUtils#currentTimeMillis

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 <yzhda...@apache.org> wrote: > Nickolay, IgniteUtils#currentTimeMillis() is some kind of an old heritage. > I guess nobody remembers when this method has been introdu

Re: IgniteUtils#currentTimeMillis

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

Re: IgniteUtils#currentTimeMillis

Addition to my previous message: 1. IgniteUtils#currentTimeMillis used in current master to check transaction timeout: https://github.com/apache/ignite/blob/master/modules/ core/src/main/java/org/apache/ignite/internal/processors/cache/transactions/ IgniteTxAdapter.java#L664 2. According to jdk

IgniteUtils#currentTimeMillis

Hello, Igniters. I found unusual implementation of IgniteUtils#currentTimeMillis function. Method is not simple proxy to System.currentTimeMillis Instead it read static variable which updated by dedicated thread: https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache