> On 3/24/13 11:46 PM, igaz wrote: >> The reason that I'm even bringing this up is that more and more >> web applications receive an increasing share of their traffic >> from GPS devices, cellphones, etc. And these devices often use >> comparatively unreliable networks, where it is not uncommon for >> tcp segments to arrive seconds apart (and I mean tcp segments >> that are part of the same http request body).
Yep. >> In such a case, Tomcat's current NIO connector leaves us in the >> same old place: a dedicated thread per socket, in an io-wait >> state (i.e. blocking). If that's the majority of your traffic, >> that doesn't scale (and that's just an empirical statement, not a >> judgment). And one I agree with. >> I'm sure the tomcat committers wouldn't be thrilled with yet >> another configuration parameter, yet another code execution path >> (I know I wouldn't be) ; maxPostSize is too coarse of course. >> Ideally, you want something where the container could ask the >> servlet (based upon the dynamic http request header) - "should I >> read all of the request body (into memory) or should I defer >> reading and let you do it (via request.getInputStream() or >> request.getReader()). This has to be asked *before* invoking >> the FilterChain. Now that is definitely not in the spec (maybe >> it should be). You may have noticed my responses were littered with comments like "up to Servlet 3.0 ..." The problem you are presenting is easily solved in Servlet 3.1. Once you need to read the request body, put the Servlet into Async mode and then use the new non-blocking IO API added in Servlet 3.1 to read the request body. Stick the data into memory or process it on a stream basis - the choice is yours. As long as you use a connector that is actually capable of non-blocking IO (NIO or APR/native) you will get true non-blocking IO and the server side can be vent-driven. If you use the BIO connector everything will still work, it will just use blocking IO and you won't get any advantages of using the new API. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
