Possible memory leak error. (N close listeners added to [Server])

[vanekbr]

Hello there!
I had a problem with my project and I'm not quite sure if it's a bug or if I am doing something wrong. Asking the community for help.

So, basically, my setup is:

• Angular v13 | v14 project (tested on both)
• Node v16.13.2
• http-proxy-middleware v2.0.6

On starting the project via npm run it compiles successfully and deploys locally.
Once I open the webpage with the application the terminal throws the following error:

(node:73643) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 close listeners added to [Server]. Use emitter.setMaxListeners() to increase limit

I was able to track down the problem and here is the case:

• The project configuration in angular.json has the field projects.ui-cli.architect.serve.options.proxyConfig.
• The proxy config has 11 routes set up for proxying.
• In the file node_modules/http-proxy-middleware/dist/http-proxy-middleware.js there are the lines of code that called for every proxy path definition:

// lines 40-46
            if (server && !this.serverOnCloseSubscribed) {
                server.on('close', () => {
                    this.logger.info('[HPM] server close signal received: closing proxy server');
                    this.proxy.close();
                });
                this.serverOnCloseSubscribed = true;
            }

So, as I got it for every definition of a proxy path the close listener on the server was created to close the proxy. But all the proxies subscribed to a single event emitter and this part the node treats as a memory leak.

Can you guys help identify is that the problem with the http-proxy-middleware or if it is my project's setup that causes the error?
Any information will be much appreciated, thanks!

[aviranb]

I suspect it is an issue in http-proxy package
http-party/node-http-proxy#1559 (comment)

[vanekbr]

Neither the project nor the comment is related to the current issue.
The changes which causing the problem are made directly in the current repo and already written in a correct way via server.on('close') listening.

[vanekbr]

Okay, I did some additional research, and here is some detailed info:
So, as mentioned before an angular project has 11 routes set up for proxying via angular.json config.
Then during building process the config being parsed by webpack-dev-server and here is the part of the parser's code:

      (this.options.proxy).forEach((proxyConfigOrCallback) => { // Here is where multiplication starts
        let proxyMiddleware;
        
        proxyMiddleware = (getProxyMiddleware(proxyConfig));
        
        ...
        
        if (typeof bypassUrl === "boolean") {
          ...
        }
        else if (proxyMiddleware) {
            return proxyMiddleware(req, res, next);
        } 
        ...
      }

The getProxyMiddleware method is

const getProxyMiddleware = (proxyConfig) => {
        if (proxyConfig.target) {
          const context = proxyConfig.context || proxyConfig.path;

          return createProxyMiddleware(
            proxyConfig
          );
        }

        if (proxyConfig.router) {
          return createProxyMiddleware(proxyConfig); // This one is actual require("http-proxy-middleware");
        }
      };

In the end, 11 proxies will be created, but all of them will be subscribed to a single server's .on('close' emitter. Which will cause Possible EventEmitter memory leak error.

So, basically, the issue is not directly related to only http-proxy-middleware or webpack-dev-server, but it is the issue of the way the one works with the other. And to resolve it one or both sides should make changes.

@chimurai I guess you are the only one who can help me at that stage of the investigation. Can you tell is it possible to fix the issue only at http-proxy-middleware or if a new issue needs to be opened at the webpack-dev-server?

[chimurai]

Thanks for effort into the investigation.

To get a better picture; Could you share your webpack-dev-server proxy configuration? (you can anonymise the sensitive parts)

Maybe you could configure it differently.

[vanekbr]

Sure, so there is a link to the file in projects.ui-cli.architect.serve.options.proxyConfig in the angular.json and the file itself can be as simple as

const httpOrigin = 'http://127.0.0.1';

const PROXY_CONFIG = {
    '/test1': {
        target: httpOrigin,
    },
    '/test2': {
        target: httpOrigin,
    },
    '/test3': {
        target: httpOrigin,
    },
    '/test4': {
        target: httpOrigin,
    },
    '/test5': {
        target: httpOrigin,
        secure: false,
    },
    '/test6': {
        target: httpOrigin,
    },
    '/test7': {
        target: httpOrigin,
    },
    '/test8': {
        target: httpOrigin,
    },
    '/test9': {
        target: httpOrigin,
    },
    '/test10': {
        target: httpOrigin,
        ws: true,
    },
    '/test11': {
        target: httpOrigin,
    },
};

module.exports = PROXY_CONFIG;

[chimurai]

They way you configured webpack-dev-server will create a proxy instance for every "path" in your PROXY_CONFIG object.

You could configure it differently to reduce proxy instances:

const httpOrigin = 'http://127.0.0.1';

// https://webpack.js.org/configuration/dev-server/#devserverproxy

module.exports = {
  //...
  devServer: {
    proxy: [
      {
        context: ['/test1', '/test2', , '/test3', ...],
        target: httpOrigin,
      },
      {
        context: ['/test10'],
        target: httpOrigin,
        ws: true
      },
    ],
  },
};

[vanekbr]

Thank you, that's a good workaround!
I was able to reduce the number of configs to 6.

But in the end, if there will be 11+ unique setups for proxy contexts it will still throw an error 🤔

I guess we can leave it at this stage for now and hope this discussion will help others with the same problem.

Thanks again, @chimurai, for your time 🙏🏻

[andywilkinshmcts]

I'm also having the same problem following an upgrade to Angular 15/node 18. Unfortunately I have more than 11 unique proxy contexts so I don't think the workaround is going to help. Any other thoughts?