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)

          [JENKINS-20913] [jar caching] - winp.x64.dll access conflicts

          Oleg Nenashev created issue -
          Oleg Nenashev made changes -
          Link New: This issue is related to JENKINS-20759 [ JENKINS-20759 ]

          boris ivan added a comment -

          Yeah, this one is killing me. This is an exact duplicate of the bug I logged previously: 20759. Hoping to see some activity on this soon, it's extraordinarily painful. Curious, do your remote build agents run as a process or from the command line (cmd/powershell/etc)?

          boris ivan added a comment - Yeah, this one is killing me. This is an exact duplicate of the bug I logged previously: 20759. Hoping to see some activity on this soon, it's extraordinarily painful. Curious, do your remote build agents run as a process or from the command line (cmd/powershell/etc)?

          boris ivan added a comment -

          One additional note: with other CI servers (TC) with the same JRE running the same Maven goal (integration-test) with the same version of Maven on a build agent running the same version of windows, etc... this has never occurred. Therefore I don't think it's something that is contained within the Maven build itself. It's either plugin related or something else Jenkins specific that interacts with this that causes the scenario to occur. But on each of my 6 remote Jenkins build slaves running various different Maven projects, this always occurs 1-2 times a week.

          boris ivan added a comment - One additional note: with other CI servers (TC) with the same JRE running the same Maven goal (integration-test) with the same version of Maven on a build agent running the same version of windows, etc... this has never occurred. Therefore I don't think it's something that is contained within the Maven build itself. It's either plugin related or something else Jenkins specific that interacts with this that causes the scenario to occur. But on each of my 6 remote Jenkins build slaves running various different Maven projects, this always occurs 1-2 times a week.

          kishorerp added a comment - - edited

          We are seeing this on win8/8.1 slaves once in a week!!
          slave.jar crashes with the above error
          we are on Jenkins LTS 1.532.1 running on CentOs6.5
          also, at the end of each job, the above issue occurs everytime!!

          kishorerp added a comment - - edited We are seeing this on win8/8.1 slaves once in a week!! slave.jar crashes with the above error we are on Jenkins LTS 1.532.1 running on CentOs6.5 also, at the end of each job, the above issue occurs everytime!!

          Oleg Nenashev added a comment -

          @Kishore

          If I understand toy correctly, you see the following issue:

          Unable to render embedded object: File (..can this be fixed please) not found.

          If yes, I suppose that this is an another issue. Please create ticket for it

          Oleg Nenashev added a comment - @Kishore If I understand toy correctly, you see the following issue: Unable to render embedded object: File (..can this be fixed please) not found. If yes, I suppose that this is an another issue. Please create ticket for it

          kishorerp added a comment -

          @Oleg

          Not sure how that embedded object got added.
          We are seeing the same [jar caching] - winp.x64.dll access conflicts mentioned above

          kishorerp added a comment - @Oleg Not sure how that embedded object got added. We are seeing the same [jar caching] - winp.x64.dll access conflicts mentioned above

          This issue is killing the whole continuous integration process. Do we have any workaround or any time line to get this fixed?

          Murali Devakumar added a comment - This issue is killing the whole continuous integration process. Do we have any workaround or any time line to get this fixed?

          Oleg Nenashev added a comment -

          @Murali
          Currently there is no solutions or ETAs.

          As a workaround, you can disable Jar caching by calling a "hudson.remoting.Engine.current().setJarCache(null)" to disable the cache (e.g. call a System Groovy script on the node).

          // Probably, it is possible to pass null via "-jar-cache" CLI parameter.

          Oleg Nenashev added a comment - @Murali Currently there is no solutions or ETAs. As a workaround, you can disable Jar caching by calling a "hudson.remoting.Engine.current().setJarCache(null)" to disable the cache (e.g. call a System Groovy script on the node). // Probably, it is possible to pass null via "-jar-cache" CLI parameter.

          @Oleg,
          Thanks for quick response.

          Can you please be more elaborate on either of options and I am running slave as windows service, which limits me with CLI parameters.

          Murali Devakumar added a comment - @Oleg, Thanks for quick response. Can you please be more elaborate on either of options and I am running slave as windows service, which limits me with CLI parameters.

            oleg_nenashev Oleg Nenashev
            oleg_nenashev Oleg Nenashev
            Votes:
            14 Vote for this issue
            Watchers:
            19 Start watching this issue

              Created:
              Updated:
              Resolved: