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