On 03/04/2014 15:21, Przemyslaw Bielicki wrote:
I tried - exactly the same results.
Another weird observation is that ServletOutputStream.isReady() is
returning true even after the connection is closed
(ServletInputStream.isFinished() is correctly returning true).
Here's the scenario that works but I can write back the data only once:
1. In HttpUpgradeHandler I set only the ReadListener
2. I switch the protocol and send some data
3. ReadListener gets activated i.e. onDataAvailable() is called.
4. I process the input data, read as much as possible and put the
input into the queue
5. From within ReadListener I set the WriteListener
6. WriteListener.onWritePossible() gets called and I process the data
- I clean the queue
7. As long as I'm in WriteListener.onWritePossible()
(while.out.isReady() is constantly returning true, which is a correct
bahavior) the ReadListener is on-hold. I can send as much data as I
like but onDataAvailable() is not called
8. Only when I leave WriteListener.onWritePossible() method the
ReadListener.onDataAvailable() is called again and I can consume the
input data again.
9. I can process the input data again i.e. put it into the queue but
WriteListener.onWritePossible() is never called again. When I try to
reset it I get IllegalStateException
Either the specification or implementation seem not very mature....
Wildfly behavior is consistent with the one of Tomcat.
At the moment I conclude that the non-blocking write is not possible
in Servlet 3.1.
I would appreciate if someone can provide an example that actually
works or explain why the weird behavior I observe is correct (is it?)
This looks as
expected (although Tomcat 8 should concurrently call
read/write in upgraded mode, as a proprietary extension to be able to
implement Websockets on top of Servlets 3.1, besides that Servlet 3.1 is
still not concurrent, so at most one thread processing a request a given
time).
Non blocking IO means it allows avoiding to block on IO, it doesn't
imply anything else. Servlets 3.1 is actually async IO (similar to NIO2,
rather than NIO1), since non blocking IO is unusable as is.
Rémy