This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author bmerry
Recipients bmerry, eric.smith
Date 2022-03-29.20:01:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1648584078.37.0.0806611863753.issue47149@roundup.psfhosted.org>
In-reply-to
Content
> Hmm. I'm not sure we should try to work around a bad resolver issue. What's your platform, and how did you install Python?

Fair point. It's Ubuntu 20.04, running inside Docker, with the default Python (3.8). I've also reproduced it outside Docker (again Ubuntu 20.04 with system Python). The TTL is 30s, so I'm not sure why systemd-resolved isn't caching it for messages logged several times a second.

Even if the system has a local cache though, it's not ideal to have logging block when the TTL expires, particularly in an event-driven (asyncio) service. Updating the address in a background thread while continuing to log to the old address might be better. But my use case is particularly real-time (even 10ms of latency is problematic), and maybe that shouldn't drive the default behaviour.

I blame the lack of standard POSIX functions for doing DNS lookups asynchronously and in a way that provides TTL information to the client.
History
Date User Action Args
2022-03-29 20:01:18bmerrysetrecipients: + bmerry, eric.smith
2022-03-29 20:01:18bmerrysetmessageid: <1648584078.37.0.0806611863753.issue47149@roundup.psfhosted.org>
2022-03-29 20:01:18bmerrylinkissue47149 messages
2022-03-29 20:01:18bmerrycreate