On 24/03/2013 15:23, igaz wrote: > markt wrote >>> Take a closer look. ServletInputStream (up to Servlet 3.0) is clearly >>> blocking. >> >> Where in the spec is this? I don't see it. ServletInputStream is not >> even mentioned - neither is blocking. ServletInputStream's javadoc also >> mentions nothing about it.
You need to read the Javadoc more carefully. While the words "blocking and "non-blocking" are not used in ServletInputStream blocking IO is the only way to implement readLine. Also, look at the Javadoc for the readXXX methods for InputStream. >> Are you talking about section 3.1.1 "When parameters are available"? >> This is the only place I could find in the 3.0 servlet spec that even >> touches on request.getInputStream() and of course it mentions nothing >> about blocking. >> Now, you might have more context than is available from the straight text >> since I assume someone from the tomcat team is in the expert group I happen to be on the EG but all the information is in the Javadoc. See above. Personally, I really dislike that a) some parts of the spec are only defined in the Javadoc and b) the Javadoc is not included in the spec pdf. The spec was a lot easier to search when everything was in a single document. Unfortunately, I lost that argument with the spec lead. >>> Here is some pseudocode for what I had in mind (I'm eliding quite a bit: >> <snip/> >>>> Note requestIncomplete() returns true only when the *entire* http >>>> request >>>> (headers and body) has been read. >>>> Now, this is idiomatic java nio and I have used this pattern in >>>> implementing >>>> my own nio server (not for http requests) >>>> I see nothing in the servlet spec that would proscribe this and it >>>> scales >>>> wonderfully. >> >>> No, it doesn't. Think about what happens if someone wants to upload a >>> 5Gb file. >> >> Well, there is a pretty good software engineering principle that I employ: >> Don't make the 99% (or 95% or 90%) case pay for the 1%; but yes, you >> are right that large file uploads would be problematic to be sure (not >> because of the non-blocking read of course, but because of the memory >> usage). Exactly. Reading the entire request body into memory doesn't scale. Performance also gets worse as request size increases. There is a similar issue with responses and that is why HTTP/1.1 has chunked encoding so 1) the entire response doesn't have to be held in memory and 2) the server can start sending the response to the client before it has finished generating all of it. > I might point out that if you're using servlets to upload 5GB >> files, well you have a bigger issue than blocking vs. non-blocking reads. Such as? If you are doing uploads over HTTP then Servlets are no better or worse than any other option. >> I'm not sure what your argument is: are you suggesting that Tomcat doesn't >> do non-blocking reads of the http request body because of large file >> uploads or because "it's required by the spec"? I am saying that the Servlet specification (up to and including 3.0) clearly requires reading of request bodies and writing of response bodies to use blocking IO. >>>> Yet it seems that Tomcats NIO connector does not do this. Hence, my >>>> confusion/curiosity >> >>> Tomcat reads the headers (and does so in a non-blocking mode for NIO) >>> but reading request bodies is an application concern and is performed >> >> well, what about the request's parameter set? strictly speaking, your >> statement is just incorrect Nope. My statement was correct. Parsing of parameters from the request body is an application concern and is triggered by the application. The Servlet API provides some convenience methods for doing the work but it is the application that triggers the processing. The application is free to process them manually if it wishes and it is also free to completely ignore them (in which case the container just swallows the bytes). > (why for instance isn't reading the headers >> (other than the path info) an 'application' concern, by which I presume >> you mean a servlet's responsibility?) Because of where the Servlet specification draws the (sometimes rather fuzzy) line. There are some aspects of the HTTP protocol that the container has to manage (e.g. chunking) and to do that it needs to read and write the headers. Also, if you study the Servlet API - and I'll grant you this may not be immediately obvious until you start implementing a Servlet container - the point at which control passes from the container to the application is once all the HTTP headers have been read. The reason for this is that HTTP headers can be in any order so to be sure that the request is valid, that it is handled correctly and that the container does any pre/post precessing it is required to do, the container has to read all the headers before passing control to the application. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
