On 04/30/2013 12:21 PM, Mark Thomas wrote:
> On 29/04/2013 10:51, Rémy Maucherat wrote:
>> Looking back at the details, in particular in the "concurrency"
>> discussion on the topic, the application needs to wait for a write to
>> finish before starting a new one (thus, no queue is supposed to be
>> needed). With the socket NIO2 implementation, you also have to wait for
>> a write to complete - async or not - before doing a new one on a given
>> socket, or get a WritePendingException. In websockets, I was "sold" the
>> NIO2 style, not crazy concurrency scenarios, but there's nothing really
>> clear in the specification (the WritePendingException is not there).
> WebSocket does require the previous message to have been sent before the
> next message is sent (unless in batch mode but the way that is defined
> doesn't really change things).
>
> The spec and Javadoc isn't as clear as it could be but sending a message
> before the previous message has finished will trigger an ISE.
Ok, thanks. It's an important item, too bad it is not so clear.
> My question with auto blocking is how does the Servlet container know
> if a read or write is meant to be blocking or not? The user code (the
> WebSocket implementation) knows but there is no API that enables it to
> tell the container. I had originally thought that flush() could be
> used to do this (i.e. block if flush() is called) but as you pointed
> out, that might work in an HTTP upgrade scenario but not in a Servlet
> one. Using flush(0 in this way would work for WebSocket since it used
> HTTp upgrade but having the same method behave differently for HTYTP
> Upgrade and async servlets doesn't seem right either.
It should be possible to make the decision about blocking or not by
using isReady. If isReady is used when doing the reads/writes, it will
not block. If isReady is not used, and things occurs inside a container
thread, it blocks (I never thought it would be a good idea to block an
async thread).
>> Wouldn't MessageHandler.Whole<InputStream> cause a problem on read ?
>> Since it would have to block and a simulated blocking done in the user
>> code couldn't possibly get another "concurrent" read event to continue
>> reading.
> The container is required to buffer the message until it is fully
> received so there is no blocking when user code does the read.
>
> So far, I haven't found any blockers to using allowing one read thread
> and one write thread.
Ok, that avoids the issue (it could cause other problems, but not this one).
Rémy