On 05/17/2013 05:54 AM, Greg Wilkins wrote:
>
> I'm belatedly getting stuck into our implementation of non blocking IO
> and have a few things that I'd like to see clearer in the spec.
>
> Consider the following code:
>
> request.startAsync();
> response.getOutputStream().setWriteListener(myListener);
> request.getInputStream().setReadListener(myListener);
> return;
>
>
> The javadoc tells us that the listener will be called back as soon as
> it is possible to read/write and in most circumstances this will be
> immediately.
>
> Is it an acceptable implementation to have the thread that called the
> set listener methods immediately call back the listeners from within
> the scope of the set call?
> If not, then I'd prefer to avoid dispatching another thread for this
> and instead use the thread that was dispatched to the servlet to call
> the listeners after it returns to the container. So is it OK to defer
> the call back until after that return or does that contravene the "as
> soon as it is possible"?
I think all three solutions are valid actually.
>
> Then I believe that we wish to have only a single thread dispatched to
> the request at a time, so we should not call the read listener methods
> in parallel to the write listener methods. So if both are ready,
> which one should we call first? As we are a server, I assume we
> should try reading before we try writing?
I am not certain it is possible to have a deterministic priority between
read and write.
>
> Note that because we are only 1 thread per request, it is really
> important that we do not let multiple calls to read/write block, as we
> could end up deadlocking ourselves with large content. So as per my
> previous message, we should throw read/write pending exceptions rather
> than block.
Looking at some of the more creative uses of the API, like websockets,
Mark found some issues and there has been a discussion about having
concurrent read/write, or autoblocking (both should allow implementing
websockets, but experimentation is ongoing).
Rémy