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
