On 29/04/2013 10:51, Rémy Maucherat wrote:Ok, thanks. It's an important item, too bad it is not so clear.
Looking back at the details, in particular in the "concurrency"WebSocket does require the previous message to have been sent before the
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).
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.
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).
Ok, that avoids the issue (it could cause other problems, but not this one).Wouldn't MessageHandler.Whole<InputStream> cause a problem on read ?The container is required to buffer the message until it is fully
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
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.
[servlet-spec users] [jsr340-experts] Re: NIO specification clarification
[servlet-spec users] [jsr340-experts] Re: Re: Re: Re: NIO specification clarification