RFR: 8022213 Intermittent test failures in java/net/URLClassLoader (Add jdk/testlibrary/FileUtils.java)
chris.hegarty at oracle.com
Thu Nov 7 11:34:06 UTC 2013
On 11/07/2013 11:19 AM, Michael McMahon wrote:
> 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?
> 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 ).
>> The important part here for review is the "API" and impl in FileUtils.
More information about the core-libs-dev