Hi Sergey, Could you tell us a bit about the problem you're trying to solve?
In most deployments I would expect either a resolver cache, or a local caching DNS server. Either of these makes our InetAddress caching redundant. The InetAddress cache has a few problems: - it ignores the time-to-live (TTL) information provided by the DNS server; other caches usually cache the entries until the TTL expires, we have a fixed caching period. - it caches all negative lookup results for a fixed period of time; other caches cache NXDOMAIN replies which contain TTL information, and do not cache lookups that failed because of server and network errors - when the cache policy is set to NEVER, all requests for the same server are serialized - if 100 threads try to resolve the same server, 100 requests will be made one after another. However, with the default cache timeouts of 30/10 seconds, these problems are usually unnoticeable. I'd rather not extend the default caching periods; I've seen DNS responses with 30 second TTL, and if we cache the results longer than that, we might break someone's design. Regards, Daniel pt., 10 mar 2023 o 11:12 Sergey Bylokhov <bylok...@amazon.com> napisał(a): > > Hello > > I would like to discuss the possible improvement of the DNS cache which is > implemented in the shared > code in "InetAddress.java": > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/InetAddress.java#L923 > and controlled by the "InetAddressCachePolicy.java" > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/net/InetAddressCachePolicy.java#L32 > > At the moment this cache can be configured by the application using the > following two properties: > (1) "networkaddress.cache.ttl" - cache policy for successful lookups > (2) "networkaddress.cache.negative.ttl" - cache policy for negative lookups > > These properties are useful but have one limitation as the TTL value is > directly related to storing > the record in the cache. > > - If an application wants to always have up-to-date data, it can always > make requests to the > server. But in this case, "negative responses"/errors can break the > application. > - If an application wants to make fewer requests to the server, and the DNS > value changes rarely > it can set a long timeout. But obviously, this will lead to the record will > be rarely updated. And > if at the time of the update the failure happens - our cache will become > useless as we will cache a > negative response. > > It would be good to have benefits from both cases above without the negative > part. I propose to > implement the possibility to update/refresh entries in the cache periodically > without deleting them. > > This can be implemented by an additional property like > "networkaddress.extended.cache.ttl". > > Consider an example: the application may set the next values > "networkaddress.cache.ttl" = 60 and > "networkaddress.extended.cache.ttl" = 600. This will cache the record for 1 > minute and then, if the > next request is successful, re-cache the value for another 1 minute, and so > on. If the next request > is unsuccessful, it will fallback to the cached record for 9 minutes(10 > minutes from the last > successful lookup), and finally after a few attempts to update/re-cache the > value will be deleted > from the cache. > > Default behavior when this new property is not set will not be changed. > > Thoughts? > > -- > Best regards, Sergey.
