Response message socket closed prematurely

[bu...@us.ibm.com]

Take the following code snippet from SimpleAxisWorker.run:

            // ... 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:

<failure message="Remote Exception caught: (0)" type="junit.framework.
AssertionFailedError">junit.framework.AssertionFailedError: Remote
Exception caught: (0)
      at test.wsdl.attachments.AttachmentTestCase.
test6AttachmentPortRPCInoutMimeMultipart(AttachmentTestCase.java:120)
</failure>

The server-side exception IS supposedly logged so perhaps we shouldn't
bother doing anything.  That's the miminal approach.  A better notion would
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 to
the client.  Any opinions?  Thoughts about how to do the best notion?

Russell Butek
butek@us.ibm.com

Re: Response message socket closed prematurely

[Steve Loughran <st...@iseran.com>]

----- Original Message -----
From: <bu...@us.ibm.com>
To: <ax...@xml.apache.org>
Sent: Wednesday, August 14, 2002 5:38 AM
Subject: Response message socket closed prematurely


> Take the following code snippet from SimpleAxisWorker.run:
>
>             // ... 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
IOException.

How about

a) differentiate between IOE and other exceptions...


catch(IOException ioe)  {
             log.debug(JavaUtils.getMessage("exception00"), e);
    }
catch(Exception e) {
    out.write("<trouble>")
}



> The server-side exception IS supposedly logged so perhaps we shouldn't
> bother doing anything.  That's the miminal approach.  A better notion
would
> 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
to
> 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.