JDK-8200569 : (se) Readiness information previously recorded in the ready set not preserved
  • Type: CSR
  • Component: core-libs
  • Sub-Component: java.nio
  • Priority: P3
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 11
  • Submitted: 2018-04-02
  • Updated: 2018-04-09
  • Resolved: 2018-04-04
Related Reports
CSR :  
Description
Summary
-------

The java.nio.channels.Selector API specifies precisely how selection operations add selection keys to the Selector's selected-key set or update the readiness information of selection keys already in the set. The JDK implementations do not implement this correctly with the result that previous readiness information is lost when a channel is selected for a disjoint set of ready operations.

Problem
-------

The "Selection" section in the Selector API docs is clear that readiness information is preserved:

"Otherwise the channel's key is already in the selected-key set, so its ready-operation set is modified to identify any new operations for which the channel is reported to be ready. Any readiness information previously recorded in the ready set is preserved; in other words, the ready set returned by the underlying system is bitwise-disjoined into the key's current ready set."

The problem is that the Selector implementations in the JDK do not implement this correctly as they override the readiness information, thus losing any previous readiness information.

The issue has gone unreported for a long time, we believe this is because the majority of frameworks/servers using this API clear the selected-key set after selection operations (as per the recommended usage). However the scenario does arise with the JDK's HTTP server module where it uses the `selectNow()` API to flush cancelled keys and ignores any selection keys added to the selected-key set. A subsequent `select()` may replace the readiness information for a key in the set, thus losing the ready-set information that was set when previously selected. (We diagnosed this issue while chasing intermittent test failures with some networking tests).


Solution
--------

Update the implementation to align with the specification. We don't think changing the specification to align with broken behavior is the right solution in this case.

We do not propose to introduce a system property or other means to revert to JDK 10 or older behavior at this time. We will re-evaulate this again once there has been more testing of JDK 11 EA builds (5 of the 6 Selector implementations have been reworked in JDK 11 so we are already reaching out to users of the API to get some help testing the new implementations).

This behavior change is release note worthy.


Specification
-------------

There are no specification changes proposed.


Comments
Moving to Approved; agree that a release note is appropriate.
04-04-2018