Log as info exceptions from server after sending stop with StopMojo.

[janbartel]

Closes #9129

Catch and log at info level any exceptions from server after jetty StopMojo sends stop command.

[sbordet]

I would catch (Throwable) like we do elsewhere, but besides that LGTM.

[gsf-sellis]

I might go the other direction and only catch (SocketException), since we know it is expected and harmless. Anything else is unexpected and maybe should be propagated up the stack?

[janbartel]

I might go the other direction and only catch (SocketException), since we know it is expected and harmless. Anything else is unexpected and maybe should be propagated up the stack?

@gsf-sellis there's not much the plugin can do if there's any kind of exception thrown after we've sent the forcestop command. Depending on the configuration, the plugin will either exit straight away after sending the forcestop command, or - if we have been able to obtain the pid of the forked child ` - we will wait for the process to exit.

[gsf-sellis]

I'm just thinking in terms of keeping the catch block specific to the case that we know is harmless and that we can recover from. Anything else would be uncaught, propagated up the stack, and logged at a higher level than info (like the SocketException was before this PR). That said, however you all want to implement it is fine with me. Thanks for addressing the issue! I look forward to having clean logs again. :-)

[gsf-sellis]

I look forward to having clean logs again.

Oops I'm realizing now that info is the default log level, so that means this error will still appear in the logs?

I was hoping to maybe hide this error at the info level, since it is not really an error and makes the logs messy.

One option might be to catch SocketException and log it at debug or trace?

[janbartel]

I look forward to having clean logs again.

Oops I'm realizing now that info is the default log level, so that means this error will still appear in the logs?

I was hoping to maybe hide this error at the info level, since it is not really an error and makes the logs messy.

One option might be to catch SocketException and log it at debug or trace?

How about this: if debug is enabled we output the full stacktrace, otherwise we output an info with just the message?

[gsf-sellis]

That sounds great, thanks!

[gsf-sellis]

Maybe "Error" could be e.getMessage()? It's probably SocketException: Connection reset but could be something else.

[janbartel]

OK, how about the latest commit then?

[gsf-sellis]

Looks great! It's too bad we have to work around Windows TCP issues like this but it will be a quality of life improvement for me and others. Thanks!