[jdk17u-dev] RFR: 8358764: (sc) SocketChannel.close when thread blocked in read causes connection to be reset (win) [v2]

[Voznia Anton]

On Wed, 29 Oct 2025 06:49:48 GMT, Goetz Lindenmaier <goetz at openjdk.org> wrote:

>>> 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.
>
> Hi @AlanBateman, thanks for having a look!

> > @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](https://github.com/openjdk/jdk21u-dev/pull/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.

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

PR Comment: https://git.openjdk.org/jdk17u-dev/pull/4076#issuecomment-3462045898