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.
Thanks,
- Kurchi
