Review request: 8004042 : Arrrghs.java test failed on windows with access error.

Stuart Marks stuart.marks at oracle.com
Thu Dec 6 05:43:31 UTC 2012



On 12/5/12 2:44 PM, David DeHaven wrote:
>
> A fix for intermittent test failures causing grief on Windows, particularly Windows 7 and 2008 systems:
> http://cr.openjdk.java.net/~ddehaven/8004042/webrev.1/
>
> The underlying cause is as of yet unknown, but I was able to create an environment that caused similar failures by running "watch -n 0.2 cat JTwork/scratch/atest.bat" in another shell then running jtreg. Without the patch it would fail very regularly (especially when isolated and looped 1,000 times), with the patch it always passes.

We had been discussing/speculating that the problem is the virus scanner 
checking the old incarnation of the file at the same time we want to create a 
new one. If so, and if it were to hold the file open with exclusive access, 
that would explain the AccessDeniedException instead of 
FileAlreadyExistsException (in the CREATE_NEW case).

(I still don't have an explanation for why the file deletion doesn't throw an 
exception. That's what seems to cause jtreg some grief in its cleanup phase, 
and for that reason we've added retry logic to jtreg.)

In any case I think backing off and retrying is probably what's getting us the 
benefit, not the adjustment of the file creation flags.

In any case I'd increase the number of retry attempts. The test environment is 
surprisingly hostile. In the RMI tests we try to open an unused network port 
and retry 10 times if that fails, and sometimes that's not enough. (See Jim 
Gish's recent changeset.)

InterruptedException shouldn't be ignored. Jtreg will interrupt the test if it 
times out, so this interruption should be handled gracefully. Perhaps, wrap the 
InterruptedException in an IOException and rethrow it? (Since the caller is 
clearly prepared to handle IOException.) Terminating the loop and returning 
normally doesn't seem right, since the file wasn't created successfully.

This is only style, but perhaps it would be good to get rid of the 'done' 
boolean and replace the 'done = true' statement with a 'return'. This 
simplifies things a bit, I think.

s'marks



More information about the core-libs-dev mailing list