Santosh Gangadhar wrote:
On Fri, Mar 6, 2009 at 10:45 PM, Oleg Kalnichevski <[email protected]> wrote:
On Fri, 2009-03-06 at 22:33 +0530, Santosh Gangadhar wrote:
On Fri, Mar 6, 2009 at 7:31 PM, Oleg Kalnichevski <[email protected]>
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 <
[email protected]
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: [email protected]
For additional commands, e-mail: [email protected]
Thanks, Santosh.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
Thanks, Santosh.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
