Seems that JAR caching also takes DLL files on Windows.
Thanks to Windows architecture (
), it leads to access conflicts, because DDLs may be locked by other process.
The issue is being heavily reproduced during the process. After several hours, any process termination fails with the FileNotFoundException exception (see the log below).
Probably, the high frequency of the issue is somehow related to "Cygwin Process Killer" plugin. On my installation it calls additional remote call on the node before any process termination (it is an interim workaround for JENKINS-19156 and JENKINS-20289 in the custom 1.509.4 core build).
Dec 07, 2013 7:02:28 AM org.jvnet.winp.Native load
WARNING: Failed to write winp.x64.dll
java.io.FileNotFoundException: C:\Users\XXX\.jenkins\cache\jars\01\winp.x64.dll (The process cannot access the file because it is being used by another process)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.<init>(Unknown Source)
at java.io.FileOutputStream.<init>(Unknown Source)
at org.jvnet.winp.Native.load(Native.java:81)
at org.jvnet.winp.Native.<clinit>(Native.java:52)
at org.jvnet.winp.WinProcess.enableDebugPrivilege(WinProcess.java:200)
at hudson.util.ProcessTree$Windows.<clinit>(ProcessTree.java:470)
at hudson.util.ProcessTree.get(ProcessTree.java:335)
at hudson.Launcher$RemoteLauncher$KillTask.call(Launcher.java:899)
at hudson.Launcher$RemoteLauncher$KillTask.call(Launcher.java:890)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:326)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at hudson.remoting.Engine$1$1.run(Engine.java:63)
at java.lang.Thread.run(Unknown Source)
Dec 07, 2013 7:02:35 AM hudson.util.ProcessTree get
WARNING: Failed to load winp. Reverting to the default
java.lang.UnsatisfiedLinkError: Native Library C:\Users\XXX\.jenkins\cache\jars\01\winp.x64.dll already loaded in another classloader
at java.lang.ClassLoader.loadLibrary1(Unknown Source)
at java.lang.ClassLoader.loadLibrary0(Unknown Source)
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.load0(Unknown Source)
at java.lang.System.load(Unknown Source)
at org.jvnet.winp.Native.loadDll(Native.java:158)
at org.jvnet.winp.Native.load(Native.java:90)
at org.jvnet.winp.Native.<clinit>(Native.java:52)
at org.jvnet.winp.WinProcess.enableDebugPrivilege(WinProcess.java:200)
at hudson.util.ProcessTree$Windows.<clinit>(ProcessTree.java:470)
at hudson.util.ProcessTree.get(ProcessTree.java:335)
at hudson.Launcher$RemoteLauncher$KillTask.call(Launcher.java:899)
at hudson.Launcher$RemoteLauncher$KillTask.call(Launcher.java:890)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:326)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at hudson.remoting.Engine$1$1.run(Engine.java:63)
at java.lang.Thread.run(Unknown Source)