[
https://issues.apache.org/jira/browse/SLING-3498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14651765#comment-14651765
]
Bertrand Delacretaz commented on SLING-3498:
--------------------------------------------
Created SLING-4921 to handle the IOException "hiding"
> Don't log stacktrace on IOException
> -----------------------------------
>
> Key: SLING-3498
> URL: https://issues.apache.org/jira/browse/SLING-3498
> Project: Sling
> Issue Type: Bug
> Components: Engine
> Affects Versions: Engine 2.3.2
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Fix For: Engine 2.3.4
>
>
> The SlingMainServlet logs IOExceptions depending on the actual cause:
> {code}
> } catch (IOException ioe) {
> // unwrap any causes (Jetty wraps SocketException in
> // EofException)
> Throwable cause = ioe;
> while (cause.getCause() != null) {
> cause = cause.getCause();
> }
> if (cause instanceof SocketException) {
> // if the cause is a SocketException, the client most
> // probably
> // aborted the request, we do not fill the log with errors
> // in this case
> log.debug(
> "service: Socketexception (Client abort or network problem",
> ioe);
> } else {
> // otherwise we want to know why the servlet failed
> log.error(
> "service: Uncaught IO Problem while handling the request",
> ioe);
> }
> } ...
> {code}
> The idea is to try to find out, whether the IOException is caused by the
> client aborting the request or some other problem.
> NIO socket channels, though, don't throw SocketException but just IOException
> in this case, so this above code will always log an ERROR message with a
> stack trace. This message has no real use and we should change this and log
> the IOException as an INFO message (if at all) and at most dump the stack
> trace as a DEBUG message.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
