On Mon, 9 Sep 2024 15:03:46 GMT, Daniel Fuchs <dfu...@openjdk.org> wrote:
>> Sounds like a right thing to do: measuring time in the loop should give us >> better estimation on time DNS client spends waiting on the response after >> submiting a query (that's how environment property value is defined in >> [javadoc >> here](https://docs.oracle.com/en/java/javase/22/docs/api/jdk.naming.dns/module-summary.html)). >> I've tried to move `start` and `end` like: >> >> do { >> + long start = System.nanoTime(); >> <....> >> - long start = System.nanoTime(); >> gotData = blockingReceive(udpChannel, ipkt, >> timeoutLeft); >> - long end = System.nanoTime(); >> <...> >> + long end = System.nanoTime(); >> long elapsedMillis = TimeUnit.NANOSECONDS.toMillis(end >> - start); >> >> As a result the tests showed that the timeout happened with a bit better >> precision (10th of milliseconds). >> I will run more tests and incorporate the suggestions. Thank you. > > 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 entrering the while loop. I will apply the suggested simplification of the timeout left now, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1750628602
