8358764: (sc) SocketChannel.close when thread blocked in read causes connection to be reset (win)

[GoeLin]

I backport this for parity with 17.0.18-oracle.

Needed resolve and adaptions:

Net.java: resolved static initializer.
SocketChannelImpl.java: In implCloseBlockingMode(), the code guarded by the new condition is not in 17. Omitted.
Update: I added this later.

Net.c: Copyright.

The test exercises platform and virtual threads.
I simplified this to what is supported in 17.
See extra commit.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• JDK-8358764 needs maintainer approval

Issue

• JDK-8358764: (sc) SocketChannel.close when thread blocked in read causes connection to be reset (win) (Bug - P3 - Requested)

Reviewers

• Martin Doerr (@TheRealMDoerr - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk17u-dev.git pull/4076/head:pull/4076
$ git checkout pull/4076

Update a local copy of the PR:
$ git checkout pull/4076
$ git pull https://git.openjdk.org/jdk17u-dev.git pull/4076/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 4076

View PR using the GUI difftool:
$ git pr show -t 4076

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk17u-dev/pull/4076.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back goetz! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

This backport pull request has now been updated with issue from the original commit.

[mlbridge]

Webrevs

• 03: Full - Incremental (c16a2c8e)
• 02: Full - Incremental (58cce4b1)
• 01: Full - Incremental (bdb4707e)
• 00: Full (d57767e8)

[TheRealMDoerr]

It is true that the affected part of implCloseBlockingMode() has been introduced with Loom, but it looks relevant without Loom, too. Note that implCloseNonBlockingMode() handles StandardSocketOptions.SO_LINGER, too.

Without this change, your PR basically only adds a test because shouldShutdownWriteBeforeClose() is unused.

diff --git a/src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java b/src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java
index a771d998b24..09c9ed4df99 100644
--- a/src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java
+++ b/src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java
@@ -1019,7 +1019,19 @@ class SocketChannelImpl
     private void implCloseBlockingMode() throws IOException {
         synchronized (stateLock) {
             assert state < ST_CLOSING;
+            boolean connected = (state == ST_CONNECTED);
             state = ST_CLOSING;
+
+            if (connected && Net.shouldShutdownWriteBeforeClose()) {
+                // shutdown output when linger interval not set to 0
+                try {
+                    var SO_LINGER = StandardSocketOptions.SO_LINGER;
+                    if ((int) Net.getSocketOption(fd, SO_LINGER) != 0) {
+                        Net.shutdown(fd, Net.SHUT_WR);
+                    }
+                } catch (IOException ignore) { }
+            }
+
             if (!tryClose()) {
                 long reader = readerThread;
                 long writer = writerThread;

[TheRealMDoerr]

Thanks! This backport LGTM, now. It would be great if someone from the core-libs team could confirm that the SO_LINGER code is adequate for 17u.

[openjdk]

⚠️ @GoeLin This change is now ready for you to apply for maintainer approval. This can be done directly in each associated issue or by using the /approval command.

[GoeLin]

Hi @AlanBateman and Kieran Farrell,

do you mind having a look at this?
The code patched by the original change in SocketChannelImpl.java
is not in 17. Do you think it is ok to include this in 17 along with
this change? It seems to be a fix independent of the loom change that added it.

Thanks! Goetz.

[AlanBateman]

Hi @AlanBateman and Kieran Farrell,

do you mind having a look at this? The code patched by the original change in SocketChannelImpl.java is not in 17. Do you think it is ok to include this in 17 along with this change? It seems to be a fix independent of the loom change that added it.

From a quick look then it seems okay. In sun.nio.ch.Net then shutdownWriteBeforeClose can be eagerly or lazily initialized, you've chosen to do it lazily which is okay.

The split of the blocking/non-blocking code paths had several motivations, the issue is specific to the (less common) case of using a SocketChannel blocking mode so I think you've got it right.

[GoeLin]

Hi @AlanBateman, thanks for having a look!

[antonvoznia]

LGTM in general.
Since Java 17 doesn't have virtual threads, perhaps remove the mention of them from the comment.

[GoeLin]

Hi @antonvoznia , Good point, I replaced it by the version of your PR.
Also, I merged head, this resolves the macos failure in the tests.

[antonvoznia]

@GoeLin
btw, it seems the introduced test passes always.
I ran it with jtreg on windows arm without the fix in place.
Did I run it incorrectly? 🤔

[TheRealMDoerr]

@GoeLin btw, it seems the introduced test passes always. I ran it with jtreg on windows arm without the fix in place. Did I run it incorrectly? 🤔

Does the test from openjdk/jdk21u-dev#2137 always fail in jdk21u without the fix?
I guess that the problem is better reproducible with loom.
Ah, I can see that your test in #3936 is different. Can it reproduce the issue better?

[antonvoznia]

@GoeLin btw, it seems the introduced test passes always. I ran it with jtreg on windows arm without the fix in place. Did I run it incorrectly? 🤔

Does the test from openjdk/jdk21u-dev#2137 always fail in jdk21u without the fix? I guess that the problem is better reproducible with loom. Ah, I can see that your test in #3936 is different. Can it reproduce the issue better?

@TheRealMDoerr for me, it's reproducible with the test from my PR.