On Wed, 2012-03-07 at 08:44 +1100, Greg Wilkins wrote:
>
> Breaking this out to a new thread....
>
> Remind me again why we need async IO?
>
> One reason is to avoid blocking while reading large content. But
> that could be more simply addressed by adding an API to AsyncContext
> to ask the container to read the content of the request and to do an
> callback (or dispatch) once the content is read (perhaps into a file
> if it is really big).
>
> Generating large responses without blocking? Well maybe, except that
> async IO does not help you with generation of large content, it only
> helps with flushing of large buffers. Again rather than give direct
> access to IO, we could add an API on AsyncContext that says: write
> this buffer and call me back when it is all written. The container
> could then handle the details.... it might even use blocking IO if it
> is a on a blocking connector.
>
> Another use-case is to process large content on the fly without
> blocking. Perhaps we wanted to do this once, but now all the use
> cases for this are covered by websocket I think.
>
> Are there any other reasons for direct async IO?
Unlike the replacement designs you mention, async IO is not extremely
inefficient. On input it allows streaming without blocking, and on
output, it avoids any unexpected blocking (the possibility of blocking
is not related to writing large buffers, it is possible to block writing
small buffers too if the client isn't reading fast enough).
So since it looks like a good IO technique that would provide the best
scalability in terms of thread use, I think it is a must in the Servlet
API.
--
Remy Maucherat <rmaucher_at_redhat.com>
Red Hat Inc