GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | ||||||||||||||||||||||||||||||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | ||||||||||||||||||||||||||||||||||
GeezerVison is showing github.com — doh: keep pooled conns shorter-lived than server idle-timeouts; h2 PING health-checks by ShiroiKuma0 · Pull Request #242 · celzero/firestack ConversationFixes #241.
With Quad9 (or any resolver whose idle timeout is under 3 minutes), every DNS lull longer than the server's idle window leaves the pool full of dead connections. The next queries are written into them, hang ~8–10 s, and surface as ChangeTwo adjustments in
TestingBuilt from source and run on-device (Android, v055x/v055y engines). Same device, same resolver (Quad9), driven with worst-case traffic — bursts of 10 parallel uncached queries after guaranteed > 30 s idle gaps, ~40 cycles over 33 min:
One caveat: with the PING enabled I saw a single rare
Sorry, something went wrong. Uh oh!
There was an error while loading. Please reload this page. All reactions…NG health-checks Some resolvers close idle DoH connections well under 30s (Quad9 measured at <=30s from the same LAN; Cloudflare survives >240s). With the 3m IdleConnTimeout, any DNS lull left only dead connections in the pool and subsequent queries were written into them, hanging ~10s and surfacing as 'Post ...: unexpected EOF' / http-status 502 bursts (maxEOFTries retries often just picked the next corpse). Downstream this expired alg mappings (realips([])), killed established flows of allowed apps, and failed the OS connectivity probes routed through the tunnel. - IdleConnTimeout 3m -> 10s: never reuse a connection older than the shortest observed server-side idle window. - http2.ConfigureTransports + ReadIdleTimeout/PingTimeout: actively evict half-dead h2 connections via PING instead of losing a query.
ignoramous
reviewed
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 10s seems too low. Perhaps this could be et to 30s instead?
Sorry, something went wrong. Uh oh!
There was an error while loading. Please reload this page. All reactions
ignoramous
reviewed
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not sure what these are required for. Just the 30s idle timeout seems sufficient...?
Sorry, something went wrong. Uh oh!
There was an error while loading. Please reload this page. All reactions
ignoramous
requested changes
|
There was an error while loading. Please reload this page.
|
Curious: Which model / agent did you use for this bug + commit? Also: Will you please make corresponding changes to |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
doh: pooled connections outlive resolver idle-timeouts — recurring "unexpected EOF" / 502 bursts (Quad9 kills idle conns at ≤30s vs 3m IdleConnTimeout)
There was an error while loading. Please reload this page.