On 30 March 2012 11:35, Justin Lee <jlee_at_antwerkz.com> wrote:
> I have to be missing something, but why is the servlet 3.1 effort focusing
> so much on async IO APIs? Why not just leverage the existing NIO (or the
> mythical AIO) APIs already in the JDK? Is this API targeted at servlet
> authors? Or potential connection upgrades?
I tend to agree that the need for async IO is not what it once was.
Originally async servlets were introduced to facilitate push
technologies like comet. While not strictly required, async IO would
allow some more efficient push applications as well as some efficient
handling of large pulls. However, this use case is largely being
taken over by websocket and potentially SPDY.
Also before websocket was a standard, it made little sense to put
support for it into the container, so a generic upgrade mechanism plus
async IO would have been one way to accommodate non standard protocols
such as the draft websockets. However, websockets is now
standardised and a JSR has begun to create a standard server API, so
the best place for an implementation will be in the container rather
than in the application.
So in a future where the containers are using SPDY and/or websockets
as the wire protocol, the current drivers for upgrade and async IO are
greatly diminished. But perhaps there will be other protocols that
are developed to replace SPDY and/or websockets and upgrade and/or
async IO support will allow those to be handled within a 3.1
container. Or perhaps applications that generate or consume large
and/or streamed content will benefit from async IO regardless of the
underlying protocol that transports the data.
I think this is an important question, since if the target is new
protocols and upgrades, then the traditional style of canRead/canWrite
notifications is probably the best approach. However if the target is
application developers wanting to stream large content, then I believe
the usability of the NIO.2 style outweighs some of it's inefficiencies
(which I think have perhaps been overstated - including by me).
cheers