groovy
  1. groovy
  2. GROOVY-3112

Occasional "Access is denied" message with <groovyc>

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.5.6, 1.5.7, 1.6-beta-2
    • Fix Version/s: 1.6-rc-1, 1.5.8, 1.7-beta-1
    • Component/s: class generator
    • Labels:
      None
    • Environment:
      Windows Server 2003 R2 SP2 (virtual machine)
      Intel Xeon CPU
      Java 1.5.0_12
      Ant 1.7.0
    • Number of attachments :
      0

      Description

      I've seen this problem with 1.5.6, 1.5.7, and 1.6-beta-2.

      Occasionally I am seeing a IOException "Access is denied" during <groovyc>.

      The stacktrace mentions java.io.IOException: Access is denied at java.io.WinNTFileSystem.createFileExclusively(Native Method) when the groovy compiler is trying to create a temp dir (FileSystemCompiler.createTempDir).

      I put code in to look for an exception that says "java.io.IOException: Access is denied". If it happens, I have it retry. I think it usually passes the second time.

      An improvement would be to keep this from happening or to retry when it happens.

      Here are interesting parts of the stacktrace:

      : Compilation Failed at org.codehaus.groovy.ant.Groovyc.compile(Groovyc.java:798) at org.codehaus.groovy.ant.Groovyc.execute(Groovyc.java:531)

      java.io.IOException: Access is denied at org.codehaus.groovy.ant.Groovyc.makeCompileUnit(Groovyc.java:820) at org.codehaus.groovy.ant.Groovyc.compile(Groovyc.java:783) ... 170 more

      Caused by: java.io.IOException: Access is denied at java.io.WinNTFileSystem.createFileExclusively(Native Method) at java.io.File.checkAndCreate(File.java:1345) at java.io.File.createTempFile(File.java:1434) at java.io.File.createTempFile(File.java:1471) at org.codehaus.groovy.tools.FileSystemCompiler.createTempDir(FileSystemCompiler.java:266) at org.codehaus.groovy.ant.Groovyc.makeCompileUnit(Groovyc.java:816) ... 171 more

      — Nested Exception ---java.io.IOException: Access is denied at org.codehaus.groovy.ant.Groovyc.makeCompileUnit(Groovyc.java:820) at org.codehaus.groovy.ant.Groovyc.compile(Groovyc.java:783) at org.codehaus.groovy.ant.Groovyc.execute(Groovyc.java:531) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105) at org.apache.tools.ant.Task.perform(Task.java:348) at groovy.util.AntBuilder.nodeCompleted(AntBuilder.java:204) at groovy.util.BuilderSupport.doInvokeMethod(BuilderSupport.java:153) at groovy.util.AntBuilder.doInvokeMethod(AntBuilder.java:154) at groovy.util.BuilderSupport.invokeMethod(BuilderSupport.java:64) at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:41) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:41) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:128) at com.sas.djte.library.DJTE$_buildTestware_closure3.doCall(DJTE.groovy:119) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86) at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234) at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:271) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:845) at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.callCurrent(PogoMetaClassSite.java:58) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:45) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:142) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:150)

        Issue Links

          Activity

          Hide
          Danno Ferrin added a comment -

          This is mostly the result of a Sun bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6325169.

          One thing you can do is go to your temp dir and remove all "groovy-*" files and directories. Groovyc wasn't reliably deleting them in Groovy 1.6-Beta 1, and some quirks with windows still occasionally causes issues reliably deleting those files (File.delete is called but the file isn't actually deleted).

          Show
          Danno Ferrin added a comment - This is mostly the result of a Sun bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6325169 . One thing you can do is go to your temp dir and remove all "groovy-*" files and directories. Groovyc wasn't reliably deleting them in Groovy 1.6-Beta 1, and some quirks with windows still occasionally causes issues reliably deleting those files (File.delete is called but the file isn't actually deleted).
          Hide
          Danno Ferrin added a comment -

          One twits that I am fixing that may be contributing to these errors. Whenever a joint compilation fails the stub dir is not deleted, so your temp dir could become littered with old stub dir directories, contributing to the temp file collision. I have added code to 1.7 and soom to 1.6-RC-1 that will delete these files inside of a finally block, since an exception was what was causing the delete code to not be called.

          Show
          Danno Ferrin added a comment - One twits that I am fixing that may be contributing to these errors. Whenever a joint compilation fails the stub dir is not deleted, so your temp dir could become littered with old stub dir directories, contributing to the temp file collision. I have added code to 1.7 and soom to 1.6-RC-1 that will delete these files inside of a finally block, since an exception was what was causing the delete code to not be called.
          Hide
          John Lewis added a comment -

          Please let me know when you commit to 1.6. I will do a build and deploy it.

          Show
          John Lewis added a comment - Please let me know when you commit to 1.6. I will do a build and deploy it.
          Hide
          John Lewis added a comment -

          I downloaded the 1.7 snapshot from the CI server on 12/4. Unfortunately, this problem is still appearing. Here is the new stacktrace:

          moreCaused by: java.io.IOException: Access is denied
          at java.io.WinNTFileSystem.createFileExclusively(Native Method)
          at java.io.File.checkAndCreate(File.java:1345)
          at java.io.File.createTempFile(File.java:1434)
          at java.io.File.createTempFile(File.java:1471)
          at org.codehaus.groovy.tools.FileSystemCompiler.createTempDir(FileSystemCompiler.java:276)
          at org.codehaus.groovy.ant.Groovyc.makeCompileUnit(Groovyc.java:825)
          ... 171 more

          — Nested Exception —
          java.io.IOException: Access is denied
          at org.codehaus.groovy.ant.Groovyc.makeCompileUnit(Groovyc.java:829)
          at org.codehaus.groovy.ant.Groovyc.compile(Groovyc.java:786)
          at org.codehaus.groovy.ant.Groovyc.execute(Groovyc.java:534)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at java.lang.reflect.Method.invoke(Method.java:585)
          at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
          at org.apache.tools.ant.Task.perform(Task.java:348)
          at groovy.util.AntBuilder.nodeCompleted(AntBuilder.java:204)
          at groovy.util.BuilderSupport.doInvokeMethod(BuilderSupport.java:153)
          at groovy.util.AntBuilder.doInvokeMethod(AntBuilder.java:154)
          at groovy.util.BuilderSupport.invokeMethod(BuilderSupport.java:64)
          at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:45)
          at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:43)
          at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
          at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:128)

          Show
          John Lewis added a comment - I downloaded the 1.7 snapshot from the CI server on 12/4. Unfortunately, this problem is still appearing. Here is the new stacktrace: moreCaused by: java.io.IOException: Access is denied at java.io.WinNTFileSystem.createFileExclusively(Native Method) at java.io.File.checkAndCreate(File.java:1345) at java.io.File.createTempFile(File.java:1434) at java.io.File.createTempFile(File.java:1471) at org.codehaus.groovy.tools.FileSystemCompiler.createTempDir(FileSystemCompiler.java:276) at org.codehaus.groovy.ant.Groovyc.makeCompileUnit(Groovyc.java:825) ... 171 more — Nested Exception — java.io.IOException: Access is denied at org.codehaus.groovy.ant.Groovyc.makeCompileUnit(Groovyc.java:829) at org.codehaus.groovy.ant.Groovyc.compile(Groovyc.java:786) at org.codehaus.groovy.ant.Groovyc.execute(Groovyc.java:534) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at groovy.util.AntBuilder.nodeCompleted(AntBuilder.java:204) at groovy.util.BuilderSupport.doInvokeMethod(BuilderSupport.java:153) at groovy.util.AntBuilder.doInvokeMethod(AntBuilder.java:154) at groovy.util.BuilderSupport.invokeMethod(BuilderSupport.java:64) at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:45) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:43) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:128)
          Hide
          blackdrag blackdrag added a comment -

          org.codehaus.groovy.tools.FileSystemCompiler.createTempDir(FileSystemCompiler.java:276) is

          File tempFile = File.createTempFile("groovy-generated-", "-java-source");

          I very much assume this is caused by http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6325169

          Show
          blackdrag blackdrag added a comment - org.codehaus.groovy.tools.FileSystemCompiler.createTempDir(FileSystemCompiler.java:276) is File tempFile = File.createTempFile( "groovy-generated-" , "-java-source" ); I very much assume this is caused by http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6325169
          Hide
          blackdrag blackdrag added a comment -

          since there is no proposed workaround and since the bug is already 4 years old we maybe should think of something... I see 3 ways here:

          1. close this as won't fix, since it is not our bug
          2. retry the file creation a couple of times
          3. let the user input the directory

          probably number 2 is the best for now

          Show
          blackdrag blackdrag added a comment - since there is no proposed workaround and since the bug is already 4 years old we maybe should think of something... I see 3 ways here: close this as won't fix, since it is not our bug retry the file creation a couple of times let the user input the directory probably number 2 is the best for now
          Hide
          blackdrag blackdrag added a comment -

          I made a commit to Groovy 1.7 that tries version 2. Could you please checkout trunk and try that? It seems a windows system is required to reproduce the problem and I have none.

          Show
          blackdrag blackdrag added a comment - I made a commit to Groovy 1.7 that tries version 2. Could you please checkout trunk and try that? It seems a windows system is required to reproduce the problem and I have none.
          Hide
          John Lewis added a comment -

          I deployed the new SNAPSHOT yesterday. I have seen one instance so far with this message:

          java.io.IOException: Access is denied. We tried 3 times to create a temporary directory and failed each time. If you are on Windows you are possibly victim to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6325169. this is no bug in Groovy.

          Otherwise, things seem to be working fine.

          Show
          John Lewis added a comment - I deployed the new SNAPSHOT yesterday. I have seen one instance so far with this message: java.io.IOException: Access is denied. We tried 3 times to create a temporary directory and failed each time. If you are on Windows you are possibly victim to http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6325169 . this is no bug in Groovy. Otherwise, things seem to be working fine.
          Hide
          blackdrag blackdrag added a comment -

          so it works, but I had hoped this would have fixed the bug... maybe I should then implement way 3 too

          Show
          blackdrag blackdrag added a comment - so it works, but I had hoped this would have fixed the bug... maybe I should then implement way 3 too
          Hide
          John Lewis added a comment -

          I wouldn't bother with #3. I think with enough retries, it will eventually pass.

          Before you made your change, I put in retry mechanism with a 30 sec sleep in between. I don't think it ever took more than 5 retries before succeeding.

          If I would do anything, I would increase the number of times from 3 and possibly put in a sleep in between.

          Thanks for you help on this.

          John

          Show
          John Lewis added a comment - I wouldn't bother with #3. I think with enough retries, it will eventually pass. Before you made your change, I put in retry mechanism with a 30 sec sleep in between. I don't think it ever took more than 5 retries before succeeding. If I would do anything, I would increase the number of times from 3 and possibly put in a sleep in between. Thanks for you help on this. John
          Hide
          blackdrag blackdrag added a comment -

          but then we would have users complaining that the compiler is so slow on windows machines

          Show
          blackdrag blackdrag added a comment - but then we would have users complaining that the compiler is so slow on windows machines
          Hide
          John Lewis added a comment -

          I see your concern, but from my experience, the problem occurs very rarely. I maintain a continuous integration system. I'd say there are at least 20 projects that use the groovyc ant task to build Groovy classes throughout the day. I'd say there are easily a hundred invocations a day. I only see this problem on average about 4 or 5 times a week.

          Note that I am only advocating a sleep if the "access is denied" problem occurs the first time. In most cases it will not happen the first time. It is my experience that with a sleep, it succeeds the second time.

          John

          Show
          John Lewis added a comment - I see your concern, but from my experience, the problem occurs very rarely. I maintain a continuous integration system. I'd say there are at least 20 projects that use the groovyc ant task to build Groovy classes throughout the day. I'd say there are easily a hundred invocations a day. I only see this problem on average about 4 or 5 times a week. Note that I am only advocating a sleep if the "access is denied" problem occurs the first time. In most cases it will not happen the first time. It is my experience that with a sleep, it succeeds the second time. John
          Hide
          blackdrag blackdrag added a comment -

          John, could you try one more time? I added an delay of 100ms and the option to let the user define the stub directory. I think if the delay is not working, then it is possibly really better to use an explicit stub directory

          Show
          blackdrag blackdrag added a comment - John, could you try one more time? I added an delay of 100ms and the option to let the user define the stub directory. I think if the delay is not working, then it is possibly really better to use an explicit stub directory

            People

            • Assignee:
              blackdrag blackdrag
              Reporter:
              John Lewis
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: