-
Notifications
You must be signed in to change notification settings - Fork 852
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 detected on the EventEmitter with http-proxy-middleware.js where server.on('close') listener is added for non websocket usage #909
Comments
got the same issue |
Try to create the proxy once, instead of on every request. Similar issue: #108 (comment) Could you share what server are you using? |
Is anyone working on that? |
We are facing the same issue on a NestJS Application trying to leverage http-proxy-middleware through a Nest Middleware.
Is there a way to create the proxy instance only once but still be able to dynamically set headers for the proxied request? I know of |
Leaving this here for anyone facing the same issue with a NestJS application. The solution was like suggested by @chimurai to only call
|
Checks
http-proxy-middleware
.Describe the bug (be clear and concise)
I had an issue with my project where the memory is steadily increasing. When I turned on the profiling through chrome inspector, I get a warning of this
And when I checked and console.log the req.socket where the code of the library is creating the listener at, on every single request being made which result into invoking createHttpProxyMiddleware, it will always add an event listener to server.onClose, and the object was never cleared by the Garbage Collector.
Please see screenshot below
I've created a runner which triggered 50request at a time, and it created 50 close events without being cleared.
Step-by-step reproduction instructions
1. Turn on node --inspect on your nodejs application 2. Open chrome://inspect and make sure you are on debug mode 3. Fire 50 or more request, you shall see a warning which I've described above.
Expected behavior (be clear and concise)
Since request.connection has been deprected, hence request.socket which used in this line should only applicable for HPM with mode ws: true. For ws: false which is non websocket, should not need this kind of listener.
How is http-proxy-middleware used in your project?
What http-proxy-middleware configuration are you using?
What OS/version and node/version are you seeing the problem?
Additional context (optional)
No response
The text was updated successfully, but these errors were encountered: