tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: WebSocket status
Date Thu, 01 Mar 2012 11:31:48 GMT
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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message