Code Review Request: 8014254: Selector in HttpServer introduces a 1000 ms delay when using KeepAlive

[Chris Hegarty]

Thanks Kurchi, the changes look fine to me.

-Chris.

On 09/05/2013 22:15, Kurchi Hazra wrote:
> I have re-arranged the code a little, so that the events are handled
> first, any freed up
> connections are then registered with the selector, post which select()
> is called. This
> removes the bottleneck in a single threaded server receiving requests
> from the same client
> with a high frequency.
>
> http://cr.openjdk.java.net/~khazra/8014254/webrev.01/
>
> - Kurchi
>
> On 5/9/13 1:45 AM, Chris Hegarty wrote:
>> On 05/09/2013 01:56 AM, Kurchi Hazra wrote:
>>>
>>> On 5/8/2013 4:35 PM, Matthew Hall wrote:
>>>> On Wed, May 08, 2013 at 04:06:10PM -0700, Kurchi Hazra wrote:
>>>>> com.sun.net.httpServer uses a selector to get notified about
>>>>> interesting
>>>>> events (such as arrival of a new connection, or data available to read
>>>>> on an existing connection when using keep-alive), but imposes a
>>>>> timeout of
>>>>> 1000 ms on the select() operation.
>>>> Maybe I'm missing something since the bug is not viewable to the
>>>> community,
>>>> but, if I'm reading properly, this design by itself is not quite
>>>> right, and
>>>> the fix of 200 msec selector timeout is just a band-aid solution.
>>>>
>>>> Shouldn't it be registering interestOps for reading on the existing
>>>> connections and accepting connections from the server socket in the
>>>> selector?
>>>> Otherwise why use any selector in the first place if it's not really
>>>> selecting
>>>> across all the right sockets and right events on them?
>>>
>>> - If you look at the implementation, this is exactly what is done.
>>> However, for keep-alive, the implementation delays the re-registering of
>>> a used channel
>>> for reading until after one select call, which results in the
>>> bottleneck. The other option is to re-register existing channels before
>>> the select call, this is what
>>> was done in jdk6. But I would need to understand why we walked away from
>>> that. Michael or Chris can shed some light on this.
>>
>> I'm not sure why this changed from jdk6, but I don't see any reason it
>> cannot be reverted back.
>>
>> -Chris.
>>
>>>
>>>
>>>
>>> Thanks,
>>> - Kurchi
>