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

[Aleksei Efimov]

On Mon, 9 Sep 2024 17:15:43 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> I have been wondering why the timeout was measured in this way. My explanation was that the original author of the API (duke? ;-) ) wanted to measure "actual timeout" (time actually spent waiting for a packet) as opposed to perceived timeout (time the caller spent waiting). Rationale might have been to exclude potential time spent waiting for a lock before entering receive() - for instance. That said - I'm not opposed to extend the scope of the timeout to make it closer to the perceived timeout, which is what the test expect. 
>> If we do this maybe we could move `start` out of the `do` block  - which would make the computation of `timeoutLeft` simpler (we wouldn't need the `-=`).
>
> I think that "the perceived timeout" described by you above is closer to the following description of the timeout environment property:
> ```The provider submits a query to a DNS server and waits for a response to arrive within a timeout period (1 second by default)```
> And the query is submitted to a DNS server right before entering the while loop.
> I will apply the suggested simplification of the timeout left now, thanks.

The code now measures "the perceived timeout": [4d33d05](https://github.com/openjdk/jdk/pull/20892/commits/4d33d05b111f38a418dac57587236465f2359f8c)
The timeout JNDI/DNS tests seem to be stable and a bit more accurate across multiple runs with the latest changes.

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

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