failures in unit tests on temp directory deletion

[Slide]

I have noticed this in two different plugins now. During the tearDown method, if the test created a file of some sort (in one cases its created using a BufferedWriter, in another case it is the log for a DumbSlave machine). In both cases, an exception is thrown by TemporaryDirectoryAllocator.dispose as you can see below. Another person has also seen the issue while building the email-ext plugin (the failures occur in the matrix testing) and I also see the issue on the token-macro plugin during the property file test. 

OS: Windows 7 64-bit

JAVA_HOME=C:\Program Files\Java\jdk1.6.0_30 (64-bit JDK)

Maven Version: 3.0.3

testPreBuildMatrixBuildSendParentOnly(hudson.plugins.emailext.ExtendedEmailPublisherMatrixTest)  Time elapsed: 16.912 sec  <<< ERROR!

hudson.util.IOException2: Failed to clean up temp dirs

at org.jvnet.hudson.test.TemporaryDirectoryAllocator.dispose(TemporaryDirectoryAllocator.java:87)

at org.jvnet.hudson.test.TestEnvironment.dispose(TestEnvironment.java:53)

at org.jvnet.hudson.test.HudsonTestCase.tearDown(HudsonTestCase.java:355)

at hudson.plugins.emailext.ExtendedEmailPublisherMatrixTest.tearDown(ExtendedEmailPublisherMatrixTest.java:46)

at junit.framework.TestCase.runBare(TestCase.java:140)

at org.jvnet.hudson.test.HudsonTestCase.runBare(HudsonTestCase.java:267)

at junit.framework.TestResult$1.protect(TestResult.java:110)

at junit.framework.TestResult.runProtected(TestResult.java:128)

at junit.framework.TestResult.run(TestResult.java:113)

at junit.framework.TestCase.run(TestCase.java:124)

at junit.framework.TestSuite.runTest(TestSuite.java:232)

at junit.framework.TestSuite.run(TestSuite.java:227)

at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)

at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:45)

at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:119)

at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:101)

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:597)

at org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)

at $Proxy0.invoke(Unknown Source)

at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150)

at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91)

at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)

Caused by: java.io.IOException: Unable to delete C:\Users\USER\AppData\Local\Temp\hudson5080588723723698775test\slave-slave0.log

at hudson.Util.deleteFile(Util.java:266)

at hudson.Util.deleteRecursive(Util.java:316)

at hudson.Util.deleteContentsRecursive(Util.java:227)

at hudson.Util.deleteRecursive(Util.java:307)

at hudson.FilePath$9.invoke(FilePath.java:826)

at hudson.FilePath$9.invoke(FilePath.java:824)

at hudson.FilePath.act(FilePath.java:758)

at hudson.FilePath.act(FilePath.java:740)

at hudson.FilePath.deleteRecursive(FilePath.java:824)

at org.jvnet.hudson.test.TemporaryDirectoryAllocator.dispose(TemporaryDirectoryAllocator.java:82)

... 24 more

--
Website: http://earl-of-code.com

[Brian J]

It appears that this, and the previously mentioned thread dumps are all occurring in HudsonTestCase.tearDown() itself. It looks like some things aren't shut down in a way that will unlock the files from a windows OS perspective.

If anyone else cares to take a look, we're looking at:

https://github.com/jenkinsci/email-ext-plugin/blob/master/src/test/java/hudson/plugins/emailext/ExtendedEmailPublisherMatrixTest.java 

Line 49 is where these exceptions are coming from. 

[Mark Waite]

I think the exception is expressing reality.  Windows won't allow an open file to be deleted.  It is an unfortunate reality, but it is reality as far as I know (and a source of failures in automated builds I've seen).

 

Are you proposing that the plugins should hide that exception, or that they should do something else (queue the file for deletion on next reboot, etc.)?

 

Mark Waite

[Richard Lavoie]

Imo deleting an open file is pretty much running toward problems, what's better should that the clean up/teardown calls close the files they have open and leave in a clean state.

My 2cents

Richard

[Slide]

The question is why the file is still open. In the case of the token macro plugin, it explicitly closes the BufferedWriter used to create the file during the unit test. I think it has something to do with jetty, but I need to play around with some things. Is it possible to build plugins against a local build of jenkins core?

[Slide]

In both cases, the files should be closed by the time it reaches teardown according to the code, but this is not the case, and it only happens on windows from what I can tell.

[Slide]

FYI, I think it MIGHT have something to do with this [1] but I am not sure how to update Jetty in a local Jenkins build in order to try what they say to do to stop the locking.

slide

[1] http://docs.codehaus.org/display/JETTY/Files+locked+on+Windows 

--
Website: http://earl-of-code.com

[Slide]

I am very unfamiliar with the Jenkins build process, but is the resolution in [1] below something that could easily be tested with my plugin build?

--
Website: http://earl-of-code.com

[Christian Wolfgang]

Did you solve the problem? I am experiencing it now?

Br
Christian

[Slide]

No, I never got a resolution, I did file an issue [1] but I don't think it has been resolved yet.

slide

[1]  https://issues.jenkins-ci.org/browse/JENKINS-12768 

--
Website: http://earl-of-code.com