-
Improvement
-
Resolution: Fixed
-
Minor
-
Jenkins LTS 2.107.1 on Windows Server 2008 R2 x64,
ws-cleanup 0.34, resource-disposer 0.8
Hi!
In our environment with 4 agents and many concurrent builds (of different jobs), the log contains many entries like:
Apr 13, 2018 5:26:09 AM WARNING hudson.util.AtomicFileWriter commit
Unable to move atomically, falling back to non-atomic move.
java.nio.file.AccessDeniedException: C:\webserver\Jenkins\atomic466027149674640611tmp -> C:\webserver\Jenkins\org.jenkinsci.plugins.resourcedisposer.AsyncResourceDisposer.xml
at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:83)
at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
at sun.nio.fs.WindowsFileCopy.move(WindowsFileCopy.java:301)
at sun.nio.fs.WindowsFileSystemProvider.move(WindowsFileSystemProvider.java:287)
at java.nio.file.Files.move(Files.java:1395)
at hudson.util.AtomicFileWriter.commit(AtomicFileWriter.java:191)
at hudson.XmlFile.write(XmlFile.java:198)
at org.jenkinsci.plugins.resourcedisposer.AsyncResourceDisposer.persist(AsyncResourceDisposer.java:201)
at org.jenkinsci.plugins.resourcedisposer.AsyncResourceDisposer.access$400(AsyncResourceDisposer.java:73)
at org.jenkinsci.plugins.resourcedisposer.AsyncResourceDisposer$WorkItem.run(AsyncResourceDisposer.java:286)
at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
IMHO - I think, this issue is caused by (quasi) concurrent writes by the method persist() in AsyncResourceDisposer.java.
Therefore, I have built an private variant of this plugin to test, whether this issue can be fixed by simply adding the synchronized-keyword to the definition of the the persist-method (in the Java-class AsyncResourceDisposer). This has fixed this issue; I.e., there are no log-entries of this kind since about 2 days ...
Note: Maybe, my suggested fix should be used in a next release (after review of the maintainer)?
Best regards from Salzburg,
Markus
- relates to
-
JENKINS-52402 Job fails randomly when attempt to lock resources
- Open
-
JENKINS-52404 Job fails randomly when using copyArtifact
- Fixed but Unreleased