Skip to content

Commit d3004aa

Browse files
jcschaffclaude
andcommitted
Don't cache failed DNS lookups in the desktop client
When a laptop wakes from sleep, transient DNS resolution failures get cached by Java's InetAddress cache. Our continuous polling loop then hits the cached failure faster than the 10s default negative TTL can expire, wedging the client at "connecting…" until the user restarts it. The OS resolver is fine — `host vcell-dev.cam.uchc.edu` returns the correct IP — but the JVM never re-queries it. Set Security properties at the top of main(), before any DNS lookup: - networkaddress.cache.ttl=30 (modest positive cache, matches the non-SecurityManager default but makes it explicit and stable) - networkaddress.cache.negative.ttl=0 (never cache failures; recover immediately when DNS comes back) Asymmetric TTL is the established pattern for long-running JVMs that need to recover from transient DNS issues — see AWS SDK and Oracle networking-properties guidance. Programmatic Security.setProperty is the only reliable mechanism: -D JVM args don't bridge to security properties, and -Dsun.net.inetaddr.ttl is undocumented in modern Java. Observed in user log: >> polling failure << vcell-dev.cam.uchc.edu: nodename nor servname provided, or not known (repeating, after laptop sleep/wake) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1 parent 210bb01 commit d3004aa

1 file changed

Lines changed: 8 additions & 0 deletions

File tree

vcell-client/src/main/java/cbit/vcell/client/VCellClientMain.java

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -80,6 +80,14 @@ private VCellClientMain() {
8080
* @param args an array of command-line arguments
8181
*/
8282
public static void main(java.lang.String[] args) {
83+
// Recover gracefully when DNS lookups fail transiently (e.g. laptop wake from sleep).
84+
// Java's default 10s negative-result cache combined with our continuous polling loop
85+
// wedges the client at "connecting…" until restart, because the polling interval is
86+
// shorter than the cache TTL so the cached failure never expires. A short positive
87+
// TTL still gives reasonable cache locality without holding stale entries indefinitely.
88+
java.security.Security.setProperty("networkaddress.cache.ttl", "30");
89+
java.security.Security.setProperty("networkaddress.cache.negative.ttl", "0");
90+
8391
System.out.println("starting with arguments " + Arrays.asList(args));
8492
int exitCode = 1;
8593
try {

0 commit comments

Comments
 (0)