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

[Chris Hegarty]

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