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

one server is always leaked #3447

Closed
cjihrig opened this issue Feb 28, 2017 · 5 comments
Closed

one server is always leaked #3447

cjihrig opened this issue Feb 28, 2017 · 5 comments
Assignees
Labels
Milestone

Comments

@cjihrig
Copy link
Contributor

@cjihrig cjihrig commented Feb 28, 2017

Are you sure this is an issue with hapi or are you just looking for some help?

This is an issue with hapi. You may or may not care to fix it.

What are you trying to achieve or the steps to reproduce?

Create one or more Server objects.

What was the result you received?

This function captures various things, including the server object. The memory associated with the last call can never be released because this.cache is on the prototype.

What did you expect?

I don't expect much out of life.

Context

  • node version: 7.3.0
  • hapi version: master
  • os: macOS
  • any other relevant information:

If you care to fix this, it should be as simple as moving cache to the instance instead of the prototype. I can give it a shot and send a PR if you want. If it's not that important or by design, just close the issue.

@AdriVanHoudt
Copy link
Contributor

@AdriVanHoudt AdriVanHoudt commented Mar 1, 2017

This is a nice and sad report at the same time :O

@hueniverse hueniverse self-assigned this May 29, 2017
@hueniverse hueniverse added the bug label May 29, 2017
@hueniverse hueniverse added this to the 16.1.2 milestone May 29, 2017
@cjihrig
Copy link
Contributor Author

@cjihrig cjihrig commented May 29, 2017

I don't think dc52c13 fixes the leak. internals is around for the entire execution of the application, so it holds the reference like the prototype was previously.

hueniverse added a commit that referenced this issue May 29, 2017
@hueniverse
Copy link
Contributor

@hueniverse hueniverse commented May 29, 2017

@cjihrig what about this?

@cjihrig
Copy link
Contributor Author

@cjihrig cjihrig commented May 29, 2017

I tested by running a few of the tests in test/server.js, adding an after() hook at the end of the tests, and taking a heap snapshot. The snapshot for the latest commit has lower memory consumption and no instances of module.exports.internals.Server 👍

@hueniverse
Copy link
Contributor

@hueniverse hueniverse commented May 29, 2017

Thanks.

@lock lock bot locked as resolved and limited conversation to collaborators Jan 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants