-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New NEXRAD related failure #42
Comments
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? |
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: netcdf-java/cdm/src/main/java/ucar/nc2/iosp/nexrad2/Level2VolumeScan.java Lines 789 to 795 in b935573
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 ( } 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 |
I dont understand then why it wouldnt fail every time? |
I think it's because the lock is only obtained when decompressing, otherwise |
Ok, I have it in the debugger and I agree with your analysis. I think we could just ditch the finally block all together. |
New failure in
ucar.nc2.iosp.nexrad2.TestNexrad2.testRead
on Jenkins (possibly related to #37).Does not consistently bomb out on a particular file or after processing particular number of files.
The text was updated successfully, but these errors were encountered: