RFR: 8339538: Wrong timeout computations in DnsClient [v5]

[Aleksei Efimov]

On Tue, 10 Sep 2024 19:01:54 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> I agree that we don't want to document too much here. Updated the factor to 1.75 (2 seems a bit high and might hide real issues), and to make the timeout value calculation and check less arcane - I have updated test output to print the range of acceptable timeout values: 05ed9e053865293a1938ed7bc6fe208759513813
>
> 2 time  is not too high,
> I have presented, in the comment, a failures with the elapsed time is almost twice the expected time
> where the elapsed time is 14229 !! which is approx 1.84 * expected timeout

Let me try to summarize all timeout related test failures we've observed so far:

1. Observed timeout is less than expected/calculated one by a small quantity (250 ms or less). A failure example: `Failed: timeout in 7749 ms, expected 7750ms`. The possible reason: is the 50 ms tolerance (per retry) in DNS client implementation. Possible solutions: adjust test expectations to take the 50 ms into account OR remove the 50 ms tolerance (set it to 0).

2. Observed timeout is much higher than expected/calculated one by a signigicant amount. A failure example: `Failed: timeout in 14229 ms, expected 7750ms`. The possible reason: tests are run on a busy machines. Possible solution: update the max allowed timeout to be 2x expected/calculated.

3. Observed timeout is much less than expected/calculated one by a significant amount. A failure example: `Failed: timeout in 5786 ms, expected to be in a range (ms): 7505 - 13562`. The possible reason: If there is an exception observed inside the retry loop (inside `DnsClient.query` method) the timeout left from the interrupted attempt is not carried over to the next one, therefore the difference can be as huge as a duration of one of retry attempts. Possible solution: implement the carry over of the left timeout of an interrupted attempt to the next one (or restart the interrupted retry attempt). 

I will address the 1st and the 2nd scenarios now. And will start working on the 3rd one.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1754857360