New NEXRAD related failure

[lesserwhirls]

New failure in ucar.nc2.iosp.nexrad2.TestNexrad2.testRead on Jenkins (possibly related to #37).

java.io.IOException: java.nio.channels.ClosedChannelException

	at ucar.nc2.NetcdfFile.open(NetcdfFile.java:500)
	at ucar.nc2.dataset.NetcdfDataset.openOrAcquireFile(NetcdfDataset.java:713)
	at ucar.nc2.dataset.NetcdfDataset.openFile(NetcdfDataset.java:580)
	at ucar.nc2.iosp.nexrad2.TestNexrad2$MyAct.doAct(TestNexrad2.java:56)
	at ucar.unidata.util.test.TestDir.actOnAll(TestDir.java:263)
	at ucar.unidata.util.test.TestDir.actOnAll(TestDir.java:213)
	at ucar.nc2.iosp.nexrad2.TestNexrad2.testRead(TestNexrad2.java:34)

Does not consistently bomb out on a particular file or after processing particular number of files.

[JohnLCaron]

My apologies, I obviously didnt get that refactor right. Its intermittent because it deals with the case of producing an uncompressed file, which it then leaves in place.

The logic is rather fiendish, probably we should roll the PR back until I can fix. Umm, how do you do that?

[lesserwhirls]

No need to apologize! That's why we have tests :-) I can roll back just the nexrad changes, but I think I found the underlying problem. As part of your PR, you moved to using try-with-resource here:

netcdf-java/cdm/src/main/java/ucar/nc2/iosp/nexrad2/Level2VolumeScan.java

Line 683 in b935573

try (RandomAccessFile outputRaf = new RandomAccessFile(ufilename, "rw")) {

Good stuff. Within that try-with-resource block, we acquire a lock. Cool. The whole try-with-resource block concludes with a finally:

netcdf-java/cdm/src/main/java/ucar/nc2/iosp/nexrad2/Level2VolumeScan.java

Lines 789 to 795 in b935573

	} finally {
	if (lock != null) {
	lock.release();
	}
	} // try-with-resource
	}

but by that point, we're out of the try block and the source has been closed, so the channel is closed and sad times ensue. The lock isn't valid anymore (lock.isValid() = false) by the time we do the null check, as it appears to get released when we move out of the try block, so maybe we don't need a finally block anymore? Or maybe add a log message in case we get there and the lock is still valid somehow?

} finally { 
  if (lock != null && lock.isValid()) { 
      log.error("Uncompresed file is closed but the lock is still valid. Why is you the way you is, file lock?");
  } 
} // try-with-resource 

[JohnLCaron]

I dont understand then why it wouldnt fail every time?

[lesserwhirls]

I think it's because the lock is only obtained when decompressing, otherwise lock=null. The test bombs out on the first file it encounters that needs to be decompressed.

[JohnLCaron]

Ok, I have it in the debugger and I agree with your analysis. I think we could just ditch the finally block all together.