Skip to content

feat(request_forwarder): Add config option to set DNS cache TTL - #312

Merged
ketiltrout merged 1 commit into
chime-upgradefrom
dvw/dns_caching
Oct 6, 2026
Merged

ketiltrout merged 1 commit into
chime-upgradefrom
dvw/dns_caching

Conversation

@ketiltrout

Copy link
Copy Markdown
Member

Adds an optional config parameter "dns_cache_ttl" to allow changing the AIOHTTP DNS caching time. The default TTL in coco is 10 seconds, which is also AIOHTTP's default value for this parameter.

There's a bigger change here, though:

  • previoiusly coco would create a new connector (which is the object containing the DNS cache) for each endpoint forward. This connector would last until the end of a single endpoint forward at which point it would be closed and the cache deleted. Theoretically, the DNS cache could have been used if an endpoint had multiple forwards to the same host but, in practice, that's not how our endpoints usually work. (Typically a given endpoint forwards only once to a particular host.) The upshot is, in old coco, the DNS cache was essentially unused.
  • To fix this, the connector is now cached in the RequestForwarder itself and reused over-and-over again. I think this should be fine, but it will need some field testing to see if there's unintended consequences.

If "dns_cache_ttl" is set to zero, DNS caching will be explicitly disabled in the request forwarder, which (due to the above) is effectively the legacy behaviour.

Also, merged the RequestForwarder.set_session_limit function into RequestForwarder.__init__ since it was only ever called immediately after creating the request forwarder. If there was a reason to have these separate in the past, that's no longer the case.

A re-implementation of #243 now that the test-suite works again.

Adds an optional config parameter "dns_cache_ttl" to allow
changing the AIOHTTP DNS caching time.  The default TTL in coco
is 10 seconds, which is also AIOHTTP's default value for this
parameter.

There's a bigger change here, though:
* previoiusly coco would create a new connector (which is the object
  containing the DNS cache) for each endpoint forward.  This connector
  would last until the end of a single endpoint forward at which point
  it would be closed and the cache deleted.  Theoretically, the DNS
  cache could have been used if an endpoint had multiple forwards to
  the same host but, in practice, that's not how our endpoints usually
  work.  (Typically a given endpoint forwards only once to a particular
  host.)  The upshot is, in old coco, the DNS cache was essentially
  unused.
* To fix this, the connector is now cached in the RequestForwarder
  itself and reused over-and-over again.  I think this should be fine,
  but it will need some field testing to see if there's unintended
  consequences.

If "dns_cache_ttl" is set to zero, DNS caching will be explicitly
disabled in the request forwarder, which (due to the above) is
effectively the legacy behaviour.
@ketiltrout
ketiltrout merged commit 0a7d9d8 into chime-upgrade Oct 6, 2026
5 checks passed
@ketiltrout
ketiltrout deleted the dvw/dns_caching branch October 6, 2026 21:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants