Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <4F4FB940.3060303@hanik.com>
Date: Thu, 01 Mar 2012 11:00:32 -0700
From: Filip Hanik - Dev Lists <devlists@hanik.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: WebSocket status
References: <4F4CB5A4.3040104@apache.org> <4F4D07B4.6040201@hanik.com>
 <4F4D1F6D.10004@apache.org> <4F4D229C.8050108@hanik.com>
 <4F4D473C.30701@apache.org> <4F4F5E24.2030301@apache.org>
 <4F4F6CA0.3090709@apache.org> <4F4F8FB5.4070302@hanik.com>
 <4F4FA713.7090902@apache.org> <4F4FAE38.6080204@hanik.com>
In-Reply-To: <4F4FAE38.6080204@hanik.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I see, MessageInbound has hard coded receive buffers. Got it

Filip

On 3/1/2012 10:13 AM, Filip Hanik - Dev Lists wrote:
> Mark, what buffer size are you referring to increase for the web socket tests to all pass?
>
> Filip
>
> On 3/1/2012 9:42 AM, Mark Thomas wrote:
>> On 01/03/2012 15:03, Filip Hanik - Dev Lists wrote:
>>>> 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
>>> I took a look at the patch. IMHO it's not the right way to go.
>> That doesn't surprise me. You know the NIO code better than I do.
>>
>>> You're adding in flags to compensate for the state machine in the selector.
>> Yep. On that topic, I couldn't find any decent information on the state
>> machine in the selector. Do you know of any? There was a fair amount of
>> guess work involved investigating this issue and a clearer picture of
>> the state machine would help develop a better patch.
>>
>>> And by doing so, you will have the selector run more than it needs to
>> Yep.
>>
>>> cause you have read interest turned on,
>> Yep.
>>
>>> on sockets that you are already processing,
>> Yep. Agree with you completely up to this point.
>>
>>> wasting CPU cycles.
>> This part I wasn't so sure of. There is a problem here that affects
>> WebSocket badly and Comet intermittently and fixing that problem may
>> well require the trade off of additional processing. I compared the NIO
>> blocking figures I have and the NIO non-blocking figures to see if there
>> was a noticeable performance difference.
>>
>> The patch does impact performance. Typically it is<3% but for large
>> numbers of small packets it can be as high as ~15%. On this basis my
>> patch is clearly far from ideal. I look forward to seeing what insights
>> you have on how best to solve this for both WebSocket and Comet.
>>
>> Interestingly, I don't recall anything that suggests that this problem
>> affects HTTP although it isn't impossible that there is a very slim
>> window somewhere where HTTP may be affected.
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org