On 28/02/2012 21:29, Mark Thomas wrote: > On 28/02/2012 18:53, Filip Hanik - Dev Lists wrote: >> On 2/28/2012 11:39 AM, Mark Thomas wrote: > >>> 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 take a look at this, I've not seen this behavior before, it's been >> very accurate. > > Very similar behaviour has been observed in the unit tests for Comet > with the NIO connector ever since they were introduced. > >> Send it my way, I will take a look
I have done a little more experimentation and if I comment out line 1231 in the NioEndpoint: unreg(sk, attachment,sk.readyOps()); (part of the NIO Poller) all the problems I see with NIO + Autobahn + non-blocking reads go away. This is consistent with the description above. However, I don't think the solution is as simple as just commenting out this line as that would result in multiple calls to processSocket(), most of which would not be required and each call to processSocket() results in a thread being allocated to process the data. That said, I think some additional logic in process socket could handle this safely. What I think is happening is that because we call SelectionKey.interestOps(0) to prevent the poller triggering multiple times for the same request there is currently a small window where data can arrive for the next request that isn't read by a processing thread and doesn't trigger the poller. I have been thinking about a solution to this but I haven't written any code yet. Where I think we'll end up is with a small window where two poller events may be triggered for the same request which would result in an extra thread being allocated for a short period of time. I know more when I actually write the code. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
