United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4919127 : (so spec) Confusing relationship between OP_CONNECT and OP_WRITE

Details
Type:
Bug
Submit Date:
2003-09-08
Status:
Open
Updated Date:
2012-01-07
Project Name:
JDK
Resolved Date:
Component:
core-libs
OS:
linux,generic,windows_xp
Sub-Component:
java.nio
CPU:
x86,generic
Priority:
P4
Resolution:
Unresolved
Affected Versions:
1.4.2,5.0
Targeted Versions:
tbd_major

Related Reports
Duplicate:
Duplicate:

Sub Tasks

Description
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.

                                    

Comments
EVALUATION

Due to timing and synchronization issues we can't check the validity of
operation masks in selection keys with respect to the current state of a
channel.  The interest mask in a selection key is simply a request for
readiness information which will be fulfilled at some future time if and when
that information becomes available.

It would not be appropriate to specify any sort of connection between
OP_CONNECT and OP_WRITE, since that is an implementation artifact.

We should clarify the language in the Selector spec which promises that a
blocking select method will only return after at least one channel is selected
unless the request times out, is woken up, or is interrupted.

-- ###@###.### 2003/11/16
                                     
182-11-11 0



Hardware and Software, Engineered to Work Together