axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From krishna <kris...@lac.uic.edu>
Subject Re: timeout exception because of no Content-Length
Date Fri, 08 Jul 2005 13:58:41 GMT
Hi Samisa/All

I varied the timeout with the following values - 0,10,100,1000 -
and received the same amount of data in the SOAP-RESPONSE each time.

Cheers
Krishna

Samisa Abeysinghe wrote:

>Hi,
>	Even though the variable name used in the implementation is
>m_iContentLength, it has nothing to do with the HTTP Content-Length
>header. As Carsten has pointed out, there is no need to have the
>Content-Length HTTP header, if the message is chunked.
>	Our transport has been fixed to work with chunked data long time
>back and it has been working OK since then.
>	Please vary your time out and see if you get lager message with
>larger timeout, or if you get the same amount of message with different
>timeouts.
>	If you get larger message with larger timeout, then you can
>solve the problem by increasing the timeout. However, if that is not the
>case, then there may be a bug which we would have to dig into.
>
>Thanks,
>Samisa...
>
>-----Original Message-----
>From: Carsten Blecken [mailto:cblecken@macrovision.com] 
>Sent: Friday, July 08, 2005 4:37 AM
>To: Apache AXIS C Developers List
>Subject: RE: timeout exception because of no Content-Length
>
>Hi,
>
>if you are saying that the chunked code path depends on
>Content-Length to be set, then this is likely a bug in
>the code. The http spec does NOT require content-length
>to be set if transfer encoding is chunked. There a several
>app servers out there who use chunking (I know Jetty for
>sure) and no content length. The logic should be to look
>for 'Transfer-Encoding : chunked' first and only after 
>none was found to look for Content-length. 
>
>Carsten
>
>P.S> The relevant HTTP spec part -
>
>--------------------------------------------
>
>When a message-body is included with a message, the transfer-length of
>that body is determined by one of the following (in order of
>precedence):
>
>1.Any response message which "MUST NOT" include a message-body (such as
>the 1xx, 204, and 304 responses and any response to a HEAD request) is
>always terminated by the first empty line after the header fields,
>regardless of the entity-header fields present in the message.
>
>2.If a Transfer-Encoding header field (section 14.41) is present and has
>any value other than "identity", then the transfer-length is defined by
>use of the "chunked" transfer-coding (section 3.6), unless the message
>is terminated by closing the connection.
>
>3.If a Content-Length header field (section 14.13) is present, its
>decimal value in OCTETs represents both the entity-length and the
>transfer-length. The Content-Length header field MUST NOT be sent if
>these two lengths are different (i.e., if a Transfer-Encoding
>
>     header field is present). If a message is received with both a
>     Transfer-Encoding header field and a Content-Length header field,
>     the latter MUST be ignored.
>
>4.If the message uses the media type "multipart/byteranges", and the
>ransfer-length is not otherwise specified, then this self- elimiting
>media type defines the transfer-length. This media type UST NOT be used
>unless the sender knows that the recipient can arse it; the presence in
>a request of a Range header with ultiple byte- range specifiers from a
>1.1 client implies that the lient can parse multipart/byteranges
>responses.
>
>       A range header might be forwarded by a 1.0 proxy that does not
>       understand multipart/byteranges; in this case the server MUST
>       delimit the message using methods defined in items 1,3 or 5 of
>       this section.
>
>5.By the server closing the connection. (Closing the connection cannot
>be used to indicate the end of a request body, since that would leave no
>possibility for the server to send back a response.) 
>
>
>-----Original Message-----
>From: krishna [mailto:krishna@lac.uic.edu]
>Sent: Thursday, July 07, 2005 3:23 PM
>To: Apache AXIS C Developers List
>Subject: timeout exception because of no Content-Length
>
>
>Hi Samisa/Fred/All,
>
>Both the methods
>1. Using the stubObj to setTransportTimeout
>2. Calling setTimeout from the stub code
>
>Gave me the following error.
>
>Error
>HTTPTransportException:Input streaming error while getting data Timed 
>out waiting for SOAP message (1).
>
>My analysis showed that the code with for http chunking has 2 parts.
>1. For the initial chunk
>2. For the subsequent chunks
>
>It relies on the content length field to decide whether the current 
>chunk is the first chunk or not
>Please find the lines below from HTTPTransport.cpp
>
>if( m_strReceived.length () > 0)
>{
>627
>628 if( m_bChunked && m_iContentLength < 1) // Read first chunk
>629 {
>
>
>.......
>722 }
>723 else if( m_bChunked) // read continued portions of a chunk
>724 {
>
>As the SOAP - RESPONSE does not contain a Content-Length field. It keeps
>
>repeating the algorithm for the first chunk
>and lands in an exception.
>
>If my analysis is right then my question is why does the server not send
>
>a Content-Length field for chunked messages and how can this be 
>incorporated?
>
>Cheers
>Krishna
>
>Samisa Abeysinghe wrote:
>
>  
>
>>Well, without editing the generated code, you can change the user
>>    
>>
>code:
>  
>
>>stubObj->setTransportTimeout(30);//assuming the stub object is a
>>    
>>
>pointer
>  
>
>>Samisa...
>>
>>-----Original Message-----
>>*From:* Fred Preston [mailto:PRESTONF@uk.ibm.com]
>>*Sent:* Thursday, July 07, 2005 3:34 PM
>>*To:* Apache AXIS C Developers List
>>*Subject:* Re: how to set a timeout - update
>>
>>
>>Hi Krishna,
>>The IterationCountdown in the HTTPTransport::getBytes() method is not 
>>a timeout, but is used to catch a potential deadlock situation where 
>>the client is waiting for a response message from the server and the 
>>server either never or only partially responds. The timeout for the 
>>socket is set by HTTPTransport::setTimeout( long lSeconds). The 
>>default channel timeout is 10 seconds. To change the timeout you have 
>>to be able to call the setTimeout method. You cannot do this directly 
>>from the client application because it does not have access to the 
>>transport layer. You can however change the timeout at the generated 
>>stub level. The best time to change the timeout is before the invoke, 
>>i.e.
>>
>>*In the stub code for the web service method, change:*
>>:
>>if (AXIS_SUCCESS == m_pCall->invoke())
>>{
>>:
>>
>>*To:*
>>:
>>m_pCall->getTransport()->setTimeout( 30); // Change the socket timeout
>>    
>>
>
>  
>
>>to 30 seconds
>>if (AXIS_SUCCESS == m_pCall->invoke())
>>{
>>:
>>
>>Regards,
>>
>>Fred Preston.
>>
>>
>>	
>>
>>*krishna <krishna@lac.uic.edu>*
>>
>>07/07/2005 01:24 AM
>>Please respond to "Apache AXIS C Developers List"
>>
>>	
>>
>>
>>To: Apache AXIS C Developers List <axis-c-dev@ws.apache.org>
>>cc:
>>Subject: Re: how to set a timeout - update
>>
>>
>>
>>Hi
>>
>>Sorry for the traffic in the mailing list.
>>
>>I traced the exception back to its where it was thrown. It looks like
>>the timeout is hardcoded to 100 by setting iIterationCountdown=100 in
>>the HTTPTransport.cpp:655 file.
>>
>>Is there a way of resetting this timeout without recompiling axis or
>>Is there a way of recompiling the transport alone??
>>
>>Cheers
>>Krishna
>>
>>krishna wrote:
>>
>>    
>>
>>>Hi All
>>>
>>>The problem why the Array example was failing was due to timeouts. It
>>>is "HTTPTransportException:Input streaming error while getting data
>>>Timed out waiting for SOAP message (1)." I saw a discussion in the
>>>lists about connection timeouts and response timeouts. Would this
>>>      
>>>
>fall
>  
>
>>>under a response timeout ?
>>>
>>>I saw that Axis Java has a setTimeout functionality as part of the
>>>stubs. I could not find it in Stub.hpp. Does this functionality exist
>>>in Axis C++??
>>>
>>>Cheers
>>>Krishna
>>>
>>>
>>>krishna wrote:
>>>
>>>      
>>>
>>>>Hi All
>>>>
>>>>I was implementing the Array example on Axis 1.6 alpha. (
>>>>echoIntArray - The client sends an array of numbers and the server
>>>>echoes the array back to the client ). This is a RPC based
>>>>        
>>>>
>webservice
>  
>
>>>>The example seemed to work fine for < 200 numbers. For numbers > 200
>>>>the I had the following problems
>>>>I have attached the source code and stubs along with this email.
>>>>
>>>>Please find parts of the SOAP_RESPONSE below.
>>>>
>>>>1. The server did not echo back all the numbers
>>>>
>>>><item>1159</item>
>>>><item>1160</item>
>>>><item>1161</item>
>>>><item>1162</item>
>>>><item
>>>>
>>>>The message stopped here it was supposed to return 10000 items.
>>>>
>>>>2. Some text - "ffb" came into the message
>>>>
>>>><item>208</item>
>>>><item>209</item>
>>>><item
>>>>ffb
>>>>        
>>>>
>>>>>210</item>
>>>>>          
>>>>>
>>>><item>211</item>
>>>><item>212</item>
>>>>
>>>><item>449</item>
>>>><item>450</item>
>>>>ffb
>>>>
>>>><item>451</item>
>>>><item>452</item>
>>>>
>>>>Is this a known issue? The output above was captured using ethereal.
>>>>
>>>>Cheers
>>>>Krishna
>>>>
>>>>        
>>>>
>>>
>>>      
>>>
>
>
>
>  
>


Mime
View raw message