-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Memory leak when using Reactive variables in SSR setup on the server #7274
Comments
@manojVivek Thanks for opening this issue! I can see what the problem is, and how to fix it, though I suspect any possible solution to this problem will depend on you explicitly calling |
Each reactive variable must remember any caches previously involved in reading its value, so those caches can be notified if/when the variable value is next modified. To prevent reactive variables from retaining references to caches that no longer need to be notified, we preemptively remove the cache from the memory of all of its associated reactive variables whenever all of its watches are cancelled, since not having any active cache.watches means cache.broadcastWatches has nothing to do. Should prevent memory leaks when many caches are created and discarded by the same process, as in the SSR use case described in #7274.
Each reactive variable must remember any caches previously involved in reading its value, so those caches can be notified if/when the variable value is next modified. To prevent reactive variables from retaining references to caches that no longer need to be notified, we preemptively remove the cache from the memory of all of its associated reactive variables whenever all of its watches are cancelled, since not having any active cache.watches means cache.broadcastWatches has nothing to do. This change should prevent memory leaks when lots of caches are created and discarded by the same process, as in the server-side rendering use case described by @manojVivek in #7274.
Addressed by #7279 - thanks! |
Intended outcome:
Usage of reactive vars on the server-rendering shouldn't create a memory leak.
Actual outcome:
When an app, that uses reactive vars, is rendered on the server, it holds the query results in memory forever. Even though a new client, cache, and reactiveVar instances are created freshly for every request.
Probably because the references to reactive vars are held in a global context?
How to reproduce the issue:
We make use of the following function to create a new apollo client on every request to the serve:
And we observed from heap-dumps that the cache data is held in the memory when we use the reactive-vars even after a GC.
And if we remove the usage of reactive vars, the memory recovers back to normal after the GC.
Screenshot of a sample object(one of tons of similar ones) that were in memory:
![Screenshot 2020-11-02 at 1 35 53 PM](https://user-images.githubusercontent.com/1283424/97844167-88fe9500-1d10-11eb-94b5-20c5d8b90699.png)
Versions
The text was updated successfully, but these errors were encountered: