Mark,
for A we should do whatever we would do if another write was attempted
before the previous one had completed. Semantically you could argue that
complete is asking the container to "write" the end of message (ie flush
the buffers and write the end chunk marker if chunking), so complete is
essentially a write and so should act in the same way.
However the spec is not very clear on what should happen if a write is
attempted before a prior one has completed. My preference is that both
a write and a complete should throw a WritePendingException (just as NIO
does), however I guess the language on the isReady() method "This method
can be used to determine if data can be written without blocking." suggests
that a subsequent write should block. I don't like this might block
approach as it means that the API is not really asynchronous, it is just
mostly asynchronous if called in the right state. It might feel safer
that something will block if it can't execute asynchronously, but I think
having code unexpectedly blocking is likely to cause more problems than it
solves and also encourages lazy coding.
Ditto for scenario B, it should throw a ReadPendingException
the good thing about ReadPending and WritePending exceptions are that they
are ISE and thus are RuntimeExceptions and don't need to be declared in the
signature of complete()
regards
On 30 April 2013 19:58, Mark Thomas <markt_at_apache.org> 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)
>
> Cheers,
>
> Mark
>
--
Greg Wilkins <gregw_at_intalio.com>
http://www.webtide.com
Developer advice and support from the Jetty & CometD experts.
Intalio, the modern way to build business applications.