JDK-8278369 : java/nio/channels/Channels/TransferTo.java hangs in testStreamContents
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.nio
  • Affected Version: 18,19,20
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • OS: windows
  • CPU: x86_64
  • Submitted: 2021-12-07
  • Updated: 2023-01-08
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.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8278469 - Test java/nio/channels/FileChannel/LargeGatheringWrite.java times out
Relates :  
JDK-8278166 - java/nio/channels/Channels/TransferTo.java timed out
Relates :  
JDK-8282296 - (se) Pipe.open() creates a Pipe implementation that uses Unix domain sockets (win)
Sub Tasks
JDK-8280233 :  
Temporarily disable Unix domain sockets in Windows PipeImpl - Resolved
JDK-8280944 :  
Enable Unix domain sockets in Windows Selector notification mechanism - Resolved
Description
The following test timed out in the JDK18 CI:

java/nio/channels/Channels/TransferTo.java

Here's a snippet from the log file:

#section:testng
----------messages:(6/224)----------
command: testng TransferTo
reason: User specified action: run testng/othervm/timeout=180 TransferTo 
Mode: othervm [/othervm specified]
Timeout information:
--- Timeout information end.
elapsed time (seconds): 741.449
----------configuration:(0/0)----------
----------System.out:(9/651)----------
Seed from RandomFactory = -2139475181596097368L
test TransferTo.testIllegalBlockingMode(): success
test TransferTo.testMoreThanTwoGB(): success
test TransferTo.testNullPointerException(TransferTo$2@4e95475, TransferTo$4@4d48f6ee): success
test TransferTo.testNullPointerException(TransferTo$2@4cfdf64b, TransferTo$5@2f9495d): success
test TransferTo.testNullPointerException(TransferTo$2@5f5b8bcd, TransferTo$6@7cb771c3): success
test TransferTo.testNullPointerException(TransferTo$3@5e2c68b1, TransferTo$1@19d223de): success
test TransferTo.testStreamContents(TransferTo$2@2d1e9e6d, TransferTo$4@409aa16b): success
Timeout refired 720 times
----------System.err:(0/0)----------
----------rerun:(40/5695)*----------


This failure happened in jdk-18+27-1900-tier2 which include the fix for:

JDK-8278166 java/nio/channels/Channels/TransferTo.java timed out
Comments
[~michaelm] Should we close this as a dup of JDK-8279916?
08-01-2023
It looks like the timeout occurred while the test was in the testMoreThanTwoGB() sub-test which tests a file-to-file transfer of more than 2 GB. This would seem to be indicative of slow file system access.
05-07-2022
Here's a log file snippet from the jdk-20+5-182-tier2 sighting: java/nio/channels/Channels/TransferTo.java #section:testng ----------messages:(6/223)---------- command: testng TransferTo reason: User specified action: run testng/othervm/timeout=180 TransferTo Mode: othervm [/othervm specified] Timeout information: --- Timeout information end. elapsed time (seconds): 953.28 ----------configuration:(0/0)---------- ----------System.out:(3/128)---------- Seed from RandomFactory = -5950939689694927945L test TransferTo.testIllegalBlockingMode(): success Timeout refired 720 times ----------System.err:(0/0)---------- ----------rerun:(39/5669)*---------- <snip> result: Error. Program `c:\ade\mesos\work_dir\jib-master\install\jdk-20+5-182\windows-x64.jdk\jdk-20\bin\java' timed out (timeout set to 720000ms, elapsed time including timeout handling was 953258ms).
30-06-2022
I assume the cause is JDK-8279916.
15-01-2022
Reassigning to Michael for now.
04-01-2022
The Windows behavior looks a lot like a Windows bug. I will investigate that and see if it can be reproduced with a native test case to give to Microsoft.
26-12-2021
I think the issue is the Unix domain socket implementation of Pipe that is used on Windows 10+ and Windows Server 2019+. More specifically, if there is a large number of writes to the sink and it immediately closes its end then a reader on the source side does not read EOF. As a test, I changed the implementation to use a TCP socket so that it works like Windows 8 or Windows Server 2016 and no hang/timeout is observed with 300 runs. When I switch it back to the Unix domain socket implementation then there are intermittent hangs/timeouts on Windows 10, Windows Server 2019 and Windows Server 2022 systems. We'll need to look at it more closely in the new year but it may be that we are dealing with a Windows bug rather than a JDK bug.
24-12-2021