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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
