axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samisa Abeysinghe <samisa.abeysin...@gmail.com>
Subject Re: timeout exception because of no Content-Length
Date Tue, 12 Jul 2005 03:55:12 GMT
+1 for Exceeption on TRANSPORT_FINISHED.

Samisa...

On 7/11/05, Carsten Blecken <cblecken@macrovision.com> wrote:
>  
> +1 for adding an exception in case the transport returns TRANSPORT_FINISHED.
> This case needs to be 
>    handled by the axis c engine and not the transport. 
>   
> Carsten 
>  
> -----Original Message-----
> From: Fred Preston [mailto:PRESTONF@uk.ibm.com]
> Sent: Monday, July 11, 2005 5:33 AM
> To: Apache AXIS C Developers List
> Subject: RE: timeout exception because of no Content-Length
> 
> 
> Hi Bernd, 
>         Good idea, but the parser works on a 'pull' model where information
> is only 'pulled' from the socket when Xerces internally runs out of
> information to parse and needs to draw more information from the socket. 
> Thus, it does not matter what proportion of the message has been received
> because if the parser needs more information to complete, it will attempt to
> read more information from the socket.  What could go into readBytes is some
> exception testing that would throw an exception if a readBytes was called
> once the Transport had read all of the expected bytes and returned with a
> TRANSPORT_FINISHED.  The iMaxToRead is a maximum size of pcToFill array and
> not an 'expecting to read' value.  BUFFER_SIZE reflects the size of a TCP
> packet, i.e. the maximum amount of data that can be transmitted per packet
> or the maximum granularity of the message data size. 
> 
> As a footnote to all this, if extra bytes are transmitted after the end of
> the response message (that is not part of the XML message), who will drain
> these additional bytes? 
> 
> Regards,
> 
> Fred Preston.
> 
> 
> 
>  
>  bernd.weber04@polizei.bayern.de 
> 
> 07/11/2005 12:29 PM 
> Please respond to "Apache AXIS C Developers List"         
>         To:        axis-c-dev@ws.apache.org 
>         cc:         
>         Subject:        RE: timeout exception because of no Content-Length 
> 
>        
> 
> Hi All,
> 
> I am using axis-c-final-1.5 and encountered problems of that kind, too,
> but it seemed not to be a time-out problem. I took a look at
> src/xml/xerces/SoapBinInputStream.cpp:41 - method readBytes
> 
> unsigned int SoapBinInputStream::readBytes(XMLByte* const
> pcToFill,
>                                 const unsigned int iMaxToRead)
> {
>                 int iRead = iMaxToRead;
>                 m_pInputStream->getBytes((char*)pcToFill,
> &iRead);
>                 m_nByteCount += iRead;
>                 return iRead;
> }
> 
> This method doesn't recognize if transport is still in progress after
> m_pInputStream->getBytes was called. If iRead is less than iMaxToRead
> and there are some more bytes left to receive, they get lost. If you
> think of the buffer size of HTTPChannel (BUF_SIZE == 8096) and the value
> of iMaxToRead (49152), you see that this must lead to truncated data
> if the amount to receive is greater that BUF_SIZE.
> This in mind, I rewrote that method:
> 
> unsigned int SoapBinInputStream::readBytes(XMLByte* const
> pcToFill,
>                                           const unsigned int iMaxToRead)
> {
>                 // Bernd Weber: call m_pInputStream->getBytes in a loop
> checking
>                 // AXIS_TRANSPORT_STATUS and the remaining space
> 
>                 unsigned iLoopRead = 0;
>                 AXIS_TRANSPORT_STATUS status = TRANSPORT_IN_PROGRESS;
>                 do {
>                                  int iRead = iMaxToRead - iLoopRead;
>                                  char* pcBuffer = (char*)(pcToFill +
> iLoopRead);
>                                  status =
> m_pInputStream->getBytes(pcBuffer, &iRead);
>                                  m_nByteCount += iRead;                     
>             // this instance's byte
> amount
>                                  iLoopRead += iRead;                        
>          // this loop's byte amount
>                                  if (iLoopRead < iMaxToRead) {
>                                                   pcToFill[iLoopRead] = 0;
>                                  }
>                 } while (status == TRANSPORT_IN_PROGRESS && iMaxToRead >
> iLoopRead);
>                 return iLoopRead;
> }
> 
> 
> Please check if these changes fix your problems, too, and if they could
> get part of the next Axis release.
> 
> 
> Best regards and thanks for Axis-c!
> 
> Bernd Weber
> bernd.weber@t-systems.com
> (bernd.weber04@polizei.bayern.de)
> 
> 
> 
> 
> > -----Original Message-----
> > From: krishna [mailto:krishna@lac.uic.edu]
> > Sent: Friday, July 08, 2005 3:59 PM
> > To: Apache AXIS C Developers List
> > Subject: Re: timeout exception because of no Content-Length
> > 
> > 
> > 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