Clarify the use of sleep in CCR test

Sleeps in tests smell funny, and we try to avoid them to the extent
possible. We are using a small one in a CCR test. This commit clarifies
the purpose of that sleep by adding a comment explaining it. We also
removed a hard-coded value from the test, that if we ever modified the
value higher up where it was set, we could end up forgetting to change
the value here. Now we ensure that these would move in lock step if we
ever maintain them later.
This commit is contained in:
Jason Tedor 2019-02-21 14:04:01 -05:00
parent 719c38a36d
commit b9f8be6968
No known key found for this signature in database
GPG Key ID: FA89F05560F16BC5
1 changed files with 16 additions and 1 deletions

View File

@ -337,8 +337,23 @@ public class CcrRetentionLeaseIT extends CcrIntegTestCase {
} }
}); });
/*
* We want to ensure that the background renewal is cancelled at the end of recovery. To do this, we will sleep a small multiple
* of the renew interval. If the renews are not cancelled, we expect that a renewal would have been sent while we were sleeping.
* After we wake up, it should be the case that the retention leases are the same (same timestamp) as that indicates that they were
* not renewed while we were sleeping.
*/
final TimeValue renewIntervalSetting = CcrRepository.RETENTION_LEASE_RENEW_INTERVAL_SETTING.get(
followerClient()
.admin()
.indices()
.prepareGetSettings(followerIndex)
.get()
.getIndexToSettings()
.get(followerIndex));
final long end = System.nanoTime(); final long end = System.nanoTime();
Thread.sleep(Math.max(0, randomIntBetween(2, 4) * 200 - TimeUnit.NANOSECONDS.toMillis(end - start))); Thread.sleep(Math.max(0, randomIntBetween(2, 4) * renewIntervalSetting.millis() - TimeUnit.NANOSECONDS.toMillis(end - start)));
// now ensure that the retention leases are the same // now ensure that the retention leases are the same
assertBusy(() -> { assertBusy(() -> {