On 30/04/2013 12:01, Rémy Maucherat wrote:
> 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 ?
Sorry. Poor explanation on my part. By "large async read" I meant a
non-blocking read after startAsync() on a container thread when there is
more data available to read than the application chooses to.
Mark