On Tue, 10 Sep 2024 14:59:44 GMT, Daniel Fuchs <dfu...@openjdk.org> wrote:
>> test/jdk/com/sun/jndi/dns/ConfigTests/Timeout.java line 112: >> >>> 110: // Check that elapsed time is as long as expected, and >>> 111: // not more than 67% greater. Given the min DNS timeout >>> 112: // correction above the threshold value is equal to 61%. >> >> this is a bit arcane, why not have a simple measure that elapsed time >> shouldn't be more than twice the expected timeout ... this is not that >> different to the multipliedBy(2) and multipliedBy(3) -- >> elaspedTime.compareTo(expectedTime.multipliedBy(2) <= 0 >> >> Additionally based on the internal minimum timeout allowance of 50 secs and >> this upper bound calculation, it would suggest that an @implNote might be >> useful, or required, to alert developers to potential timeout variability, >> and not to rely on timeout to be absolutely (real time) precise > > I don't think we want to go down the rabbit hole of documenting too much. > Agreed that using a simple factor 2 would make the code simpler, but do we > want to go that high? I don't think it is a rabbit hole, to provide some additional clarity on the timeout mechanism and to avoid any perception that it is an absolute realtime timeout semantics, such that developers have precise view of how the mechanism works https://docs.oracle.com/en/java/javase/22/docs/api/jdk.naming.dns/module-summary.html ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20892#discussion_r1752422523
