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 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.) Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
