RFR: 7900051 - jtreg cleanup intermittentely fails to delete files on Windows

[Eric Wang]

Thanks Stuart, I'm investigating below tests, they failed on windows due 
to RFR 7900051.

http://sqeweb.us.oracle.com/jsn/nightly/reg/test_stabilization/2013_01_07/win_ken/run_156/testoutput/jdk_lang/JTwork/sun/misc/EscapePath.jtr
http://sqeweb.us.oracle.com/jsn/nightly/reg/test_stabilization/2013_01_07/win_sandeep/run_107/testoutput/jdk_jfr/JTwork/closed/com/oracle/jfr/startupargs/OptionsTest/TestDefaultRecordingDisabled.jtr
http://sqeweb.us.oracle.com/jsn/nightly/reg/test_stabilization/2013_01_07/win_ken/run_305/testoutput/jdk_io/JTwork/java/io/File/SetLastModified.jtr
http://sqeweb.us.oracle.com/jsn/nightly/reg/test_stabilization/2013_01_07/win_ken/run_37/testoutput/jdk_jfr/JTwork/closed/com/oracle/jfr/startupargs/OptionsTest/TestGlobalBufferSize.jtr
http://sqeweb.us.oracle.com/jsn/nightly/reg/test_stabilization/2013_01_07/win_ken/run_11/testoutput/jdk_net/JTwork/java/net/URLClassLoader/closetest/GetResourceAsStream.jtr
http://sqeweb.us.oracle.com/jsn/nightly/reg/test_stabilization/2013_01_07/win_ken/run_11/testoutput/jdk_net/JTwork/java/net/URLClassLoader/closetest/CloseTest.jtr

-Eric

On 2013/3/8 7:15, Stuart Marks wrote:
> Hi, did this ever get pushed?
>
> Eric Wang was diagnosing intermittent test failures and he was running 
> into problems where a test would pass but jtreg would fail it 
> after-the-fact when it was unable to clean up the scratch directory. I 
> think those failures might be helped by Jim's cleanup change.
>
> s'marks
>
> On 2/7/13 3:31 PM, Jonathan Gibbons wrote:
>> I've not looked at this round of changes, but I will, and will push 
>> them if
>> they're OK.
>>
>> -- Jon
>>
>> On 02/07/2013 03:16 PM, Jim Gish wrote:
>>> All I had to do was look at the subject of my own message, didn't 
>>> I?  It's
>>> been one of those crazy days:-(  Thanks.
>>>
>>> Do the changes look ok?  If so, could you push them, please? (I 
>>> updated the
>>> commit message and attached a proper patch).
>>>
>>> Jim
>>>
>>> On 02/07/2013 04:52 PM, Jonathan Gibbons wrote:
>>>> 7900051 is a CODETOOLS bug, isn't it?
>>>>
>>>> -- Jon
>>>>
>>>>
>>>> On 02/07/2013 01:33 PM, Jim Gish wrote:
>>>>> Thanks, Jonathan -- I made your suggested changes.  Please 
>>>>> re-review.  I
>>>>> suppose we need a code-tools bug for this don't we?
>>>>>
>>>>> Thanks,
>>>>>     Jim
>>>>>
>>>>> http://cr.openjdk.java.net/~jgish/Bug7900051-DeleteRetry/
>>>>> <http://cr.openjdk.java.net/%7Ejgish/Bug7900051-DeleteRetry/>
>>>>>
>>>>> On 02/06/2013 09:25 PM, Jonathan Gibbons wrote:
>>>>>> Also, notice the inconsistent order of words in
>>>>>>
>>>>>>   111         RETRY_DELETE_DELAY_MSEC = isWindows ? 500 : 0;
>>>>>>   112         MAX_DELETE_RETRY_SECONDS = isWindows ? 30 : 0;
>>>>>> I guess I would expect to see MAX_ be a prefix to what it is a 
>>>>>> max of, such as
>>>>>>     MAX_RETRY_DELETE_SECONDS
>>>>>>
>>>>>> Also, it's not clear to me that it helps to change units, 
>>>>>> especially given
>>>>>> the silly slip you had in the code that I mentioned earlier.   
>>>>>> Why not
>>>>>> keep all times consistently in the same units, presumably MSEC?
>>>>>>
>>>>>> -- Jon
>>>>>>
>>>>>>
>>>>>> On 02/06/2013 06:20 PM, Jonathan Gibbons wrote:
>>>>>>> Jim,
>>>>>>>
>>>>>>> Sorry for the delay; thanks for the reminder.
>>>>>>>
>>>>>>> To get from milliseconds to seconds, you divide by 1000, not 
>>>>>>> multiply by
>>>>>>> it ;-)  In two places.
>>>>>>>
>>>>>>> I don't think you should log messages about deleting files. Some 
>>>>>>> tests
>>>>>>> generate *lots* of files, and it would be unacceptable to report 
>>>>>>> them
>>>>>>> being deleted, one by one.   I can see that occasionally you 
>>>>>>> might want
>>>>>>> to see this level of details, but it should be enabled by setting a
>>>>>>> system property such as javatest.regtest.showDeleteFiles and 
>>>>>>> should be
>>>>>>> off by default.   Reporting issues when files cannot be deleted, 
>>>>>>> such as
>>>>>>> ScratchDirectory.java:191(new) is acceptable.
>>>>>>>
>>>>>>> -- Jon
>>>>>>>
>>>>>>>
>>>>>>> On 02/06/2013 09:22 AM, Jim Gish wrote:
>>>>>>>> I haven't heard back on this one yet.  Any comments?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>     Jim
>>>>>>>>
>>>>>>>> On 01/23/2013 04:24 PM, Jim Gish wrote:
>>>>>>>>> Please review:
>>>>>>>>> http://cr.openjdk.java.net/~jgish/Bug7900051-DeleteRetry/
>>>>>>>>> <http://cr.openjdk.java.net/%7Ejgish/Bug7900051-DeleteRetry/>
>>>>>>>>>
>>>>>>>>> Summary: this change adds delete retry logic on Windows 
>>>>>>>>> similar to that
>>>>>>>>> that is already there on init.  It also consolidates the delete
>>>>>>>>> methods. Instead of trying some N times with Delta msec. delay in
>>>>>>>>> between, it now tries for up to 30 seconds with Delta (500 
>>>>>>>>> msec) delay
>>>>>>>>> in between.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>    Jim
>>>>>>>>> -- 
>>>>>>>>> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
>>>>>>>>> Oracle Java Platform Group | Core Libraries Team
>>>>>>>>> 35 Network Drive
>>>>>>>>> Burlington, MA 01803
>>>>>>>>> jim.gish at oracle.com
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
>>>>>>>> Oracle Java Platform Group | Core Libraries Team
>>>>>>>> 35 Network Drive
>>>>>>>> Burlington, MA 01803
>>>>>>>> jim.gish at oracle.com
>>>>>>>
>>>>>>
>>>>>
>>>>> -- 
>>>>> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
>>>>> Oracle Java Platform Group | Core Libraries Team
>>>>> 35 Network Drive
>>>>> Burlington, MA 01803
>>>>> jim.gish at oracle.com
>>>>
>>>
>>> -- 
>>> Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
>>> Oracle Java Platform Group | Core Libraries Team
>>> 35 Network Drive
>>> Burlington, MA 01803
>>> jim.gish at oracle.com
>>