New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Logging hostname at startup can take a prohibitively long time #32908
Comments
I would love to see this change in Spring Boot 3, I mean really! On Mac or some Cloud platforms resolving localhost DNS at startup can take a huge amount of time (including for native), so it seems to be much safer to avoid this friction point on both DevXP and Cloud deployments by default, and let people add the hostname or any other differentiator via the log aggregation system or via Logback configuration. That would be a much safer default, would make Spring Boot startup time more robust and predictive, while still allowing much more useful per lines differentiator use case via explicit configuration. |
I totally agree with your line of reasoning, Andy. |
Fine by me. |
Another option might be to look for |
A significant limitation is that on most Unix systems, So I guess the 2 options would be either:
|
We've decided to remove the hostname from the log message. |
StartupInfoLogger logs the result of calling
InetAddress.getLocalHost().getHostName()
. This call can take a long time as we've discussed in the past. That discussion concluded with us logging a warning when resolving the host name takes too long.With a new major release we have another option available to us: remove the hostname from the log message. I am in favour of doing so as I don't think it adds much value at the moment. If you're viewing the logs locally, knowing the hostname isn't useful. If you're viewing them remotely you presumably now where the logs came from. If you're viewing aggregated logs, having an identifier per log entry would be far more useful than mentioning the hostname in one entry which may have been lost long ago via a rollover.
The text was updated successfully, but these errors were encountered: