RFR: 8022213 Intermittent test failures in java/net/URLClassLoader (Add jdk/testlibrary/FileUtils.java)

[Michael McMahon]

On 07/11/13 11:34, Chris Hegarty wrote:
> 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.
>

Personally, I would have thought System.err would be okay, but maybe 
there are tests that need to run
without this kind of noise. I agree adding a PrintStream arg is not 
worth doing.

>> 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 wasn't suggesting to swallow the exception - rather to wrap it in an 
unchecked exception. The issue
is really only whether callers need to distinguish this situation from 
the various other errors and environmental
problems  that will all probably cause a test to be interrupted/stopped.

Michael

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