Array example fails for large number of numbers

[krishna-15]

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

[Fred Preston]

Hi Krishna,
        Answering your second question, '2. Some text - "ffb" came into the message'.  This is fine.  What is happening is when you have a large message it cannot be sent as a single block, but has to be cut up into smaller blocks or 'chunks'.  What you are seeing is called 'chunking' and the numbers are actually hexadecimal numbers that begin each chunk and tell the transport how big that chunk is.

Regards,

Fred Preston.

krishna <krishna@...> 07/06/2005 02:44 AM Please respond to "Apache AXIS C Developers List"

To:        Apache AXIS C Developers List <axis-c-dev@...>         cc:                 Subject:        Array example fails for large number of numbers

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




#### example_xml_array.tar has been removed from this note on July 06 2005 by Fred Preston

[krishna-15]

Hi Fred/All

Thanks for the reply.  Do you have any idea as to why the first error is
occurring or/and what I may do to debug it.

Cheers
Krishna

Fred Preston wrote:

>
> Hi Krishna,
>         Answering your second question, '2. Some text - "ffb" came
> into the message'.  This is fine.  What is happening is when you have
> a large message it cannot be sent as a single block, but has to be cut
> up into smaller blocks or 'chunks'.  What you are seeing is called
> 'chunking' and the numbers are actually hexadecimal numbers that begin
> each chunk and tell the transport how big that chunk is.
>
> Regards,
>
> Fred Preston.
>
>
>
>
> *krishna <krishna@...>*
>
> 07/06/2005 02:44 AM
> Please respond to "Apache AXIS C Developers List"
>
>      
>         To:        Apache AXIS C Developers List
> <axis-c-dev@...>
>         cc:        
>         Subject:        Array example fails for large number of numbers
>
>        
>
>
>
>
> 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
>
>
>
>
> #### example_xml_array.tar has been removed from this note on July 06
> 2005 by Fred Preston

[krishna-15]

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
>

[krishna-15]

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
>>
>
>
>

[Samisa Abeysinghe-2]

Even through this is hardcoded here, you can control the timeout at
stub level using setTransportTimeout() on the client stub.
Please try this.

Thanks,
Samisa...

On 7/7/05, krishna <krishna@...> wrote:

> 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
> >>
> >
> >
> >
>
>

[Fred Preston]

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@...> 07/07/2005 01:24 AM Please respond to "Apache AXIS C Developers List"

To:        Apache AXIS C Developers List <axis-c-dev@...>         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
>>
>
>
>

[Samisa Abeysinghe]

Some parts of this message have been removed. Learn more about Nabble's security policy.

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@...]
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@...> 07/07/2005 01:24 AM Please respond to "Apache AXIS C Developers List"

To:        Apache AXIS C Developers List <axis-c-dev@...>         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
>>
>
>
>

[Nadir Amra]

I have always had a problem with the iteration counter.  I mean, the
server may be slow to respond or there could be some network glitches.  I
think for TCP/IP connections we should always set the keep-alive flag on
to ensure that if the server goes down the engine will know about, and
remove the iteration counter.  Yes, their is potential that the client
will wait indefinately, but I think that is better than returning an error
when there really is no error.

At the very least we should set keep-alive flag in the socket.

What do you all think?

Nadir K. Amra


Fred Preston <PRESTONF@...> wrote on 07/07/2005 04:33:35 AM:

>
> 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@...>
> 07/07/2005 01:24 AM
> Please respond to "Apache AXIS C Developers List"
>
>
>         To:        Apache AXIS C Developers List
<axis-c-dev@...>

>         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
> >>
> >
> >
> >
>

[krishna-15]

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@...]
> *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@...>*
>
> 07/07/2005 01:24 AM
> Please respond to "Apache AXIS C Developers List"
>
>
>
>
> To: Apache AXIS C Developers List <axis-c-dev@...>
> 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
>>>
>>
>>
>>
>

[Carsten Blecken]

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@...]
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@...]
> *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@...>*
>
> 07/07/2005 01:24 AM
> Please respond to "Apache AXIS C Developers List"
>
>
>
>
> To: Apache AXIS C Developers List <axis-c-dev@...>
> 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
>>>
>>
>>
>>
>

[Samisa Abeysinghe]

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@...]
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@...]
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@...]
> *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@...>*
>
> 07/07/2005 01:24 AM
> Please respond to "Apache AXIS C Developers List"
>
>
>
>
> To: Apache AXIS C Developers List <axis-c-dev@...>
> 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
>>>
>>
>>
>>
>

[krishna-15]

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@...]
>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@...]
>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@...]
>>*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@...>*
>>
>>07/07/2005 01:24 AM
>>Please respond to "Apache AXIS C Developers List"
>>
>>
>>
>>
>>To: Apache AXIS C Developers List <axis-c-dev@...>
>>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
>>>>
>>>>        
>>>>
>>>
>>>      
>>>
>
>
>
>  
>

[Fred Preston]

Hi Nadir,
        This could be done.  The best approach now is to create a JIRA suggesting this as an 'improvement'.  i.e. rather than using an iteration count, have the ability to change the socket to never timeout (i.e set the timeout to NULL in the select statement at the end of the applyTimeout method).  This could be done by selecting a timeout of 0 which would be interpreted as a 'never timeout'.  Of course if you do this and the server never responds or the message is incomplete, your client will never return unless the server closes the socket connection.  But it could be coded and the user could request this option knowing the consequences of message failure.

Regards,

Fred Preston.

Nadir Amra <amra@...> 07/07/2005 03:08 PM Please respond to "Apache AXIS C Developers List"

To:        "Apache AXIS C Developers List" <axis-c-dev@...>         cc:                 Subject:        Re: how to set a timeout - update

I have always had a problem with the iteration counter.  I mean, the
server may be slow to respond or there could be some network glitches.  I
think for TCP/IP connections we should always set the keep-alive flag on
to ensure that if the server goes down the engine will know about, and
remove the iteration counter.  Yes, their is potential that the client
will wait indefinately, but I think that is better than returning an error
when there really is no error.

At the very least we should set keep-alive flag in the socket.

What do you all think?

Nadir K. Amra


Fred Preston <PRESTONF@...> wrote on 07/07/2005 04:33:35 AM:

>
> 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@...>
> 07/07/2005 01:24 AM
> Please respond to "Apache AXIS C Developers List"
>
>
>         To:        Apache AXIS C Developers List
<axis-c-dev@...>
>         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
> >>
> >
> >
> >
>

[bernd.weber04]

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@...
(bernd.weber04@...)

> -----Original Message-----
> From: krishna [mailto:krishna@...]
> 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@...]
> >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@...]
> >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@...]
> >>*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@...>*
> >>
> >>07/07/2005 01:24 AM
> >>Please respond to "Apache AXIS C Developers List"
> >>
> >>
> >>
> >>
> >>To: Apache AXIS C Developers List <axis-c-dev@...>
> >>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
> >>>>
> >>>>        
> >>>>
> >>>
> >>>      
> >>>
> >
> >
> >
> >  
> >
>

[Fred Preston]

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@... 07/11/2005 12:29 PM Please respond to "Apache AXIS C Developers List"

To:        axis-c-dev@...         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@...
(bernd.weber04@...)




> -----Original Message-----
> From: krishna [mailto:krishna@...]
> 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@...]
> >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@...]
> >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@...]
> >>*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@...>*
> >>
> >>07/07/2005 01:24 AM
> >>Please respond to "Apache AXIS C Developers List"
> >>
> >>                
> >>
> >>
> >>To: Apache AXIS C Developers List <axis-c-dev@...>
> >>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
> >>>>
> >>>>        
> >>>>
> >>>
> >>>      
> >>>
> >
> >
> >
> >  
> >
>

[Carsten Blecken]

+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@...]
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@... 07/11/2005 12:29 PM Please respond to "Apache AXIS C Developers List"

To:        axis-c-dev@...         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@...
(bernd.weber04@...)

> -----Original Message-----
> From: krishna [mailto:krishna@...]
> 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@...]
> >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@...]
> >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@...]
> >>*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@...>*
> >>
> >>07/07/2005 01:24 AM
> >>Please respond to "Apache AXIS C Developers List"
> >>
> >>                
> >>
> >>
> >>To: Apache AXIS C Developers List <axis-c-dev@...>
> >>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
> >>>>
> >>>>        
> >>>>
> >>>
> >>>      
> >>>
> >
> >
> >
> >  
> >
>

[Samisa Abeysinghe-2]

+1 for Exceeption on TRANSPORT_FINISHED.

Samisa...

On 7/11/05, Carsten Blecken <cblecken@...> 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@...]
> 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@...
>
> 07/11/2005 12:29 PM
> Please respond to "Apache AXIS C Developers List"        
>         To:        axis-c-dev@...
>         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@...
> (bernd.weber04@...)
>
>
>
>
> > -----Original Message-----
> > From: krishna [mailto:krishna@...]
> > 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@...]
> > >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@...]
> > >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@...]
> > >>*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@...>*
> > >>
> > >>07/07/2005 01:24 AM
> > >>Please respond to "Apache AXIS C Developers List"
> > >>
> > >>                
> > >>
> > >>
> > >>To: Apache AXIS C Developers List <axis-c-dev@...>
> > >>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
> > >>>>
> > >>>>        
> > >>>>
> > >>>
> > >>>      
> > >>>
> > >
> > >
> > >
> > >  
> > >
> >
>
>
>

[Samisa Abeysinghe-2]

Sorry for the delay in responding.

However, the server may have run into problems due to some memory
errors (these effested client side as well) I fixed some memory
errors. Could please try now and see?

Thanks,
Samisa...

On 7/6/05, krishna <krishna@...> wrote:

> Hi Fred/All
>
> Thanks for the reply.  Do you have any idea as to why the first error is
> occurring or/and what I may do to debug it.
>
> Cheers
> Krishna
>
> Fred Preston wrote:
>
> >
> > Hi Krishna,
> >         Answering your second question, '2. Some text - "ffb" came
> > into the message'.  This is fine.  What is happening is when you have
> > a large message it cannot be sent as a single block, but has to be cut
> > up into smaller blocks or 'chunks'.  What you are seeing is called
> > 'chunking' and the numbers are actually hexadecimal numbers that begin
> > each chunk and tell the transport how big that chunk is.
> >
> > Regards,
> >
> > Fred Preston.
> >
> >
> >
> >
> >       *krishna <krishna@...>*
> >
> > 07/06/2005 02:44 AM
> > Please respond to "Apache AXIS C Developers List"
> >
> >
> >         To:        Apache AXIS C Developers List
> > <axis-c-dev@...>
> >         cc:
> >         Subject:        Array example fails for large number of numbers
> >
> >
> >
> >
> >
> >
> > 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
> >
> >
> >
> >
> > #### example_xml_array.tar has been removed from this note on July 06
> > 2005 by Fred Preston
>
>
>

[krishna-15]

Hi Samisa/All

I am able to successfully run the samples which failed earlier.
Thanks for the help.

Cheers
Krishna

Samisa Abeysinghe wrote:

>Sorry for the delay in responding.
>
>However, the server may have run into problems due to some memory
>errors (these effested client side as well) I fixed some memory
>errors. Could please try now and see?
>
>Thanks,
>Samisa...
>
>On 7/6/05, krishna <krishna@...> wrote:
>  
>
>>Hi Fred/All
>>
>>Thanks for the reply.  Do you have any idea as to why the first error is
>>occurring or/and what I may do to debug it.
>>
>>Cheers
>>Krishna
>>
>>Fred Preston wrote:
>>
>>    
>>
>>>Hi Krishna,
>>>        Answering your second question, '2. Some text - "ffb" came
>>>into the message'.  This is fine.  What is happening is when you have
>>>a large message it cannot be sent as a single block, but has to be cut
>>>up into smaller blocks or 'chunks'.  What you are seeing is called
>>>'chunking' and the numbers are actually hexadecimal numbers that begin
>>>each chunk and tell the transport how big that chunk is.
>>>
>>>Regards,
>>>
>>>Fred Preston.
>>>
>>>
>>>
>>>
>>>      *krishna <krishna@...>*
>>>
>>>07/06/2005 02:44 AM
>>>Please respond to "Apache AXIS C Developers List"
>>>
>>>
>>>        To:        Apache AXIS C Developers List
>>><axis-c-dev@...>
>>>        cc:
>>>        Subject:        Array example fails for large number of numbers
>>>
>>>
>>>
>>>
>>>
>>>
>>>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
>>>
>>>
>>>
>>>
>>>#### example_xml_array.tar has been removed from this note on July 06
>>>2005 by Fred Preston
>>>      
>>>
>>
>>    
>>
>
>
>  
>