[ 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)