-
Notifications
You must be signed in to change notification settings - Fork 240
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
[BUG] Excessive memory usage for SPA where unload hooks keep accumulating #2311
Labels
Milestone
Comments
related to microsoft/applicationinsights-react-js#59 |
MSNev
added a commit
to MSNev/ApplicationInsights-JS
that referenced
this issue
Mar 20, 2024
…ting microsoft#2311 - Rework Asynchronous notification handling
MSNev
added a commit
that referenced
this issue
Mar 20, 2024
…ting #2311 - Rework Asynchronous notification handling
As a temporary workaround for this you can "add" a dummy performance manager the same was as VS Code has in their PR above. To avoid the issue, until we can release a fix for this (a PR of which is available) |
MSNev
added
waiting - CDN deployment
released - NPM
and removed
fixed - waiting release
PR Committed and waiting deployment
labels
Mar 21, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
An issue has been identified with the tracking the removal of all events, timers and config tracking functions where an excessive number of
unload
hooks can accumulate in long running applications.The primary identified culprit is that the
getPerfMgr()
function will ALWAYS add a new unload hook whenever no performance manager currently exists (either explicitly or via create perf manager config function) -- which is the default situation, and when called multiple times without any of the configuration they keep accumulating. The object created and stored is not large, so it takes quite a while (or a lot of events) for the problem to become visible.And as part of our performance testing (to track for excessive memory usage), we actually "install" a performance manager -- which doesn't catch this edge case...
The identified
getPerfMgr()
case only exists in v3.x and was introduced as part of the dynamic configuration support as the watcher being accumulated is the configuration watcher to "handle" configuration changes.This Issue affects the following versions
We will be publishing both a 3.0.9 and a 3.1.2 with a fix for this issue.
The text was updated successfully, but these errors were encountered: