On Wed, 10 May 2023 21:58:52 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:

>> I would like to get preliminary feedback about the provided patch.
>> 
>> Discussion on net-dev@ 
>> https://mail.openjdk.org/pipermail/net-dev/2023-March/020682.html
>> 
>> One of the main issue I try to solve is how the cache handle the 
>> intermittent DNS server outages due to overloading or network connection.
>> 
>> At the moment this cache can be configured by the application using the 
>> following two properties:
>>    (1) "networkaddress.cache.ttl"(30 sec) - cache policy for successful 
>> lookups
>>    (2) "networkaddress.cache.negative.ttl"(10 sec) - cache policy for 
>> negative lookups
>> 
>> The default timeout for positive responses is good enough to "have recent 
>> dns-records" and to "minimize the number of requests to the DNS server".
>> 
>> But the cache for the negative responses is problematic. This is a problem I 
>> would like to solve. Caching the negative response means that for **10** 
>> seconds the application will not be able to connect to the server.
>> 
>> Possible solutions:
>>   1. Decreasing timeout "for the negative responses": unfortunately more 
>> requests to the server at the moment of "DNS-outage" cause even more issues, 
>> since this is not the right moment to load the network/server more.
>>   2. Increasing timeout "for the positive responses": this will decrease the 
>> chance to get an error, but the cache will start to use stale data longer.
>>   3. This proposal: it would be good to ignore the negative response and 
>> continue to use the result of the last "successful lookup" until some 
>> additional timeout.
>> 
>> The idea is to split the notion of the TTL and the timeout used for the 
>> cache. When TTL for the record will expire we should request the new data 
>> from the server. If this request goes fine we will update the record, if it 
>> fails we will continue to use the cached date until the next sync.
>> 
>> For example, if the new property "networkaddress.cache.extended.ttl" is set 
>> to 10 minutes, then we will cache a positive response for 10 minutes but 
>> will try to sync it every 30 seconds. If the new property is not set then as 
>> before we will cache positive for 30 seconds and then cache the negative 
>> response for 10 seconds.
>> 
>> 
>> RFC 8767 Serving Stale Data to Improve DNS Resiliency:
>> https://www.rfc-editor.org/rfc/rfc8767
>> 
>> Comments about current and other possible implementations:
>>  * The code intentionally moved to the separate ValidAddresses class, just 
>> to make clear that the default configuration, when the new property is not 
>> set is not changed much.
>>  * The refr...
>
> Sergey Bylokhov has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Michael McMahon 
> <70538289+michael-mc-ma...@users.noreply.github.com>

The CSR is updated, please take a look.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13285#issuecomment-1549970700

Reply via email to