Occasional "Access is denied" message with <groovyc>

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).

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

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)

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

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

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.

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.

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

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

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

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

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