[
http://issues.apache.org/jira/browse/WICKET-155?page=comments#action_12457248 ]
Eelco Hillenius commented on WICKET-155:
----------------------------------------
The fix might actually be easier. What I missed was that in the case of this
Jetty exception there was actually a nested SocketException, but the message
was different than the ones checked on ('Broken pipe'). I scanned through the
JDK code a bit, and there are even more variations to be found, which might
vary between versions of the JDK and implementations (vendors) as well.
Here is an improvement implementation (hack rather) of Resource#respond that
checks whether this is a JDBC exception - which should never be ignored, but
may just as well be the cause of a socket exceptions - and if not, it checks on
a couple of more options than before. Another improvement is the break, which
was in the wrong spot in the old code.
catch (Exception e)
{
// FIXME this doesn't catch all. For instance, Jetty
(6/ NIO) on
// Unix like platforms will not be recogninzed as
exceptions
// that should be ignored
Throwable throwable = e;
boolean ignoreException = false;
while (throwable != null)
{
if (throwable instanceof SQLException)
{
break; // leave false and quit loop
}
else if (throwable instanceof SocketException)
{
String message = throwable.getMessage();
ignoreException = message != null
&&
(message.indexOf("Connection reset") != -1
||
message.indexOf("Broken pipe") != -1
||
message.indexOf("Socket closed") != -1
||
message.indexOf("connection abort") != -1);
}
else
{
ignoreException =
throwable.getClass().getName()
.indexOf("ClientAbortException") >= 0;
}
if (ignoreException)
{
if (log.isDebugEnabled())
{
log.debug("Socket exception
ignored for sending Resource "
+ "response to
client (ClientAbort)", e);
}
break;
}
throwable = throwable.getCause();
}
if (!ignoreException)
{
throw new WicketRuntimeException("Unable to
render resource stream "
+ resourceStream, e);
}
}
Personally, I think we shouldn't even try those strings as it is still darn
fragile if you ask me, but just bluntly ignore any SocketException that is not
an SqlException. Or can anyone come up with other obvious exceptions?
> Extend cases where the exception can be ignored due to an aborted request
> -------------------------------------------------------------------------
>
> Key: WICKET-155
> URL: http://issues.apache.org/jira/browse/WICKET-155
> Project: Wicket
> Issue Type: Improvement
> Affects Versions: 2.0, 1.3, 1.2.4
> Reporter: Eelco Hillenius
> Assigned To: Johan Compagner
>
> We should either find more specific catches in Resource#respond or come up
> with some other way to ensure we can recognize a client abortion. For
> instance, Jetty 6 on unix-like platforms (tested here on OpenBSD/ OSX) throws
> EofExceptions which extend IOExceptions and thus are not marked as ignorable.
> The problem then is that a stack trace will be printed in
> ComponentResourceRequestTarget, and as many production systems will have some
> trigger installed that sends an error message/ SMS/ ... that can be quite
> annoying.
> Can't we instead of looking at the exception somehow look at the request/
> response itself to figure out that a request was aborted? If that is
> possible, that seems like a much more robust way of solving this.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
