>> 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.)
I see a lot of quirky filesystem behavior just using Windows 7, especially compared to Unixish systems … but maybe that's just me and my environment :) > 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. I agree… I also think this is deeper than just the virus scanner, but I've not the expertise to validate that claim. > 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.) For 8004317 (I think you pushed it yesterday)? I'll take a look at it. That was my initial value. I backed it off thinking it was overly aggressive, but if the environment is that hostile perhaps it's not. > 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. Good point! I'll add that. I think I should through RuntimeException in both cases, to be consistent. > 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. I rewrote it to use a for loop instead and it's much cleaner. I'll post a new webrev later today. -DrD-
