Hey Jeff,
nicely done - one can certainly not do without experimenting and
analyzing the "line"
into and out of servers/clients to find out what is going on. And what
you listed below
can certainly help me. In fact I did suspect that
I do get extraneous characters from these engines as my socket
monitoring loops
spit out nulls before and after the messages. In any case, there is
nothing much in the
code to see now, it is a simple client sitting listening to a port on
the localhost while
the Axis stubs write to that port with the service call. Once the SOAP
arrives I capture
it, I feed it manually to the server Axis on another machine, capture
the output and
then feed it manually back in the waiting client. Sometimes depending on
how I
send the headers or the SOAP body the client will block and only if I
kill the response
sending process the client will come back with the Connection Refused
message -
otherwise if I add a CR or an LF to the mix then the client will instead
give me either
a SAX parsing error without blocking or it will give me No Content
allowed in trailing
section - for this in fact I found some postings on it that do seem to
touch on the issue
of how the client works and why it blocks:
http://www.nabble.com/Content-is-not-allowed-in-trailing-section-tf75635.html#a205589
In any case, this reveals that I am not sending something that the
client excepts like
you very correctly pointed out but I am not doing anything fancy - I get
the post,
I retrieve the headers and everything else around them and I send them
over. And
as you could see my SOAP response that I feed back into the client resembles
very much the SOAP response you captured in the tcpmon (which by the way I
installed and I am playing with).
Anyway - once again - fantastic job in responding man and I
appreciate it
and I will certainly let you know what I find out later on today.
Cheers
Walker, Jeff wrote:
Hi,
Well, of course without looking at your code and setup, I can't really
help much.
All I can say is, I tried to simulate the stopping of the server. Here's
what I did:
1. I have a basic example web service up and running. The service runs
on WebSphere 6.0, the client is actually a small Java program running on
Eclipse 3.2, but they both exist on the same physical machine. I also
run org.apache.axis.utils.tcpmon to watch the request and response msgs
going bck and forth.
2. I placed a breakpoint in one of my service methods, and started the
server in debug mode.
3. I started the client and made a call to the web service.
4. The breakpoint in the service was hit. I looked at tcpmon and can see
the request that went to the server. The text area that shows the
response was as expected, totally, empty. At the client, it is
blocked-waiting for the response.
5. At this point, I stopped the debugger, which basically kills the
whole service.
6. Not sure exactly where it comes from, but it looks like the service
(Axis?) throws this response back to the lcient:
java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
...
I can see this clearly in tcpmon. The client receives that response and
that causes a RemoteException to pop up in my client. The text is:
Caught a RemoteException when retrieving data: (0)null
So, how does this help?
Well, I didn't see any of those strange characters that preceded and
followed the request/response you showed in one of your emails.
Admittely, my web service does minimal parsing of the xml, but it shows
that the client is blocked-waiting for a response. If it fails to get a
correct one, you either get a timeout, a RemoteException or SOAP Fault.
I killed the debugging session, and the client received the "connection
refused .." response which was interpreted as a RemoteException. I
cannot see how your getting a SAX parsing error, if the client should be
blocked-waiting on your response. (You never mention that you may be
doing asynchronous web service calls, so I am assuming your doing
synchronous calls).
I can only conclude that some part of your setup is very non-standard.
It seems like the service is not a real web service. At this point, you
need to see exactly what is being sent from the client, and what is
being sent back from your simulated service, in normal expected
situation and when you kill the service. I would recommend using Axis's
tcpmon because it is very easy to setup, but it 'may' clean up certain
extraneous characters, and so a line sniffer would be better, but
obviously way more dificult to get a hold of and setup.
Good luck!
-jeff
-----Original Message-----
From: Demetris G [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 21, 2007 6:46 PM
To: [email protected]
Subject: Re: SOAP response
One thing I noticed is that if I kill the server response process that
is forwarding the SOAP
response to the client, the client spits out the message that there was
a SAX Parser
exception - Content cannot be in trailing section ?? That makes no sense
- here is the
complete response that is very similar to Jeff's - to make this a bit
readable I am showing
only part of the soap body:
HTTP/1.1 200 OK
MIME-Version: 1.0
Content-Type: text/xml; charset=utf-8
Server: The Knopflerfish HTTP Server
Connection: Close
Date: Thu, 21 Jun 2007 20:31:44 GMT
<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";
xmlns:xsd="http://www.w3.org/2001/XMLSchema";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";><soapenv:Body><ns1
:getBundlesResponse
soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/";
xmlns:ns1="http://soapobject.bundle.knopflerfish.org";><getBundlesReturn
soapenc:arrayType="xsd:long[24]" xsi:type="soapenc:Array"
...
</soapenv:Body></soapenv:Envelope>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
