jsr340-experts@servlet-spec.java.net

[jsr340-experts] Re: Non-blocking IO and async questions

From: Rémy Maucherat <rmaucher_at_redhat.com>
Date: Tue, 30 Apr 2013 13:01:47 +0200

On 04/30/2013 11:58 AM, Mark Thomas wrote:
> I'm working on finishing off Tomcat's non-blocking implementation and
> have come across the following scenarios that don't seem to be covered
> by the specification. I have have missed something please feel free to
> point me to the relevant part of the spec and/or Javadoc.
>
> All these scenarios start with the following:
>
> 1. Application calls ServletRequest.startAsync()
> 2. Application calls ServletInputStream.setReadListener() and/or
> ServletOutputStream.setWriteListener()
>
> so we have an async request using non-blocking IO for input and/or output.
>
>
> My questions are what happens if:
>
> A.
> The application starts a large async write and then calls
> AsyncContext.complete() or AsyncContext.dispatch() before the write has
> completed. Does this result in:
> a) an error?
> b) the delay of the complete() or dispatch() until the write has completed?
> c) something else?
>
> B.
> The applications starts a large async read and then calls
> AsyncContext.complete() or AsyncContext.dispatch() before all the data
> has been read. Does this result in:
> a) an error?
> b) the delay of the complete() or dispatch() until all the data has been
> read?
> c) complete() and dispatch() are processed as soon as control returns to
> the container and any unread data is available through the
> ServletInputStream via a blocking read?
> d) something else?
>
>
> My working assumptions at this point are A b) and B c)
Ab would be nicer. Hopefully it is possible to do it. As a reminder,
"large writes" are not a good idea with this API (better: the user
should call isReady and loop over a portion of the data).

For B, besides not knowing what a "large read" would be (the user is
never going to be able to read a large amount of data in a single read
call), I am not convinced since an sync read (= outside of a container
thread) does not make sense to me: the container in async mode will also
be busy doing its own read operations to be able to later call the
listener, and thus this could clash. There will also be nothing to
actually read until the listener is called, so what would be the point
of reading outside a container thread ?

Rémy