Date: Tue, 12 Aug 2003 17:14:09 -0700
From: Michael Mccloskey <###@###.###>
Subject: spinning Selector

The Selector spin that in the workspace I examined is because of the 
following situation.

Because of an inconsistency between DefaultHttpTransaction believing the 
channel was connected or not, vs whether the channel believed it was
connected or not, the selector would spin. There is a boolean field 
DefaultHttpTransaction.connected that does not always agree with 
channel.isConnected().

This caused spin because of one of two possibilities:
 
1. The channel was not connected, the key interested in writing and
   the key ready for writing. Because the key is ready for something it
   is interested in, the select operation returns immediately, but the
   key is not marked as ready for write, because the channel is not
   in the connected state, therefore the key was not added to the selected
   set. So the selector spins and returns 0.

2. The channel was connected, the key interested in connecting and 
   the key ready for connecting. Because the key is ready for something it
   is interested in, the select operation returns immediately, but the
   key is not marked as ready to connect, because the channel is already
   connected. Therefore the key was not added to the selected set, the
   selector spins and returns 0.


Date: Wed, 13 Aug 2003 09:30:35 +0100
From: Michael McMahon <###@###.###>

>This caused spin because of one of two possibilities:
> 
>1. The channel was not connected, the key interested in writing and
>   the key ready for writing. Because the key is ready for something it
>   is interested in, the select operation returns immediately, but the
>   key is not marked as ready for write, because the channel is not
>   in the connected state, therefore the key was not added to the selected
>   set. So the selector spins and returns 0.
>
Are you saying this is not a bug in nio? If so, there seems to be a 
subtle undocumented relationship
between OP_WRITE and OP_CONNECT.
At the OS level "writability" implies "connected" and is documented as 
such, but it seems as if NIO
wants apps to wait for OP_CONNECT before checking OP_WRITE, but this is 
not specified
and therefore cannot be enforced.

Would it not make more sense to specify this behavior and throw an 
exception if someone calls
select with OP_WRITE before the socket is connected? That way, 
developers would recognise the
problem much sooner, rather than :-
- noticing a strange performance problem,
- diagnosing that the selector is spinning
- then filing a nio bug in frustration.

Alternatively, the docs for  SelectionKey should spell this out in more 
detail.

>2. The channel was connected, the key interested in connecting and 
>   the key ready for connecting. Because the key is ready for something it
>   is interested in, the select operation returns immediately, but the
>   key is not marked as ready to connect, because the channel is already
>   connected. Therefore the key was not added to the selected set, the
>   selector spins and returns 0.

This is the converse of the above. Once a channel is connected, the app 
really should not check
for OP_CONNECT. It would be nice if developers were alerted to this, by 
getting an exception
rather than their app spinning.