https://bz.apache.org/bugzilla/show_bug.cgi?id=61736
--- Comment #3 from ZILONG SONG <sz...@qq.com> --- Yes, the queue is custom implemented, but it still works following the rule of a non-blocking queue. I'm afraid that the problem is not caused by how the queue works, but how we use a queue. Perhaps a more basic reason for this problem is that, the cancelled keys are still cached. A cancelled key is invalid and cannot be used again, so it should not be cached. If invalid keys are not cached, or they can recover from the invalid state, we may not wake the Worker thread up when handling events, so it's possible to avoid this problem. However how the SelectionKey will behave is controlled in the JDK, out of our control. I didn't find anyway other than performing a selection that can clear the invalid SelectionKey caches. So I think maybe the most effective action to take is to prevent the BlockPoller to cost too much time in the loop polling and handling events, and let the next selection to clear the invalid SelectionKeys as soon as possible. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
