Fix throttled reindex_from_remote

[nik9000]

reindex_from_remote was using TimeValue#toString to generate the
scroll timeout which is bad because that generates fractional
time values that are useful for people but bad for Elasticsearch
which doesn't like to parse them. This switches it to using
TimeValue#getStringRep which spits out whole time values.

Closes to #23945

Makes #23828 even more desirable.

[dakrone]

It seems strange that this is tested with a REST test, is there any way we could extract the scroll calculation into a (maybe static) method where it could be tested independently of the full reindex pipeline? (It'd also be good to keep the REST test too of course)

[nik9000]

I updated a unit test. I can change it if you like. I admit it is pretty perfunctory.

…

On Thu, Apr 6, 2017, 6:05 PM Lee Hinman ***@***.***> wrote: It seems strange that this is tested with a REST test, is there any way we could extract the scroll calculation into a (maybe static) method where it could be tested independently of the full reindex pipeline? (It'd also be good to keep the REST test too of course) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#23953 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANLolGqfgU-qInsIgky6WO0FJDlu6qIks5rtWGggaJpZM4M2Ggo> .

[dakrone]

Yeah, it'd be nice if there was something like

public void testCalculationThingys() throws Exception {
    assertThat(ReindexCalculationThing.calculateTime(90, TimeUnit.SECONDS), equalTo("2m")); // instead of "1.5m"
}

So this was a little more well encapsulated

[nik9000]

@dakrone I pushed some more changes - 2 unit test tweaks and another place where I was calling toString.

I can push a concrete (rather than randomized) example too if you'd like. Right now the scroll tests are still embedded with the rest of the request building tests. I think splitting them out would make the whole thing more brittle.

[dakrone]

LGTM, thanks for changing the tests

[nik9000]

Thanks for reviewing @dakrone!

[silashansen]

I think this has caused our remote reindexing to fail.
I am reindexing from 1.4.5 to 5.4.0 and I am now receiving this error:

"POST http://xxx.xxx.xxx.xxx:9200/_search/scroll?scroll=300000000000nanos: HTTP/1.1 400 Bad Request\n{\"error\":\"ElasticsearchParseException[Failed to parse [300000000000nanos]]; nested: NumberFormatException[For input string: \\\"300000000000nano\\\"]; \",\"status\":400}"

Indicating that our 1.4.5 server is not too happy about the "nanos".

Is there a workaround that can I can deploy until it's fixed?

[jasontedor]

@silashansen That's a duplicate of #24520.