You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Santosh Gangadhar <sa...@wirkle.com> on 2009/03/05 14:25:17 UTC
Bug in using InputStreamRequestEntity and chunked encoding
Hi All,
In the following code, pushServlet is a servlet that consumes data sent to
it with an upper limit specified by the "mb" parameter.
RandomDataInputStream is an InputStream generates some random data with an
upper limit. If acceptMB < sendMB, then httpclient stops sending data,
servlet stop receiving and sends response code 200 to http client. If
acceptMB > sendMB, then although the servlet stops accepting data and its
thread exits cleanly, the http client does not stop. It remains stuck at
executeMethod(). Further, it seems to retry sending data to pushServlet
again but no data is actually received there.
Http client code: -
http://rafb.net/p/GVNMxd61.html
Push servelet code: -
http://rafb.net/p/RrXrOx81.html
RandomDataInputSteram code: -
http://rafb.net/p/wNA9HN92.html
There is no retry handler specified here. Specifying a retry handler that
disallows a retry does not work either. Is this a bug? If the receving end
has stopped accepting data and sent the repsonse code, http cleint should
return from the executeMethod() method.
Thanks,
Santosh.
Re: Bug in using InputStreamRequestEntity and chunked encoding
Posted by Santosh Gangadhar <sa...@wirkle.com>.
We are sorting to a workaround specific to the implementation.
Thanks Oleg. Thanks all.
Santosh.
On Sat, Mar 7, 2009 at 7:41 PM, Oleg Kalnichevski <ol...@apache.org> wrote:
> Santosh Gangadhar wrote:
>
>> On Fri, Mar 6, 2009 at 10:45 PM, Oleg Kalnichevski <ol...@apache.org>
>> wrote:
>>
>> On Fri, 2009-03-06 at 22:33 +0530, Santosh Gangadhar wrote:
>>>
>>>> On Fri, Mar 6, 2009 at 7:31 PM, Oleg Kalnichevski <ol...@apache.org>
>>>>
>>> wrote:
>>>
>>>> On Fri, 2009-03-06 at 16:33 +0530, Santosh Gangadhar wrote:
>>>>>
>>>>>> Hi All,
>>>>>> After doing a few tests, the problem seems not be in http client.
>>>>>>
>>>>> After
>>>
>>>> the
>>>>>
>>>>>> service (doGet or doPost) method returns, at the back Tomcat does
>>>>>>
>>>>> some
>>>
>>>> cleanup. As a part of this cleanup, it tries to read out all data
>>>>>>
>>>>> coming
>>>
>>>> in.
>>>>>
>>>>>> It does not *close* the stream after the service method and therefore
>>>>>>
>>>>> the
>>>
>>>> http client keeps sending.
>>>>>>
>>>>>> What Tomcat does makes perfect sense. Tomcat attempts to read to end
>>>>> of
>>>>> the request entity in order to ensure the connection can be re-used for
>>>>> subsequent requests. If the clients keeps on sending data, Tomcat will
>>>>> keep on reading it.
>>>>>
>>>>> How can this be tackled? Is this a problem with Tomcat? Is this
>>>>>>
>>>>> related
>>>
>>>> to
>>>>>
>>>>>> Expect: 100 continue?
>>>>>>
>>>>>> Please help.
>>>>>>
>>>>>> Whatever you are trying to do it looks pretty bizarre to me. You
>>>>>
>>>> should
>>>
>>>> probably seriously reconsider your approach.
>>>>>
>>>>
>>>> We are trying to push a MJPEG stream to a servlet using chunked
>>>> encoding.
>>>> The stream is continuous and the client can send it as long as the
>>>>
>>> servlet
>>>
>>>> needs it. The control of stopping this stream is with the server and
>>>>
>>> hence
>>>
>>>> the client cannot stop it.
>>>>
>>>>
>>>> So, you are basically abusing HTTP protocol for a use case it has never
>>> intended or designed for. You may have a better luck asking Tomcat folks
>>> how they recommend to go about this problem. Essentially what you need
>>> is ability to physically close the underlying connection from inside the
>>> servlet when all required content has been read.
>>>
>>> Oleg
>>>
>>
>>
>> IP cameras and webcams these days expose APIs that serve mjpeg streams
>> over
>> HTTP. The streaming happens in a response not in a request. Is this the
>> reason the use in our case is inappropriate?
>>
>> In current versions of Tomcat ending a request input stream is not
>> possible.
>> The upcoming Tomcat 6.0.19 will support it with the help status codes and
>> exceptions.
>>
>>
> Santosh
>
> HTTP servers does not have to guess request content length. HTTP agents
> MUST correctly delimit request content body either using Content-Length
> header or the terminal chunk, if chunk coding is used.
>
> Hope this helps
>
> Oleg
>
>
>
>
>>
>>>
>>>
>>> Oleg
>>>>>
>>>>> Thanks,
>>>>>> Santosh.
>>>>>>
>>>>>> On Thu, Mar 5, 2009 at 6:55 PM, Santosh Gangadhar <
>>>>>>
>>>>> santosh@wirkle.com
>>>
>>>> wrote:
>>>>>>
>>>>>> Hi All,
>>>>>>> In the following code, pushServlet is a servlet that consumes data
>>>>>>>
>>>>>> sent
>>>
>>>> to
>>>>>
>>>>>> it with an upper limit specified by the "mb" parameter.
>>>>>>> RandomDataInputStream is an InputStream generates some random data
>>>>>>>
>>>>>> with
>>>
>>>> an
>>>>>
>>>>>> upper limit. If acceptMB < sendMB, then httpclient stops sending
>>>>>>>
>>>>>> data,
>>>
>>>> servlet stop receiving and sends response code 200 to http client.
>>>>>>>
>>>>>> If
>>>
>>>> acceptMB > sendMB, then although the servlet stops accepting data
>>>>>>>
>>>>>> and
>>>
>>>> its
>>>>>
>>>>>> thread exits cleanly, the http client does not stop. It remains
>>>>>>>
>>>>>> stuck
>>>
>>>> at
>>>>>
>>>>>> executeMethod(). Further, it seems to retry sending data to
>>>>>>>
>>>>>> pushServlet
>>>
>>>> again but no data is actually received there.
>>>>>>>
>>>>>>> Http client code: -
>>>>>>> http://rafb.net/p/GVNMxd61.html
>>>>>>>
>>>>>>> Push servelet code: -
>>>>>>> http://rafb.net/p/RrXrOx81.html
>>>>>>>
>>>>>>> RandomDataInputSteram code: -
>>>>>>> http://rafb.net/p/wNA9HN92.html
>>>>>>>
>>>>>>>
>>>>>>> There is no retry handler specified here. Specifying a retry
>>>>>>>
>>>>>> handler
>>>
>>>> that
>>>>>
>>>>>> disallows a retry does not work either. Is this a bug? If the
>>>>>>>
>>>>>> receving
>>>
>>>> end
>>>>>
>>>>>> has stopped accepting data and sent the repsonse code, http cleint
>>>>>>>
>>>>>> should
>>>>>
>>>>>> return from the executeMethod() method.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Santosh.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>>>>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>>>>>
>>>>>
>>>>> Thanks, Santosh.
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>>>
>>> Thanks, Santosh.
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
--
Santosh Gangadhar
Technical Lead, Wirkle
http://www.wirkle.com
+91 989.902.2981 (Mobile)
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Wirkle is a leading product engineering firm focused on developing software
products for the mobile including telecom grade client/server platforms, SMS
applications and Mobile Internet (WAP). The Company has designed, developed,
maintained, supported, tested and ported several mobile platforms for
hundreds of handsets of Nokia, Sony Ericsson, Samsung, LG, Motorola,
Blackberry, Pocket PC and iPhone.
Wirkle's expertise in the mobile space spans Social Networking, Instant
Messaging, Location Based Services, Multimedia Streaming, Banking,
Enterprise applications, Payments, Barcode Scanning and beyond. Millions of
mobile users across the globe today are using products developed by Wirkle
through various carriers across multiple geographies including North America
– AT&T, Sprint/Nextel, Boost Mobile; Europe – Telenor; Asia – Airtel, Idea
and more. For more information please visit: www.wirkle.com
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Re: Bug in using InputStreamRequestEntity and chunked encoding
Posted by Oleg Kalnichevski <ol...@apache.org>.
Santosh Gangadhar wrote:
> On Fri, Mar 6, 2009 at 10:45 PM, Oleg Kalnichevski <ol...@apache.org> wrote:
>
>> On Fri, 2009-03-06 at 22:33 +0530, Santosh Gangadhar wrote:
>>> On Fri, Mar 6, 2009 at 7:31 PM, Oleg Kalnichevski <ol...@apache.org>
>> wrote:
>>>> On Fri, 2009-03-06 at 16:33 +0530, Santosh Gangadhar wrote:
>>>>> Hi All,
>>>>> After doing a few tests, the problem seems not be in http client.
>> After
>>>> the
>>>>> service (doGet or doPost) method returns, at the back Tomcat does
>> some
>>>>> cleanup. As a part of this cleanup, it tries to read out all data
>> coming
>>>> in.
>>>>> It does not *close* the stream after the service method and therefore
>> the
>>>>> http client keeps sending.
>>>>>
>>>> What Tomcat does makes perfect sense. Tomcat attempts to read to end of
>>>> the request entity in order to ensure the connection can be re-used for
>>>> subsequent requests. If the clients keeps on sending data, Tomcat will
>>>> keep on reading it.
>>>>
>>>>> How can this be tackled? Is this a problem with Tomcat? Is this
>> related
>>>> to
>>>>> Expect: 100 continue?
>>>>>
>>>>> Please help.
>>>>>
>>>> Whatever you are trying to do it looks pretty bizarre to me. You
>> should
>>>> probably seriously reconsider your approach.
>>>
>>> We are trying to push a MJPEG stream to a servlet using chunked encoding.
>>> The stream is continuous and the client can send it as long as the
>> servlet
>>> needs it. The control of stopping this stream is with the server and
>> hence
>>> the client cannot stop it.
>>>
>>>
>> So, you are basically abusing HTTP protocol for a use case it has never
>> intended or designed for. You may have a better luck asking Tomcat folks
>> how they recommend to go about this problem. Essentially what you need
>> is ability to physically close the underlying connection from inside the
>> servlet when all required content has been read.
>>
>> Oleg
>
>
> IP cameras and webcams these days expose APIs that serve mjpeg streams over
> HTTP. The streaming happens in a response not in a request. Is this the
> reason the use in our case is inappropriate?
>
> In current versions of Tomcat ending a request input stream is not possible.
> The upcoming Tomcat 6.0.19 will support it with the help status codes and
> exceptions.
>
Santosh
HTTP servers does not have to guess request content length. HTTP agents
MUST correctly delimit request content body either using Content-Length
header or the terminal chunk, if chunk coding is used.
Hope this helps
Oleg
>
>>
>>
>>
>>>> Oleg
>>>>
>>>>> Thanks,
>>>>> Santosh.
>>>>>
>>>>> On Thu, Mar 5, 2009 at 6:55 PM, Santosh Gangadhar <
>> santosh@wirkle.com
>>>>> wrote:
>>>>>
>>>>>> Hi All,
>>>>>> In the following code, pushServlet is a servlet that consumes data
>> sent
>>>> to
>>>>>> it with an upper limit specified by the "mb" parameter.
>>>>>> RandomDataInputStream is an InputStream generates some random data
>> with
>>>> an
>>>>>> upper limit. If acceptMB < sendMB, then httpclient stops sending
>> data,
>>>>>> servlet stop receiving and sends response code 200 to http client.
>> If
>>>>>> acceptMB > sendMB, then although the servlet stops accepting data
>> and
>>>> its
>>>>>> thread exits cleanly, the http client does not stop. It remains
>> stuck
>>>> at
>>>>>> executeMethod(). Further, it seems to retry sending data to
>> pushServlet
>>>>>> again but no data is actually received there.
>>>>>>
>>>>>> Http client code: -
>>>>>> http://rafb.net/p/GVNMxd61.html
>>>>>>
>>>>>> Push servelet code: -
>>>>>> http://rafb.net/p/RrXrOx81.html
>>>>>>
>>>>>> RandomDataInputSteram code: -
>>>>>> http://rafb.net/p/wNA9HN92.html
>>>>>>
>>>>>>
>>>>>> There is no retry handler specified here. Specifying a retry
>> handler
>>>> that
>>>>>> disallows a retry does not work either. Is this a bug? If the
>> receving
>>>> end
>>>>>> has stopped accepting data and sent the repsonse code, http cleint
>>>> should
>>>>>> return from the executeMethod() method.
>>>>>>
>>>>>> Thanks,
>>>>>> Santosh.
>>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>>>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>>>>
>>>>
>>> Thanks, Santosh.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
>> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>>
> Thanks, Santosh.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Bug in using InputStreamRequestEntity and chunked encoding
Posted by Santosh Gangadhar <sa...@wirkle.com>.
On Fri, Mar 6, 2009 at 10:45 PM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Fri, 2009-03-06 at 22:33 +0530, Santosh Gangadhar wrote:
> > On Fri, Mar 6, 2009 at 7:31 PM, Oleg Kalnichevski <ol...@apache.org>
> wrote:
> >
> > > On Fri, 2009-03-06 at 16:33 +0530, Santosh Gangadhar wrote:
> > > > Hi All,
> > > > After doing a few tests, the problem seems not be in http client.
> After
> > > the
> > > > service (doGet or doPost) method returns, at the back Tomcat does
> some
> > > > cleanup. As a part of this cleanup, it tries to read out all data
> coming
> > > in.
> > > > It does not *close* the stream after the service method and therefore
> the
> > > > http client keeps sending.
> > > >
> > >
> > > What Tomcat does makes perfect sense. Tomcat attempts to read to end of
> > > the request entity in order to ensure the connection can be re-used for
> > > subsequent requests. If the clients keeps on sending data, Tomcat will
> > > keep on reading it.
> > >
> > > > How can this be tackled? Is this a problem with Tomcat? Is this
> related
> > > to
> > > > Expect: 100 continue?
> > > >
> > > > Please help.
> > > >
> > >
> > > Whatever you are trying to do it looks pretty bizarre to me. You
> should
> > > probably seriously reconsider your approach.
> >
> >
> > We are trying to push a MJPEG stream to a servlet using chunked encoding.
> > The stream is continuous and the client can send it as long as the
> servlet
> > needs it. The control of stopping this stream is with the server and
> hence
> > the client cannot stop it.
> >
> >
>
> So, you are basically abusing HTTP protocol for a use case it has never
> intended or designed for. You may have a better luck asking Tomcat folks
> how they recommend to go about this problem. Essentially what you need
> is ability to physically close the underlying connection from inside the
> servlet when all required content has been read.
>
> Oleg
IP cameras and webcams these days expose APIs that serve mjpeg streams over
HTTP. The streaming happens in a response not in a request. Is this the
reason the use in our case is inappropriate?
In current versions of Tomcat ending a request input stream is not possible.
The upcoming Tomcat 6.0.19 will support it with the help status codes and
exceptions.
>
>
>
>
> > >
> > > Oleg
> > >
> > > >
> > > > Thanks,
> > > > Santosh.
> > > >
> > > > On Thu, Mar 5, 2009 at 6:55 PM, Santosh Gangadhar <
> santosh@wirkle.com
> > > >wrote:
> > > >
> > > > > Hi All,
> > > > > In the following code, pushServlet is a servlet that consumes data
> sent
> > > to
> > > > > it with an upper limit specified by the "mb" parameter.
> > > > > RandomDataInputStream is an InputStream generates some random data
> with
> > > an
> > > > > upper limit. If acceptMB < sendMB, then httpclient stops sending
> data,
> > > > > servlet stop receiving and sends response code 200 to http client.
> If
> > > > > acceptMB > sendMB, then although the servlet stops accepting data
> and
> > > its
> > > > > thread exits cleanly, the http client does not stop. It remains
> stuck
> > > at
> > > > > executeMethod(). Further, it seems to retry sending data to
> pushServlet
> > > > > again but no data is actually received there.
> > > > >
> > > > > Http client code: -
> > > > > http://rafb.net/p/GVNMxd61.html
> > > > >
> > > > > Push servelet code: -
> > > > > http://rafb.net/p/RrXrOx81.html
> > > > >
> > > > > RandomDataInputSteram code: -
> > > > > http://rafb.net/p/wNA9HN92.html
> > > > >
> > > > >
> > > > > There is no retry handler specified here. Specifying a retry
> handler
> > > that
> > > > > disallows a retry does not work either. Is this a bug? If the
> receving
> > > end
> > > > > has stopped accepting data and sent the repsonse code, http cleint
> > > should
> > > > > return from the executeMethod() method.
> > > > >
> > > > > Thanks,
> > > > > Santosh.
> > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> > >
> > >
> > Thanks, Santosh.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
Thanks, Santosh.
Re: Bug in using InputStreamRequestEntity and chunked encoding
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2009-03-06 at 22:33 +0530, Santosh Gangadhar wrote:
> On Fri, Mar 6, 2009 at 7:31 PM, Oleg Kalnichevski <ol...@apache.org> wrote:
>
> > On Fri, 2009-03-06 at 16:33 +0530, Santosh Gangadhar wrote:
> > > Hi All,
> > > After doing a few tests, the problem seems not be in http client. After
> > the
> > > service (doGet or doPost) method returns, at the back Tomcat does some
> > > cleanup. As a part of this cleanup, it tries to read out all data coming
> > in.
> > > It does not *close* the stream after the service method and therefore the
> > > http client keeps sending.
> > >
> >
> > What Tomcat does makes perfect sense. Tomcat attempts to read to end of
> > the request entity in order to ensure the connection can be re-used for
> > subsequent requests. If the clients keeps on sending data, Tomcat will
> > keep on reading it.
> >
> > > How can this be tackled? Is this a problem with Tomcat? Is this related
> > to
> > > Expect: 100 continue?
> > >
> > > Please help.
> > >
> >
> > Whatever you are trying to do it looks pretty bizarre to me. You should
> > probably seriously reconsider your approach.
>
>
> We are trying to push a MJPEG stream to a servlet using chunked encoding.
> The stream is continuous and the client can send it as long as the servlet
> needs it. The control of stopping this stream is with the server and hence
> the client cannot stop it.
>
>
So, you are basically abusing HTTP protocol for a use case it has never
intended or designed for. You may have a better luck asking Tomcat folks
how they recommend to go about this problem. Essentially what you need
is ability to physically close the underlying connection from inside the
servlet when all required content has been read.
Oleg
> >
> > Oleg
> >
> > >
> > > Thanks,
> > > Santosh.
> > >
> > > On Thu, Mar 5, 2009 at 6:55 PM, Santosh Gangadhar <santosh@wirkle.com
> > >wrote:
> > >
> > > > Hi All,
> > > > In the following code, pushServlet is a servlet that consumes data sent
> > to
> > > > it with an upper limit specified by the "mb" parameter.
> > > > RandomDataInputStream is an InputStream generates some random data with
> > an
> > > > upper limit. If acceptMB < sendMB, then httpclient stops sending data,
> > > > servlet stop receiving and sends response code 200 to http client. If
> > > > acceptMB > sendMB, then although the servlet stops accepting data and
> > its
> > > > thread exits cleanly, the http client does not stop. It remains stuck
> > at
> > > > executeMethod(). Further, it seems to retry sending data to pushServlet
> > > > again but no data is actually received there.
> > > >
> > > > Http client code: -
> > > > http://rafb.net/p/GVNMxd61.html
> > > >
> > > > Push servelet code: -
> > > > http://rafb.net/p/RrXrOx81.html
> > > >
> > > > RandomDataInputSteram code: -
> > > > http://rafb.net/p/wNA9HN92.html
> > > >
> > > >
> > > > There is no retry handler specified here. Specifying a retry handler
> > that
> > > > disallows a retry does not work either. Is this a bug? If the receving
> > end
> > > > has stopped accepting data and sent the repsonse code, http cleint
> > should
> > > > return from the executeMethod() method.
> > > >
> > > > Thanks,
> > > > Santosh.
> > > >
> > >
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> > For additional commands, e-mail: httpclient-users-help@hc.apache.org
> >
> >
> Thanks, Santosh.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Bug in using InputStreamRequestEntity and chunked encoding
Posted by Santosh Gangadhar <sa...@wirkle.com>.
On Fri, Mar 6, 2009 at 7:31 PM, Oleg Kalnichevski <ol...@apache.org> wrote:
> On Fri, 2009-03-06 at 16:33 +0530, Santosh Gangadhar wrote:
> > Hi All,
> > After doing a few tests, the problem seems not be in http client. After
> the
> > service (doGet or doPost) method returns, at the back Tomcat does some
> > cleanup. As a part of this cleanup, it tries to read out all data coming
> in.
> > It does not *close* the stream after the service method and therefore the
> > http client keeps sending.
> >
>
> What Tomcat does makes perfect sense. Tomcat attempts to read to end of
> the request entity in order to ensure the connection can be re-used for
> subsequent requests. If the clients keeps on sending data, Tomcat will
> keep on reading it.
>
> > How can this be tackled? Is this a problem with Tomcat? Is this related
> to
> > Expect: 100 continue?
> >
> > Please help.
> >
>
> Whatever you are trying to do it looks pretty bizarre to me. You should
> probably seriously reconsider your approach.
We are trying to push a MJPEG stream to a servlet using chunked encoding.
The stream is continuous and the client can send it as long as the servlet
needs it. The control of stopping this stream is with the server and hence
the client cannot stop it.
>
> Oleg
>
> >
> > Thanks,
> > Santosh.
> >
> > On Thu, Mar 5, 2009 at 6:55 PM, Santosh Gangadhar <santosh@wirkle.com
> >wrote:
> >
> > > Hi All,
> > > In the following code, pushServlet is a servlet that consumes data sent
> to
> > > it with an upper limit specified by the "mb" parameter.
> > > RandomDataInputStream is an InputStream generates some random data with
> an
> > > upper limit. If acceptMB < sendMB, then httpclient stops sending data,
> > > servlet stop receiving and sends response code 200 to http client. If
> > > acceptMB > sendMB, then although the servlet stops accepting data and
> its
> > > thread exits cleanly, the http client does not stop. It remains stuck
> at
> > > executeMethod(). Further, it seems to retry sending data to pushServlet
> > > again but no data is actually received there.
> > >
> > > Http client code: -
> > > http://rafb.net/p/GVNMxd61.html
> > >
> > > Push servelet code: -
> > > http://rafb.net/p/RrXrOx81.html
> > >
> > > RandomDataInputSteram code: -
> > > http://rafb.net/p/wNA9HN92.html
> > >
> > >
> > > There is no retry handler specified here. Specifying a retry handler
> that
> > > disallows a retry does not work either. Is this a bug? If the receving
> end
> > > has stopped accepting data and sent the repsonse code, http cleint
> should
> > > return from the executeMethod() method.
> > >
> > > Thanks,
> > > Santosh.
> > >
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
Thanks, Santosh.
Re: Bug in using InputStreamRequestEntity and chunked encoding
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2009-03-06 at 16:33 +0530, Santosh Gangadhar wrote:
> Hi All,
> After doing a few tests, the problem seems not be in http client. After the
> service (doGet or doPost) method returns, at the back Tomcat does some
> cleanup. As a part of this cleanup, it tries to read out all data coming in.
> It does not *close* the stream after the service method and therefore the
> http client keeps sending.
>
What Tomcat does makes perfect sense. Tomcat attempts to read to end of
the request entity in order to ensure the connection can be re-used for
subsequent requests. If the clients keeps on sending data, Tomcat will
keep on reading it.
> How can this be tackled? Is this a problem with Tomcat? Is this related to
> Expect: 100 continue?
>
> Please help.
>
Whatever you are trying to do it looks pretty bizarre to me. You should
probably seriously reconsider your approach.
Oleg
>
> Thanks,
> Santosh.
>
> On Thu, Mar 5, 2009 at 6:55 PM, Santosh Gangadhar <sa...@wirkle.com>wrote:
>
> > Hi All,
> > In the following code, pushServlet is a servlet that consumes data sent to
> > it with an upper limit specified by the "mb" parameter.
> > RandomDataInputStream is an InputStream generates some random data with an
> > upper limit. If acceptMB < sendMB, then httpclient stops sending data,
> > servlet stop receiving and sends response code 200 to http client. If
> > acceptMB > sendMB, then although the servlet stops accepting data and its
> > thread exits cleanly, the http client does not stop. It remains stuck at
> > executeMethod(). Further, it seems to retry sending data to pushServlet
> > again but no data is actually received there.
> >
> > Http client code: -
> > http://rafb.net/p/GVNMxd61.html
> >
> > Push servelet code: -
> > http://rafb.net/p/RrXrOx81.html
> >
> > RandomDataInputSteram code: -
> > http://rafb.net/p/wNA9HN92.html
> >
> >
> > There is no retry handler specified here. Specifying a retry handler that
> > disallows a retry does not work either. Is this a bug? If the receving end
> > has stopped accepting data and sent the repsonse code, http cleint should
> > return from the executeMethod() method.
> >
> > Thanks,
> > Santosh.
> >
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: Bug in using InputStreamRequestEntity and chunked encoding
Posted by Santosh Gangadhar <sa...@wirkle.com>.
Hi All,
After doing a few tests, the problem seems not be in http client. After the
service (doGet or doPost) method returns, at the back Tomcat does some
cleanup. As a part of this cleanup, it tries to read out all data coming in.
It does not *close* the stream after the service method and therefore the
http client keeps sending.
How can this be tackled? Is this a problem with Tomcat? Is this related to
Expect: 100 continue?
Please help.
Thanks,
Santosh.
On Thu, Mar 5, 2009 at 6:55 PM, Santosh Gangadhar <sa...@wirkle.com>wrote:
> Hi All,
> In the following code, pushServlet is a servlet that consumes data sent to
> it with an upper limit specified by the "mb" parameter.
> RandomDataInputStream is an InputStream generates some random data with an
> upper limit. If acceptMB < sendMB, then httpclient stops sending data,
> servlet stop receiving and sends response code 200 to http client. If
> acceptMB > sendMB, then although the servlet stops accepting data and its
> thread exits cleanly, the http client does not stop. It remains stuck at
> executeMethod(). Further, it seems to retry sending data to pushServlet
> again but no data is actually received there.
>
> Http client code: -
> http://rafb.net/p/GVNMxd61.html
>
> Push servelet code: -
> http://rafb.net/p/RrXrOx81.html
>
> RandomDataInputSteram code: -
> http://rafb.net/p/wNA9HN92.html
>
>
> There is no retry handler specified here. Specifying a retry handler that
> disallows a retry does not work either. Is this a bug? If the receving end
> has stopped accepting data and sent the repsonse code, http cleint should
> return from the executeMethod() method.
>
> Thanks,
> Santosh.
>
--
Santosh Gangadhar
Technical Lead, Wirkle
http://www.wirkle.com
+91 989.902.2981 (Mobile)
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Wirkle is a leading product engineering firm focused on developing software
products for the mobile including telecom grade client/server platforms, SMS
applications and Mobile Internet (WAP). The Company has designed, developed,
maintained, supported, tested and ported several mobile platforms for
hundreds of handsets of Nokia, Sony Ericsson, Samsung, LG, Motorola,
Blackberry, Pocket PC and iPhone.
Wirkle's expertise in the mobile space spans Social Networking, Instant
Messaging, Location Based Services, Multimedia Streaming, Banking,
Enterprise applications, Payments, Barcode Scanning and beyond. Millions of
mobile users across the globe today are using products developed by Wirkle
through various carriers across multiple geographies including North America
– AT&T, Sprint/Nextel, Boost Mobile; Europe – Telenor; Asia – Airtel, Idea
and more. For more information please visit: www.wirkle.com
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------