On 25/03/2013 03:46, igaz wrote:
>> 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.
ByteArrayInputStream isn't really a fair example is it? Given that it
doesn't actually do any IO.
>> 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.
But read() is blocking, so I'm not sure what your point is.
> 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)
If I had to guess, I'd say you hadn't bothered to check out who your
interlocutor is & what he's spent most of his time working on recently.
p
> 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
>
--
[key:62590808]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
