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:
http://cr.openjdk.java.net/~alanb/8200458/webrev/index.html
-Alan
-------------- 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