tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Getting my head around NIO 'simulated' blocking (trying to)
Date Wed, 27 Mar 2013 21:11:23 GMT
> 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).


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


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message