Github user d2r commented on the issue:
https://github.com/apache/spark/pull/17500
@srowen
> Hm, why does this help? isn't it somehow trying to bind/close a port
that's already in use?
If the port is in use, then it will throw a BindException here, which will
be handled by logic in Spark code thereby avoiding logging a big stack trace in
the Jetty code following it.
Without this change, if the port is in use, then Jetty code will log the
exception with the full stack trace and then throw it.
In the case when the port is not used when entering this code, it is
possible but less likely that we will see the stack trace. The scenario in
which we would still see the stack trace is when the port is free before we
enter the Jetty code, but then it becomes unavailable before Jetty tries to
bind the port. It is a fairly tight race, but it could happen.
This change should hide the unhelpful stack trace a majority of the time.
> What about just trying to reduce the log level or otherwise squelch the
exception?
We did look for a way to do this, but options are limited as the code is in
Jetty.
Reducing the log level would be messy, and there are other log messages
from Jetty at the WARN level that are very helpful. Unfortunately adjusting the
log level dynamically here could hide useful information.
We actually do not want the exception squelched, we just want to avoid the
log message.
Sorry for the late response. I need to fix my notification settings.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
