RFR: 8304885: Reuse stale data to improve DNS resolver resiliency [v6]

[Sergey Bylokhov]

On Fri, 28 Apr 2023 11:00:31 GMT, Michael McMahon <michaelm at openjdk.org> 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