-
Notifications
You must be signed in to change notification settings - Fork 80
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
Fixed a resource leak in PackedAtlasSerializer #215
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lucaspcram This testing makes me jealous! Really nice! Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome fix and test. Two minor, non-impacting, nits.
*/ | ||
private static class TraceableByteArrayResource extends AbstractWritableResource | ||
{ | ||
private static final Logger logger = LoggerFactory.getLogger(ByteArrayResource.class); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be TraceableByteArrayResource.class
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed it should... Correcting it in another PR. We don't want logs being misdirected.
TraceableByteArrayResource() | ||
{ | ||
this.array = new ByteArray(Long.MAX_VALUE); | ||
this.array.setName("ByteArrayResource"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here it technically should but I don't think it matters, since it's just metadata. But your nit above definitely matters. Correcting that now. I'll correct this too because why not.
Description:
Previously, the
determineAtlasLoadFormat
method would cause a resource leak when it failed to get the format correct on the first try. This was becausedetermineAtlasLoadFormat
tried reading the atlas metadata, but then failed fast and did not close the resource it used to read that metadata. This has been remedied by adding a try-with-resources to thedeserializeSingleField
method, which gets called in all cases of metadata deserialization. The resource will now be closed properly even on failures.Potential Impact:
This has no downstream performance or API impacts.
Unit Test Approach:
The test
testResourceClosureOnInvalidLoadFormat
has been added toPackedAtlasSerializerTest
. It confirms that the correct number of resource closures occurs.Test Results:
Unit test now passes.
In doubt: Contributing Guidelines