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
