On 2/28/2012 11:39 AM, Mark Thomas wrote:
On 28/02/2012 16:58, Filip Hanik - Dev Lists wrote:
On 2/28/2012 4:08 AM, Mark Thomas wrote:
WebSocket is working with good performance and passing all Autobahn
tests on BIO, NIO and APR.
Currently, all three connectors using blocking IO throughout so there is
a one to one mapping between threads and connections. Therefore,
scalability is not what it could be for NIO and APR.
The remaining TODOs are:
Essential:
a) move to non-blocking between messages
b) address the threading issues around message sending
c) add some documentation
Nice to haves:
- better examples (Petr Praus, Jonathan Drake& Slávka are working on a
chat application)
- non-blocking throughout for NIO (requires much more state to be
maintained and a change to the API - not sure it is worth it)
I did this for Comet in the sandbox, and it is totally doable. But in my
opinion, it's not worth the effort. It is much easier to just increase
the buffer size at the network level, and voila, it wont block. I can't
imagine WebSocket's message based system would be using very large
messages, it's definitely not suited for that.
Thanks for the feedback.
You may also be able to help with some problems I am having getting
non-blocking behaviour between messages with NIO. I'm not 100% clear
what is happening yet, but I think it is something like:
- HTTP GET (with upgrade request arrives
- Upgrade is processed
- no ws frame on the wire (yet) so process of handing back to the
selector starts
- first ws frame arrives
- socket is handed back to the selector
- selector *does not* trigger indicating there is data to process
- some delay of a few seconds
- client sends another ws frame
- selector triggers
- both frames are processed
I can take a look at this, I've not seen this behavior before, it's been very
accurate.
I can force this behaviour 100% of the time with the debugger and it
looks very similar to the issues we see intermittently with the Comet
unit tests where two messages are processed at once.
I am wondering if we have a race condition somewhere in the NIO code
between:
- determining there is no data to read
- handling the socket back to the selector
- new data arriving
and if it is possible that for a particular sequence of events we can
end up in the state where there is data to be read but the selector
doesn't think so.
I would normally assume my non-blocking code is doing something stupid
(which it may well be anyway) but the similarity to the problem with the
Comet unit test makes me suspect at least one root cause may be elsewhere.
Any thoughts appreciated.
(Note all of my non-blocking changes are currently sitting on my local
hard drive. I can provide them if that would help.)
Send it my way, I will take a look
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
