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