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

[Kurchi Hazra]

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