On Thu, 10 Oct 2024 19:42:14 GMT, Roger Riggs <[email protected]> wrote:
>> I am keeping the timeout as 60 seconds. is this ok?
>>
>> @Test(timeOut=60000)
>> public void now() {
>> Instant expected, test;
>> long diff;
>> do {
>> expected = Instant.now(Clock.systemUTC());
>> test = Instant.now();
>> diff = Math.abs(test.toEpochMilli() - expected.toEpochMilli());
>> } while( diff > 100 ); // retry if more than 0.1 sec
>> }
>
> Yes, looks fine; The normal JTREG timeout is 2 minutes. 60 seconds is fine
> for the testng timeout.
FWIW - when I updated the System UTC clock to get sub-milliseconds resolution
from the OS I added this test:
https://github.com/openjdk/jdk/blob/master/test/jdk/java/time/test/java/time/TestClock_System.java
Maybe some similar technique could be used here. That is - take
System.currentTimeMillis(), Take Instant.now(), take System.currentTimeMillis()
again, and then verify that the instant lies between the two snapshots: greater
or equal to the first, less or equal to the second. That should always be true
(unless the UTC clock is adjusted by NTP). But you could hopefully detect that
and retry if you observe that the second call to System.currentTimeMillis() has
returned a value which is before the first call.
If the difference between the two System::curentTimeMillis calls is too big,
then if you wish you might want to try again too.
I believe this would provide a more robust test strategy.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21413#discussion_r1797211143
