axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "emerson cargnin" <>
Subject Re: Axis failing (with time out) but SOAPUI works
Date Thu, 18 Jan 2007 16:55:05 GMT
I found out that the problem is the load balances in one of the
servers, which doesn't accept HTTP 1.1. So, inside the stub i added:


which made its trick :)


On 18/01/07, emerson cargnin <> wrote:
> I have a web-service in two servers. One of then works fine from
> java/axis. The other service just gets a time-out. The problem is that
> both work well when I use SoapUI as the client.
> I then TCPMon'ed the calls and I found out that axis sent the request
> as chunked":
> So i presume one of the servers has its configuration to accept chunks
> and the other not. How can I configure axis to no send in chunks????
> Call from Java Code (Axis) that doesn't work:
> ------------------------------------------------------------------------------------------------------------------------
> POST /services/SapidSetting.asmx HTTP/1.1
> SOAPAction: ""
> User-Agent: Axis2
> Host:
> Transfer-Encoding: chunked
> Content-Type: text/xml; charset=UTF-8
> 203
> <?xml version='1.0' encoding='UTF-8'?><soapenv:Envelope
> xmlns:soapenv=""><soapenv:Header><ns1:authentication
> xmlns:ns1=""><userName>y123</userName><Password>xxx</Password></ns1:authentication></soapenv:Header><soapenv:Body><ns1:UpdateSapId
> xmlns:ns1=""><ns1:Input><username></username><SapId>1234</SapId></ns1:Input></ns1:UpdateSapId></soapenv:Body></soapenv:Envelope>
> 0
> --------------------------------------------------------------------------------------------------------------------
> For this request I get only this short answer:
> HTTP/1.1 100 Continue
> "Transfer-Encoding: chunked" header:
> Chunked Transfer Coding :The chunked encoding modifies the body of a
> message in order to transfer it as a series of chunks, each with its
> own size indicator, followed by an OPTIONAL trailer containing
> entity-header fields. This allows dynamically produced content to be
> transferred along with the information necessary for the recipient to
> verify that it has received the full message.
> 100 Continue: The client SHOULD continue with its request. This
> interim response is used to inform the client that the initial part of
> the request has been received and has not yet been rejected by the
> server. The client SHOULD continue by sending the remainder of the
> request or, if the request has already been completed, ignore this
> response. The server MUST send a final response after the request has
> been completed.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message