axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: Response message socket closed prematurely
Date Wed, 14 Aug 2002 16:16:44 GMT

----- Original Message -----
From: <>
To: <>
Sent: Wednesday, August 14, 2002 5:38 AM
Subject: Response message socket closed prematurely

> Take the following code snippet from
>             // ... snip... a bunch of out.writes
>             responseMsg.writeTo(out);
>             out.flush();
>         } catch (Exception e) {
>             log.debug(JavaUtils.getMessage("exception00"), e);
>         } finally {
>             try {
>                 if (socket != null) socket.close();
>             } catch (Exception e) {
>             }
>         }
> This is the code that writes the response message.  Note that, if there is
> any problem writing this message, then the socket closes.  A potentially
> common problem would be if a serializer fails.  The reason for the
> serializer failure is never sent back to the client, so the client-side
> AXIS engine, when it gets the socket closed exception, throws a very
> uninformative exception:

This looks like standard socket code to handle trouble on the wire wherein
the client has closed the connection, so out.write() fails with an

How about

a) differentiate between IOE and other exceptions...

catch(IOException ioe)  {
             log.debug(JavaUtils.getMessage("exception00"), e);
catch(Exception e) {

> The server-side exception IS supposedly logged so perhaps we shouldn't
> bother doing anything.  That's the miminal approach.  A better notion
> be for the client to at least get a useful message that the socket closed
> prematurely.  The best notion, though I don't know how to do it
> efficiently, would be for the real server-side exception to make its way
> the client.  Any opinions?  Thoughts about how to do the best notion?

One problem with the streaming approach is that while users can sort of
handle an HTML page that suddenly drops into error half way through (though
I still hate ASP's poking HRESULTS out to users), XML parsers get totally
confused when bad things happen to the text. So if anything is already
written, there is no way to write an axis fault back or anything else.

View raw message