New NEXRAD related failure about netcdf-java HOT 5 CLOSED

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?

from netcdf-java.

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:

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

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 

from netcdf-java.

I dont understand then why it wouldnt fail every time?

from netcdf-java.

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.

from netcdf-java.

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

from netcdf-java.