On Mon, 9 Sep 2024 17:15:43 GMT, Aleksei Efimov <aefi...@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
