On 7 March 2012 09:36, Remy Maucherat <rmaucher_at_redhat.com> wrote:
>
> 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).
>
Remy,
my proposal does not require blocking at all. The calls to write (or read)
return immediately and the container takes the responsibility for doing the
actual async IO flushing the buffer (or fill of the file/buffer). Only
once the container has completed the flush (or fill) does it call the
complete handler.
So my proposal is a little contrary to my initial post - which asked if we
needed async IO... I then posted a suggestion for a very simple async API.
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.
>
Sure, we don't want servlet threads blocking while waiting for bytes to be
flushed or filled. But does that mean we need the fill read ready / write
ready notification stuff? Why not just follow JDK-7 and have
completion call backs. That way the servlet does not need to ever deal
with partial writes or reads, nor does it need to wait for them to
complete. It simply get called back when they are done.
This allows the container to do the IO in the most efficient way and does
not mean we have to enter application scope on every IO action.
cheers