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

[Jonathan Gibbons]

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