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

[Jonathan Gibbons]

OK, I think I see what happened -- I guess you didn't update the webrev 
and just posted the patch.

-- Jon

On 03/17/2013 04:47 PM, Jonathan Gibbons wrote:
> Jim,
>
> You don't appear to have fixed the issue that milliseconds * 1000 
> gives you microseconds, not seconds.  No matter I will fix it.
>
> -- 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
>