On 11/07/2013 11:19 AM, Michael McMahon wrote:
Chris,
Would it be useful to add some instrumentation/logging (to System.err)
if it's taking
more than one iteration to delete a file? We could end up with degraded
test performance if there is a general problem deleting files, and
otherwise would have
no way of understanding what the problem is (eg. up to 7.5 seconds are
allowed to delete the file)
I had an optional PrintStream param on delete/deleteTree, but removed
it. If the file fails to delete, then you will see all the suppressed
exceptions, but I agree if it fails a number of times and then succeeds
you do not see this.
I'm not sure that it is worth adding PrintStream ( and this is why I
removed it ) since the external interference occurs infrequently and
does not appear to last long. I just wanted to keep this as simply as
possible, but I could be convinced to reintroduce it.
Also, just curious what is the value in throwing InterruptedException
out of the delete() method?
It seems onerous for calling code to have to catch it.
Right handling this is a pain. Since we may now be possibly sleeping
during a delete I wanted jtreg to be able to interrupt the test and have
the test take correct action, rather than just swallowing it. It is
really annoying to see hung tests in logs that do not respond to jtregs
attempts to stop them.
I've also received another comment offline about the method names. They
should be more descriptive, and highlight the difference between these
methods and regular delete. So maybe move to public deleteWithRetry?
-Chris.
Michael
On 07/11/13 10:05, Chris Hegarty wrote:
Virus checkers and, on more modern Windows OSes, Windows Experience
Service, and other external processes, have been causing trouble when
it comes to tests deleting files.
On a number of occasions in the past retry logic has been added to
tests that need to delete files. Also, the jtreg harness has similar
logic when cleaning up temporary files.
This has reared its head again with:
8027902: TEST_BUG: java/net/URLClassLoader/closetest/CloseTest.java
and java/net/URLClassLoader/closetest/GetResourceAsStream.java failed
due to dir operation failed.
8022213: Intermittent test failures in java/net/URLClassLoader
I'd like to add file utility functions to the common jdk/testlibrary,
starting with a "more reliable" delete. I've made minimal changes to
the URLClassloader tests to use this ( more could be done, but this is
just a start ).
http://cr.openjdk.java.net/~chegar/fileUtils/webrev/
The important part here for review is the "API" and impl in FileUtils.
Thanks,
-Chris.
