JDK-8361106 : [TEST] com/sun/net/httpserver/Test9.java fails with java.nio.file.FileSystemException
  • Type: Task
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 26
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • Submitted: 2025-06-30
  • Updated: 2025-11-11
  • Resolved: 2025-11-04
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 26
26 b23Fixed
Related Reports
Relates :  
Relates :  
Description
com/sun/net/httpserver/Test9.java fails with java.nio.file.FileSystemException due to File lock being held by another process

----------messages:(8/391)----------
command: main -Djava.net.preferIPv6Addresses=true Test9
reason: User specified action: run main/othervm -Djava.net.preferIPv6Addresses=true Test9 
started: Mon Jun 30 16:37:30 UTC 2025
Mode: othervm [/othervm specified]
Additional options from @modules: --add-modules jdk.httpserver,java.logging
Process id: 82992
finished: Mon Jun 30 16:37:32 UTC 2025
elapsed time (seconds): 1.903
----------configuration:(3/58)----------
Boot Layer
  add modules: jdk.httpserver java.logging

----------System.out:(1/11)----------
Test9: OK
----------System.err:(17/1790)*----------
java.nio.file.FileSystemException: C:\\sb\\prod\\1751301119\\testoutput\\test-support\\jtreg_open_test_jdk_tier2_part3\\scratch\\5\\com.sun.net.httpserver-Test9-17185654400056668684.tmp: The process cannot access the file because it is being used by another process
	at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:92)
	at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
	at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108)
	at java.base/sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:269)
	at java.base/sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:105)
	at java.base/java.nio.file.Files.delete(Files.java:1052)
	at Test9.main(Test9.java:126)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1474)

JavaTest Message: Test threw exception: java.nio.file.FileSystemException: C:\\sb\\prod\\1751301119\\testoutput\\test-support\\jtreg_open_test_jdk_tier2_part3\\scratch\\5\\com.sun.net.httpserver-Test9-17185654400056668684.tmp: The process cannot access the file because it is being used by another process
JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.nio.file.FileSystemException: C:\\sb\\prod\\1751301119\\testoutput\\test-support\\jtreg_open_test_jdk_tier2_part3\\scratch\\5\\com.sun.net.httpserver-Test9-17185654400056668684.tmp: The process cannot access the file because it is being used by another process
Comments
Changeset: 576f9694 Branch: master Author: Serhiy Sachkov <serhiy.sachkov@oracle.com> Committer: SendaoYan <syan@openjdk.org> Date: 2025-11-04 01:58:54 +0000 URL: https://git.openjdk.org/jdk/commit/576f9694b092f2a11a6a4e5a82c2b0e12203bd9c
04-11-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/28108 Date: 2025-11-03 11:06:35 +0000
03-11-2025

> I think it could be beneficial to allow each server some time to tidy up, so invoke stop with a few milliseconds timeout rather than the immediate 0 timeout. HttpServer::stop has been fixed recently, so it should be fine to call it with a wait time > 0. (see JDK-8304065) - if you intend to backport the fix - then consider backporting JDK-8304065 too.
01-07-2025

I think it could be beneficial to allow each server some time to tidy up, so invoke stop with a few milliseconds timeout rather than the immediate 0 timeout.
01-07-2025

besides the diagnosis of this issue -- this is very much a windows issue in how it handles file handles a couple of observations of other niggle issues in the test the static member variable error is set in non synchronised manner make it volatile or set with a synchronised (static) method the files in question could be set to deleteOnExit, which should obviate the need for explicit deletion. there is a temp file created within the Client run method and it is set to deleteOnExit, but it also explicitly invokes a temp.delete() in the main run block, which seems redundant, but from a consistency perspective, this should be moved to a finally block, to accommodate any Exceptions thrown and caught.
01-07-2025

I see two things can cause this issue: 1. `ClientThread`s started by `test()` that still run (there is a `join()`, but an earlier failure can make that code unreachable) 2. `executor.shutdown()` does not wait for the termination, hence `FileServerHandler` can still be accessing the file IMHO, both needs to be addressed. Alternatively, we can totally remove `Files.delete()` and rely on JTreg test data cleanup. Though a good scout should leave the campsite clean.
01-07-2025