[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tomcat-dev
Subject:    Re: Getting my head around NIO 'simulated' blocking (trying to)
From:       igaz <thurston () nomagicsoftware ! com>
Date:       2013-03-29 17:10:40
Message-ID: 1364577040365-4997164.post () n6 ! nabble ! com
[Download RAW message or body]

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

Well, I suppose it depends upon your definition of /easy/
It is certainly true that the 3.1 spec does allow for servlets to be able to
'choose' which approach they want to take and therefore get the best of both
worlds.  And the callback approach is architecturally sounder and more
flexible (of course node.js and netty were built upon it).  But at some cost
of complexity it seems to me - because the servlet author has to use async
request processing (and I see absolutely no way around that).  And it is not
contradictory to want NIO reading (and writing) of the request/response, but
have no real cause for asynchronous processing of the request
And so I suspect the adoption rate will not be that high:

1. Just because it is asynchronous and many developers have difficulty
*thinking asynchronously*
2. It means that the servlet author will have to /build their own
httprequest parameter-set/ (or its equivalent) (at least int the case of
Content-Type: application/x-www-form-urlencoded), taking into account
url-encoding and request body character-encoding; not especially difficult,
but something that the container did previously (which begs the question:
what are the semantics of accessing the httprequest's parameter set when
using the new NIO?  should the container throw an Exception?  what about
query parameters?  can those be accessed (since the container had to read
and presumable parse them?)
3.  what about memory consistency/visibility?  It seems to me that it should
be *explicitly* part of the spec that the *container* ensure that successive
calls to ReadListener#onDataAvailable() form a *happens-before* otherwise I
smell grief.
4.  And of course, it wouldn't be trivial to port all existing applications
to use this new pattern

Just upon my admittedly quick perusal of the spec and a few presentations by
Oracle engineers, I have as many questions as answers. (although I think
it's a good thing)

All told, I don't think 3.1 obviates the benefits of the approach I've
advocated.  One of its advantages is that not a single line of extant
servlet code need be changed in anyway (which is why I'm convinced that
without explicit prohibition by the spec, it isn't in violation), and
engineers (and all those extant MVC frameworks!!) that feel more comfortable
with the traditional serial access to the http request body could still
benefit





--
View this message in context: \
http://tomcat.10.n6.nabble.com/Getting-my-head-around-NIO-simulated-blocking-trying-to-tp4996773p4997164.html
 Sent from the Tomcat - Dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]