>You need to read the Javadoc more carefully.
I suggest you take a look at java.io.ByteArrayInputStream (both source and
javadoc).
Perfectly good InputStream (never heard anyone claim otherwise)
Never blocks.
>While the words "blocking
>and "non-blocking" are not used in ServletInputStream blocking IO is the
>only way to implement readLine.
Nope. readLine is beyond trivial (just delegates to #read()) -- has nothing
to do with blocking/non-blocking.
Could implement a non-blocking ServletInputStream (only defines extra
readLine method) in a minute or two.
If I had to guess, you're confusing non-blocking io with asynchronous io
(it's a common mistake). The servlet 3.0 spec does proscribe asynchronous
reads when servlets access the http request body (and headers as well for
that matter)
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).
Do you really think that is optimal? I don't and I think (hope) it is
unnecessary.
Now if the spec really does proscribe a java.io.ByteArrayInputStream-like
approach (and it's not in the pdf and it's not in the javadoc), then that's
unfortunate.
Are there tradeoffs with reading (not parsing, just reading) all the bytes
from the http request body before invoking the servlet FilterChain? Sure.
Although for servlets that access the http request body via
HttpRequest.getParameter('xxxx') (which I submit are the vast majority)
there really is no tradeoff (memory usage is the same). You certainly
identified one; I can think of others. And if you're writing an online
backup service, those tradeoffs aren't going to make you very happy.
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)
--
View this message in context:
http://tomcat.10.n6.nabble.com/Getting-my-head-around-NIO-simulated-blocking-trying-to-tp4996773p4996847.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
