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

[Stuart Marks]

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
>