JDK-8282726 : java/net/vthread/BlockingSocketOps.java timeout/hang intermittently on Windows
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 21,22,repo-loom
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2022-03-07
  • Updated: 2025-04-28
  • Resolved: 2023-11-21
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 21 JDK 22
21.0.8-oracleFixed 22 b25Fixed
Related Reports
Duplicate :  
JDK-8315544 - java/nio/channels/vthread/BlockingChannelOps.java timed out with ZGC
Duplicate :  
JDK-8281538 - java/lang/Thread/virtual/NetSockets.java and NioChannels.java timeout/hang intermittently on windows in loom repo
Duplicate :  
JDK-8272749 - java/foreign/channels/TestSocketChannels.java times out on windows with virtual threads
Relates :  
JDK-8281538 - java/lang/Thread/virtual/NetSockets.java and NioChannels.java timeout/hang intermittently on windows in loom repo
Relates :  
JDK-8315544 - java/nio/channels/vthread/BlockingChannelOps.java timed out with ZGC
Relates :  
JDK-8308466 - com/sun/jdi/BadHandshakeTest.java timed out
Sub Tasks
JDK-8337884 :  
Problem List java/foreign/channels/TestSocketChannels.java on Windows - Resolved
Description
The following tests timeout periodically, usually Windows Server 2016 and 2019 :

java/net/vthread/BlockingSocketOps.java
java/nio/channels/vthread/BlockingChannelOps.java
com/sun/jdi/BadHandshakeTest.java
Comments
Fix request [21u] I backport this for parity with 21.0.8-oracle. Lowish risk, limited to nio. Well tested. I needed to resolve. Tests pass. SAP nighlty testing passed.
24-04-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk21u-dev/pull/1699 Date: 2025-04-23 13:23:17 +0000
23-04-2025
Changeset: 21a59b9f Author: Alan Bateman <alanb@openjdk.org> Date: 2023-11-21 14:05:32 +0000 URL: https://git.openjdk.org/jdk/commit/21a59b9f4e46ebd32cff8f1000fe9ad56c918431
21-11-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/16742 Date: 2023-11-20 16:08:10 +0000
21-11-2023
The wepoll based poller prefers to re-arm to avoid re-registering at each I/O operation, thus closesocket means that wepoll has an AFD_POLL_LOCAL_CLOSE to deal with. It seems the race is when a SOCKET handle is immediately re-used by Windows.
20-11-2023
Created a ticket with wepoll here: https://github.com/piscisaureus/wepoll/issues/34 As a quick hack, I commented out this line: https://github.com/openjdk/jdk/blob/9902d2eb177072c108933056cba544cc5a34bb54/src/java.base/windows/native/libnio/ch/wepoll.c#L1891 This seems to solve the issue; this was not evaluated for possible side effects.
17-11-2023
It's a classic race in wepoll. Adding a Sleep(30) in port__poll just before EnterCriticalSection [1] makes the attached Connect.java test fail every time. Debugger pointed out that when the test gets stuck, wepoll does not monitor any handles. Windows can not notify us of a successful connect, because we don't ask it to. [1] https://github.com/openjdk/jdk/blob/1588dd934ce4e00a060e329b80f721d894559597/src/java.base/windows/native/libnio/ch/wepoll.c#L1260
17-11-2023
I've attached a test case that can be used to duplicate this issue more frequently. It needs to be copied into test tree and run as a regular jtreg test. The test duplicates the issue about 5 in 1000 runs, always Windows Server 2016 or Windows Server 2012.
29-04-2022
The most frequent "hang" appears to be when creating a Pipe for testPipeXXX tests. A Pipe creates a loopback connection and the hang appears to be because the "connect" never wakes up. The stack trace is shown below. The client socket that is connecting is in non-blocking mode, the underlying SOCKET is registered with the wepoll library (based on the AFD for WinSock). It needs the event that the connection has been established or failed to continue but the event never comes. -- VirtualThread[#60]/waiting -- java.base/jdk.internal.vm.Continuation.yield(Continuation.java:371) java.base/java.lang.VirtualThread.yieldContinuation(VirtualThread.java:371) java.base/java.lang.VirtualThread.doPark(VirtualThread.java:542) java.base/java.lang.VirtualThread.park(VirtualThread.java:523) java.base/java.lang.System$2.parkVirtualThread(System.java:2579) java.base/jdk.internal.misc.VirtualThreads.park(VirtualThreads.java:54) java.base/java.util.concurrent.locks.LockSupport.park(LockSupport.java:369) java.base/sun.nio.ch.Poller.poll2(Poller.java:139) java.base/sun.nio.ch.Poller.poll(Poller.java:102) java.base/sun.nio.ch.Poller.poll(Poller.java:89) java.base/sun.nio.ch.SelChImpl.park(SelChImpl.java:86) java.base/sun.nio.ch.SelChImpl.park(SelChImpl.java:109) java.base/sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:888) java.base/java.nio.channels.SocketChannel.open(SocketChannel.java:285) java.base/sun.nio.ch.PipeImpl$Initializer$LoopbackConnector.run(PipeImpl.java:133) java.base/sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:85) java.base/sun.nio.ch.PipeImpl$Initializer.run(PipeImpl.java:67) java.base/java.security.AccessController.doPrivileged(AccessController.java:569) java.base/sun.nio.ch.PipeImpl.<init>(PipeImpl.java:198) java.base/sun.nio.ch.PipeImpl.<init>(PipeImpl.java:182) java.base/sun.nio.ch.SelectorProviderImpl.openPipe(SelectorProviderImpl.java:64) java.base/java.nio.channels.Pipe.open(Pipe.java:155) NioChannels.lambda$testPipeWriteAsyncClose$23(NioChannels.java:592) TestHelper.lambda$run$0(TestHelper.java:48) java.base/java.lang.VirtualThread.run(VirtualThread.java:289) java.base/java.lang.VirtualThread$VThreadContinuation.lambda$new$0(VirtualThread.java:174) java.base/jdk.internal.vm.Continuation.enter0(Continuation.java:341) java.base/jdk.internal.vm.Continuation.enter(Continuation.java:334)
10-04-2022