On 01/03/2012 15:03, Filip Hanik - Dev Lists wrote: > >> I have a draft patch [1] that seems to fix this. A similar change would >> be required for the Comet part of Poller.processKey() >> >> Thoughts and/or comments? Not knowing the NIO code very well, there >> might be a better way to achieve the same result that I haven't seen. >> >> Mark >> >> [1] >> http://people.apache.org/~markt/patches/draft/2012-03-01-trunk-nio.patch > > I took a look at the patch. IMHO it's not the right way to go.
That doesn't surprise me. You know the NIO code better than I do. > You're adding in flags to compensate for the state machine in the selector. Yep. On that topic, I couldn't find any decent information on the state machine in the selector. Do you know of any? There was a fair amount of guess work involved investigating this issue and a clearer picture of the state machine would help develop a better patch. > And by doing so, you will have the selector run more than it needs to Yep. > cause you have read interest turned on, Yep. > on sockets that you are already processing, Yep. Agree with you completely up to this point. > wasting CPU cycles. This part I wasn't so sure of. There is a problem here that affects WebSocket badly and Comet intermittently and fixing that problem may well require the trade off of additional processing. I compared the NIO blocking figures I have and the NIO non-blocking figures to see if there was a noticeable performance difference. The patch does impact performance. Typically it is <3% but for large numbers of small packets it can be as high as ~15%. On this basis my patch is clearly far from ideal. I look forward to seeing what insights you have on how best to solve this for both WebSocket and Comet. Interestingly, I don't recall anything that suggests that this problem affects HTTP although it isn't impossible that there is a very slim window somewhere where HTTP may be affected. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
