On 01/03/2012 18:00, Filip Hanik - Dev Lists wrote: > I see, MessageInbound has hard coded receive buffers. Got it
They are configurable, they just aren't currently configured. I've been meaning to apply a patch that would add some commented out configuration to the examples webapp so it can just be uncommented to run the Autobahn tests. I'll try and do that shortly. Mark > > Filip > > On 3/1/2012 10:13 AM, Filip Hanik - Dev Lists wrote: >> Mark, what buffer size are you referring to increase for the web >> socket tests to all pass? >> >> Filip >> >> On 3/1/2012 9:42 AM, Mark Thomas wrote: >>> 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 >>> >>> >> >> >> --------------------------------------------------------------------- >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
