jsr340-experts@servlet-spec.java.net

[jsr340-experts] Re: Do we really need async IO

From: Remy Maucherat <rmaucher_at_redhat.com>
Date: Wed, 07 Mar 2012 08:47:43 +0100

On Wed, 2012-03-07 at 09:20 +1100, Greg Wilkins wrote:
>
> Here is the kind of java7 inspired API I'm thinking about to add to
> AsyncContext:
>
>
>
> /* ------------------------------------------------------------ */
> /**
> * Write the buffer and then call the completion handler
> * @param buffer
> * @param handler
> */
> public void write(ByteBuffer
> buffer,CompletionHandler<Boolean,AsyncContext> handler)
> {
> }
>
> /* ------------------------------------------------------------ */
> /**
> * Write the file and then call the completion handler
> * @param file
> * @param handler
> */
> public void write(File file, CompletionHandler<Boolean,
> AsyncContext> handler)
> {
> }
>
> /* ------------------------------------------------------------ */
> /**
> * Read the request content into memory so that it is available
> * from the {_at_link ServletRequest#getInputStream()} API without
> blocking
> * and then call the completion handler
> * @param attachment
> * @param handler
> */
> public <A> void read(CompletionHandler<Boolean,AsyncContext>
> handler)
> {
> }
>
> /* ------------------------------------------------------------ */
> /**
> * Read the request content into the file and then call the
> completion handler
> * @param file
> * @param handler
> */
> public <A> void read(File file, CompletionHandler<Boolean,
> AsyncContext> handler)
> {
> }

I don't understand how it can be efficient, although I get the idea it
can provide most of the functionality.

Besides encouraging using temp files, which I find quite horrible,
write(ByteBuffer) has to wait for the servlet to return, then call the
completion handler, before the servlet can write again. That's a large
lag between each write. On the async API we propose, it is possible the
servlet can continue writing, thus avoiding a costly round trip to the
container.

We have a big (unique) opportunity to provide an API which would do the
full thing efficiently, let's not waste it.

-- 
Remy Maucherat <rmaucher_at_redhat.com>
Red Hat Inc