axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <stev...@iseran.com>
Subject Re: SOAP stacktrace
Date Thu, 17 Oct 2002 20:29:09 GMT

----- Original Message -----
From: "Jeff Greif" <jgreif@alumni.princeton.edu>
To: <axis-dev@xml.apache.org>
Sent: Thursday, October 17, 2002 1:14 PM
Subject: Re: SOAP stacktrace


> Another data point at the other end of the scale:
> The Amazon web service reports "bad request" either when you supply the
> search category as 'book' rather than 'books', but also when your SOAP
> message is completely garbled.

yeah, that sounds like crossing over from the 'provide no clues for people
trying to break in' has devolved to 'provide no clues to people trying to
debug'


>
> Something in between a stack trace and a message like this is needed for
> clients.  The approaches discussed below seem a good start.
>
> Jeff

my own experience is strongly in favour of including server identity info,
so when one jvm in a cluster gets wedged, you can find out which one it is
from the support call itself:

http://www.iseran.com/Steve/papers/when_web_services_go_bad.html

Another thing that raised a call one day was the customers saying 'you are
sending back bad xml'.

"How so," we ask?
"Our side is getting XML parser errors"
"can we get a full trace".
... a full trace comes back, with enough info to determine that the xml
parser is barfing on trying to read the HTML coming from the IIS 404.html
error page. Except we werent running our service on IIS, which caused much
confusion till we resolved that they were using a URL pointing to a
completely different machine, then complaining that our code didnt work.

The moral there is that there is a limit to what you can do server side;
client side diagnostics are helpful too :)

-steve


Mime
View raw message