Re: svn commit: r485536 - /incubator/wicket/trunk/wicket/src/main/java/wicket/Resource.java

[Jean-Baptiste Quenot <jb...@apache.org>]

* ehillenius@apache.org:
> Author: ehillenius
> Date: Sun Dec 10 23:19:58 2006
> New Revision: 485536
> 
> URL: http://svn.apache.org/viewvc?view=rev&rev=485536
> Log:
> WICKET-155
> 
> Modified:
>     incubator/wicket/trunk/wicket/src/main/java/wicket/Resource.java
> 
> Modified: incubator/wicket/trunk/wicket/src/main/java/wicket/Resource.java
> URL: http://svn.apache.org/viewvc/incubator/wicket/trunk/wicket/src/main/java/wicket/Resource.java?view=diff&rev=485536&r1=485535&r2=485536
> ==============================================================================
> --- incubator/wicket/trunk/wicket/src/main/java/wicket/Resource.java (original)
> +++ incubator/wicket/trunk/wicket/src/main/java/wicket/Resource.java Sun Dec 10 23:19:58 2006
> @@ -18,6 +18,7 @@
>  
>  import java.io.OutputStream;
>  import java.net.SocketException;
> +import java.sql.SQLException;
>  import java.util.Map;
>  
>  import org.apache.commons.logging.Log;
> @@ -254,26 +255,32 @@
>  			boolean ignoreException = false;
>  			while (throwable != null)
>  			{
> -				if (throwable instanceof SocketException)
> +				if (throwable instanceof SQLException)
> +				{
> +					break; // leave false and quit loop
> +				}
> +				else if (throwable instanceof SocketException)

Hi Eelco,

I didn't necessarily follow the whole debate, but I wonder why you
have to catch  an SQLException in Wicket code!  Do  you assume the
Wicket application retrieves data from an SQL database?

FWIW here is the code used in Cocoon, it's another half-baked hack
that also analyzes the error message:

        // Check if the client aborted the connection
        if (e instanceof SocketException) {
            if (e.getMessage().indexOf("reset") > -1
                    || e.getMessage().indexOf("aborted") > -1
                    || e.getMessage().indexOf("connection abort") > -1) {
                throw new ConnectionResetException("Connection reset by peer", e);
            }
        } else if (e instanceof IOException) {
            // Tomcat5 wraps SocketException into ClientAbortException which extends IOException.
            if (e.getClass().getName().endsWith("ClientAbortException")) {
                throw new ConnectionResetException("Connection reset by peer", e);
            }
        }
-- 
     Jean-Baptiste Quenot
aka  John Banana   Qwerty
http://caraldi.com/jbq/

Re: svn commit: r485536 - /incubator/wicket/trunk/wicket/src/main/java/wicket/Resource.java

[Eelco Hillenius <ee...@gmail.com>]

> That code won't work for Jetty 6 (on a unix like platform at least),
> as it throws a SocketException with message "Broken pipe".

In fact, it throws a EofException (extends IOException), with a
SocketException nested. I take it that you loop through the nested
exceptions as well in Cocoon?

Eelco

Re: svn commit: r485536 - /incubator/wicket/trunk/wicket/src/main/java/wicket/Resource.java

[Eelco Hillenius <ee...@gmail.com>]

> Hi Eelco,
>
> I didn't necessarily follow the whole debate, but I wonder why you
> have to catch  an SQLException in Wicket code!  Do  you assume the
> Wicket application retrieves data from an SQL database?

It's actually the opposite: we *don't* want to catch SQL exceptions,
*but* SQL exceptions is one area where we know for sure that socket
exceptions may occur.

> FWIW here is the code used in Cocoon, it's another half-baked hack
> that also analyzes the error message:
>
>         // Check if the client aborted the connection
>         if (e instanceof SocketException) {
>             if (e.getMessage().indexOf("reset") > -1
>                     || e.getMessage().indexOf("aborted") > -1
>                     || e.getMessage().indexOf("connection abort") > -1) {
>                 throw new ConnectionResetException("Connection reset by peer", e);
>             }
>         } else if (e instanceof IOException) {
>             // Tomcat5 wraps SocketException into ClientAbortException which extends IOException.
>             if (e.getClass().getName().endsWith("ClientAbortException")) {
>                 throw new ConnectionResetException("Connection reset by peer", e);
>             }
>         }

That code won't work for Jetty 6 (on a unix like platform at least),
as it throws a SocketException with message "Broken pipe". Which shows
how incredible fragile this way of filtering exceptions is in the
first place. And - at least theoretically - you could be ignoring SQL
exceptions that have an underlying SocketException or even wholly
unrelated exceptions (like when you pull data from a web service or
such).

I'm not sure what *would* be the best solution. But so far, it all stinks.

Eelco

>      Jean-Baptiste Quenot
> aka  John Banana   Qwerty
> http://caraldi.com/jbq/
>