On 01/03/2012 11:31, Mark Thomas wrote: > 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.
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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
