4 ms·
This mirrors my experience. I've seen more problems caused by the JVM, by default on some configurations, caching DNS indefinitely, regardless of TTL, than cau
by jamescun 6y ago
This mirrors my experience.
I've seen more problems caused by the JVM, by default on some configurations, caching DNS indefinitely, regardless of TTL, than caused by a short TTL.
- icedchai 6y agoDefinitely. About 12+ years ago, I had to prove to a vendor, with tcpdumps, etc., that they were connecting to the wrong server after we changed a DNS entry. 3 of their systems were working, the 4th hadn't been restarted and was connecting to the old address. Very frustrating.
- axaxs 6y agoIs that fixed yet? I remember having to bounce Java apps every time DNS changed, which never made sense to me. It's literally the point of DNS to not have to do that.
- icedchai 6y agoIt's fixed in newer JVMs ("newer" meaning anything in the past 10 years.)
- squiggleblaz 6y agoBut that isn't the issue at question. If the TTL is 300 seconds or 3600 seconds and the JVM holds onto it for three weeks, you can't blame a TTL of 3600 seconds for that, and setting the TTL down to 0 seconds at all isn't going to fix it either (unless, bizarrely, the JVM developers decided to respect TTLs of 0-60 and treat all other values as infinite).