On 3/1/2012 5:33 AM, Mark Thomas wrote:
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.
I am going to take a look at it today. Commenting out a line like that doesn't
seem right. It's got to fit in with the flow.
The NIO is a fairly sensitive piece of code, and it's easy to break and get
problems like that.
Filip
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
