Skip to content
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

Merged
merged 5 commits into from
Sep 13, 2018
Merged

Fixed a resource leak in PackedAtlasSerializer #215

merged 5 commits into from
Sep 13, 2018

Conversation

lucaspcram
Copy link
Contributor

Description:

Previously, the determineAtlasLoadFormat method would cause a resource leak when it failed to get the format correct on the first try. This was because determineAtlasLoadFormat 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 the deserializeSingleField 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 to PackedAtlasSerializerTest. It confirms that the correct number of resource closures occurs.

Test Results:

Unit test now passes.


In doubt: Contributing Guidelines

Copy link
Collaborator

@matthieun matthieun left a 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!

@matthieun matthieun merged commit 97bd3f4 into osmlab:dev Sep 13, 2018
@lucaspcram lucaspcram deleted the packedresourceleak branch September 13, 2018 16:36
Copy link
Contributor

@MikeGost MikeGost left a 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);
Copy link
Contributor

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?

Copy link
Contributor Author

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");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here.

Copy link
Contributor Author

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.

@matthieun matthieun added this to the 5.1.12 milestone Oct 17, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants