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. > 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 > >> 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). 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. > 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"? > >> >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 (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?) > > > > >>All of this changes with Servlet 3.1. > > Mark > > > --------------------------------------------------------------------- > To unsubscribe, e-mail:
> dev-unsubscribe@.apache > For additional commands, e-mail: > dev-help@.apache -- View this message in context: http://tomcat.10.n6.nabble.com/Getting-my-head-around-NIO-simulated-blocking-trying-to-tp4996773p4996822.html Sent from the Tomcat - Dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
