On Fri, 28 Apr 2023 11:00:31 GMT, Michael McMahon <[email protected]> wrote:
>> Sergey Bylokhov has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains 13 additional >> commits since the last revision: >> >> - Merge branch 'master' into JDK-8304885 >> - Merge remote-tracking branch 'upstream/master' into JDK-8304885 >> - Rename the classes and add the javadoc. >> - Merge branch 'master' into JDK-8304885 >> - documentation >> - PR feedback >> - Merge remote-tracking branch 'upstream/master' into JDK-8304885 >> - Use "maximum stale timer" instead of the extended timeout, and bump it on >> each successful lookup >> - the suggested cap is 7 days >> - simplify >> - ... and 3 more: https://git.openjdk.org/jdk/compare/0f472c3b...22a0bd01 > > src/java.base/share/classes/sun/net/InetAddressCachePolicy.java line 130: > >> 128: staleCachePolicy = (int) Math.max(tmp, max); >> 129: } >> 130: } > > Maybe there was discussion of this which I missed, but this seems to be > saying if the cache policy is less than seven days, then the stale policy is > set no less than seven days. What is the reason for that? I think it would > need to be documented if we stick with it. It is come from the recommendation in the "RFC 8767" see the notion about "cap of 7 days": https://www.rfc-editor.org/rfc/rfc8767 Depending on the final implementation I can document this, or delete it in the code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13285#discussion_r1180533897
