Fix RecoveryState timestamps

[masaruh]

Use System.currentTimeMillis() instead of System.nanoTime() since it's for wall clock time.
Fixes #11870.

[bleskes]

@masaruh talked a bout using System.currentTimeMillis for the time markers and nano time for the delta.

[mikemccand]

If this goes back to 1.x, I think we have to conditionalize this by version?

[masaruh]

Will do.

[mikemccand]

Sorry, I caused this with #11058! I didn't realize we were also using the absolute msec values against a calendar (not just for elapsed msec).

[masaruh]

So, backport would look like this? masaruh@4ecd530

[bleskes]

Are we sure we can use lessThanOrEqualTo here? we can also just assert that time() > 0 imho.

[masaruh]

I think lessThanOrEqualTo is correct. (because it's rounded down to nearest decimal value)

If we use nano seconds, when start time is 1ns and stop time is 1000000ns (1ms), time() would be 99999ns but it's 0ms because of TimeValue.nsecToMSec.
But if we use milliseconds, above becomes 1ms - 0ms = 1ms. In this case, time() < stop() - start().
When start time is 1ns (0ms) and stop time is 1999999ns (1ms), it's 1999998ns but time() will be 1ms and stop() - start() = 1ms.

That's said, I like time() > 0 since it makes it simpler.

[bleskes]

I see what your are saying but I don’t think we can rely on this. The nanoTime() is not guaranteed to actually have nano precision (just resolution). it is only guaranteed to never go back…

On 29 Jun 2015, at 10:39, Masaru Hasegawa notifications@github.com wrote:

In core/src/test/java/org/elasticsearch/indices/recovery/RecoveryStateTest.java:

@@ -154,7 +154,7 @@ public void run() {
if (randomBoolean()) {
timer.stop();
assertThat(timer.stopTime(), greaterThanOrEqualTo(timer.startTime()));

•        assertThat(timer.time(), equalTo(timer.stopTime() - timer.startTime()));
  

•        assertThat(timer.time(), lessThanOrEqualTo(timer.stopTime() - timer.startTime()));
  

I think lessThanOrEqualTo is correct. (because it's rounded down to nearest decimal value)

If we use nano seconds, when start time is 1ns and stop time is 1000000ns (1ms), time() would be 99999ns but it's 0ms because of TimeValue.nsecToMSec.
But if we use milliseconds, above becomes 1ms - 0ms = 1ms. In this case, time() < stop() - start().
When start time is 1ns (0ms) and stop time is 1999999ns (1ms), it's 1999998ns but time() will be 1ms and stop() - start() = 1ms.

That's said, I like time() > 0 since it makes it simpler.

—
Reply to this email directly or view it on GitHub.

[masaruh]

Oh, I see. time() > 0 is definitely better then!

[bleskes]

Thx @masaruh . Looks great - I left one question about the test and a simple comment on the backport (which looks good).

[masaruh]

Thanks @bleskes. Changed test to use >= 0. Since it can be 0ms when it's done really quick.

[bleskes]

are you sure a 0 is possible? see https://github.com/elastic/elasticsearch/pull/11871/files#diff-064f839a8d24936e06aeb470ef25c9faR149

[masaruh]

Ah right. That one should have been greaterThan. But I believe another one https://github.com/elastic/elasticsearch/pull/11871/files#diff-064f839a8d24936e06aeb470ef25c9faR289 can be 0.

[masaruh]

Pushed another fix.

[bleskes]

awesome. LGTM

[masaruh]

@bleskes thanks, also pushed to 1.x and 1.6.