JDK-6240230 : (se) Selector doesn't act on keys with matching interestOps and readyOps
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 1.4.2_07,5.0u2
  • Priority: P4
  • Status: Resolved
  • Resolution: Not an Issue
  • OS: solaris_9
  • CPU: generic,sparc
  • Submitted: 2005-03-14
  • Updated: 2018-03-28
  • Resolved: 2018-03-28
Related Reports
Duplicate :  
Description
selectionKeys with readyOps that match interestOps are not picked up by the selector that they are registered with. This seems to only happen when interestOps are dynamically updated (with approproate synchronisation safeguards) on a registered key. 

The test case uses the standard pattern for developing a multi-threaded, NIO-based, network server at least up to the point in which inetestOps are modified for a Write event. Start the test case specifying a port number and 'false' as arguments and then connect to the port via telnet. Type something and hit return. Tne most frequently seen behaviour is that the app disconnects you, if you then repeat this step a few times, ultimately you do not get disconnected. On my test environment it always broke on the first connect. If 'false' is replaced on the command line with 'true' an extra level of synchronisation is added around the call to select() and this resolves the problem.

This problem is not reproducible on all systems and does not occur on Windows (and possibly Linux). 


###@###.### 2005-03-14 17:34:37 GMT

Comments
This is no longer an issue so I am closing this bug.
28-03-2018

EVALUATION The analysis in this bug is correct and the copyout of the revents replaces the events in the poll array so any updates are lost. The issue is specific to Solaris when the poll Selector used. As the /dev/poll Selector is the default on Solaris it means that customers should not be impacted by this issue. In jdk7 we plan to address 6429204 which deals with concurrency issues updating the interest events and this fix will also address this bug.
15-01-2007

WORK AROUND Workaround is to use an extra level of synchronisation around the call to select() ###@###.### 2005-03-14 17:34:37 GMT
14-03-2005