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

[Jonathan Gibbons]

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
>