8200458: (se) Readiness information previously recorded in the ready set not preserved

Alan Bateman Alan.Bateman at oracle.com
Thu Mar 29 20:31:06 UTC 2018

A number of networking tests that use the JDK's HTTP server have been 
tripping an assert in the HTTP server implementation lately. The assert 
arises when a key in the Selector's selected-key has an empty ready-set. 
The scenario to explain how this arises is complicated - it involves 
calling select twice, ignoring a key added to the selected-key in the 
first select, and closing the key's channel asynchronously at around the 
same time that the second select polls the file descriptor for the 
channel again.

The root of the issue is that the Selector implementations aren't 
preserving readiness information for keys in the selected key set. If a 
channel's key is already in the selected key set then its ready set is 
supposed to be updated to identify new operation but this isn't so. I 
had to dig into pre-OpenJDK history to see that there have been issues 
here for a long time. Most usages of Selectors are likely to remove the 
keys in the selected-key so they wouldn't see this issue, it's only 
cases where the selected keys aren't removed that this is noticed.

The changes to fix this are simple but it is a behavior change so a CSR 
and release notes would be appropriate if we fix this issue. I've run 
all tests on all platforms with the changes and the only issue I ran 
into was the fix for JDK-4737146 which I don't think was correct.

The webrev with the changes is here:


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180329/2058d64d/attachment.html>

More information about the nio-dev mailing list