+1 for Exceeption on TRANSPORT_FINISHED. Samisa...
On 7/11/05, Carsten Blecken <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > 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. > > > > > [EMAIL PROTECTED] > > 07/11/2005 12:29 PM > Please respond to "Apache AXIS C Developers List" > To: [email protected] > 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 > [EMAIL PROTECTED] > ([EMAIL PROTECTED]) > > > > > > -----Original Message----- > > From: krishna [mailto:[EMAIL PROTECTED] > > 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:[EMAIL PROTECTED] > > >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:[EMAIL PROTECTED] > > >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:[EMAIL PROTECTED] > > >>*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 <[EMAIL PROTECTED]>* > > >> > > >>07/07/2005 01:24 AM > > >>Please respond to "Apache AXIS C Developers List" > > >> > > >> > > >> > > >> > > >>To: Apache AXIS C Developers List <[email protected]> > > >>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 > > >>>> > > >>>> > > >>>> > > >>> > > >>> > > >>> > > > > > > > > > > > > > > > > > > > >
