Re: [servlet-dev] AsyncContext.complete() whilst red/write blocked

[Mark Thomas <markt@xxxxxxxxxx>]

On 30/11/2020 16:45, Greg Wilkins wrote:
> 
> We've had a report of the following behaviour from JBoss Resteasy:
> 
>  1. servlet calls `request.startAsync()` and then starts 2 non container
>     threads before returning.
>  2. Thread-A blocks in a call to `request.getInputStream().read()`
>  3. Thread-B calls `asyncContext.complete()`
> 
> Because there is no container thread dispatched to the app, the handling
> of `complete()` can start straight away.  But what should be done with
> the blocked read?

Something doesn't seem right with the design here.

Using async moves processing off a container thread only to block in a
different thread doing a blocking read? That seems an overly complex
approach when adding threads to the container thread pool would achieve
the same result with a lot less complexity.

I'd have expected non-blocking I/O to have been used here.

> Perhaps the blocked read should throw an IOexception, but then the app
> might catch it and start operating on the request/response, which may be
> recycled to have been reused.

Async error handling is one of the areas we need to clarify.

> So is it an error to call `complete()` in this way?

Tentative yes.

> The spec says that request/response are not thread safe in general, so is having 2 threads
> operating on them in this way supported?

Tentative no.

> Shouldn't the app be required
> to make sure other threads have stopped operating on the
> request/response before doing a complete?

Tentative yes.

> So complete could throw an ISE in this circumstance.

Tentative yes.

> thoughts?

I'm trying to square the behaviour above with section 2.3.3.4.

At best, the behaviour for this scenario is undefined. complete() is
thread-safe so arguably that call is OK. But what happens to the
in-progress read? Certainly as soon as the read exits the thread should
no longer use the request or response but handling the in-progress read
is undefined. Allow it to complete? Interrupt it? Throw an IOE?
Something else?

I guess we need to decide if we want to allow this sort of usage or not
and then improve the spec language accordingly. I'd lean towards not
allowing it but a good use case could convince me to change my mind.

Mark