RFR: 8334719: (se) Deferred close of SelectableChannel may result in a Selector doing the final close before concurrent I/O on channel has completed

[Jaikiran Pai]

On Tue, 25 Jun 2024 11:47:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to fix the issue noted in https://bugs.openjdk.org/browse/JDK-8334719?
>> 
>> Alan's comment in that issue summarizes what this issue is about https://bugs.openjdk.org/browse/JDK-8334719?focusedId=14684071&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14684071. As noted there, the deferred close implementation in several of the `SelectableChannel` implementations have a bug where they don't check for in-progress operations on the channel when closing/releasing the underlying resources of the channel. We started noticing this with `DatagramChannel` consistenly, but the issue is applicable for other channel implementations as well. 
>> 
>> The fix for the issue in this PR has been provided by Alan and I've run the necessary tests several thousand times to verify that it fixes the original issue. 
>> 
>> A new jtreg test has been introduced to reproduce the bug and verify the fix. Without the fix, the new test consistently fails for all test method (except for ServerSocketChannel, where it isn't easy to trigger a race). With the fix all tests consistently pass.
>> 
>> A successful test run of the new test takes around 60 seconds. So I've intentionally set a timeout of 4 minutes on the test to allow for some leeway on slow CI systems.
>> 
>> Another round of tier testing with these changes is currently in progress.
>
> test/jdk/java/nio/channels/Selector/DeferredCloseTest.java line 466:
> 
>> 464: 
>> 465:     private static final class DelayInjectingNIOAccess implements JavaNioAccess {
>> 466:         private final JavaNioAccess realJavaNioAccess = SharedSecrets.getJavaNioAccess();
> 
> We can't have tests implementing this interface as it puts on a tax on every change to this interface (it changes regular). So I think we need to drop this and come up with an another way to test this scenario.

Understood. I'll take a look at the code and see what else we can do.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19879#discussion_r1652658010