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

SSR: store processed documents on the Link instance to avoid memory leak #209

Merged
merged 1 commit into from Mar 5, 2020

Conversation

valerybugakov
Copy link
Contributor

@valerybugakov valerybugakov commented May 11, 2019

Prevents memory leak when apollo-link-rest is used on the server caused by storing processed documents in the module closure.

@codecov-io
Copy link

codecov-io commented May 11, 2019

Codecov Report

Merging #209 into master will decrease coverage by 0.03%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #209      +/-   ##
==========================================
- Coverage   92.71%   92.68%   -0.04%     
==========================================
  Files           3        2       -1     
  Lines         412      410       -2     
  Branches      121      121              
==========================================
- Hits          382      380       -2     
  Misses         28       28              
  Partials        2        2
Impacted Files Coverage Δ
src/restLink.ts 92.64% <100%> (+0.16%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 62ca581...62bc8e0. Read the comment docs.

@fbartho
Copy link
Collaborator

fbartho commented May 11, 2019

Should this be instead cached on the query instead of on the link? I wasn’t aware of this cache, I’m not exactly certain I understand what’s being cached and the risk.

@valerybugakov
Copy link
Contributor Author

@fbartho it might be cached on the query too, what's the difference? I didn't want to change the logic, just wanted to fix the leak.

On the server, we recreate restLink for every request along with apollo-client etc. to avoid redundant caching between request which results in memory leaks.

const removed = new Map();

This cache cannot be cleared via recreating restLink because the module closure preserves it. That's why it grows with every query without any limits till server collapses with not enough memory error.

Let me know if it makes sense.

@valerybugakov
Copy link
Contributor Author

Also, I checked the code in apollo-link-state, it seems that they removed cache completely. If we want to mimic this behavior (as noted here) that would solve SSR issue too.

@valerybugakov
Copy link
Contributor Author

@fbartho any thoughts on this one?

@fbartho fbartho added this to the 0.8.0 milestone Jul 16, 2019
@fbartho
Copy link
Collaborator

fbartho commented Jul 16, 2019

@valerybugakov I tagged this with a release milestone, to make it clear I hope to release a fix soon (I was on vacation when you submitted this).

Question for you: Would you mind researching why they removed their cache? My preference is to trust their performance analyses.

If they had a reason, then we can copy their code again here. Removing the cache would be simpler to maintain!

@fbartho
Copy link
Collaborator

fbartho commented Nov 5, 2019

@valerybugakov -- I'm working on a new release here, did you see my question re: "Why did they remove their cache?"

@valerybugakov
Copy link
Contributor Author

valerybugakov commented Nov 6, 2019

Hey @fbartho, I didn't have time to do this research

Copy link
Collaborator

@fbartho fbartho left a comment

Choose a reason for hiding this comment

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

I'm going the get this out in a beta release today!

@fbartho fbartho merged commit 273601a into apollographql:master Mar 5, 2020
@fbartho
Copy link
Collaborator

fbartho commented Mar 5, 2020

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants