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 <[email protected]> wrote: > 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] > > -- 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 ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
