winston: Got MaxListenersExceededWarning while using winston.
I got a warning message while using winston@3.0.0-rc5 after calling the createLogger function multiple times in my test cases.
(node:28754) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 end listeners added. Use emitter.setMaxListeners() to increase limit
at _addListener (events.js:280:19)
at DerivedLogger.addListener (events.js:297:10)
at DerivedLogger.Readable.on (_stream_readable.js:772:35)
at DerivedLogger.once (events.js:341:8)
at DerivedLogger.Readable.pipe (_stream_readable.js:580:9)
at DerivedLogger.add (/Users/NS/yk/node_modules/winston/lib/winston/logger.js:299:8)
at DerivedLogger.<anonymous> (/Users/NS/yk/node_modules/winston/lib/winston/logger.js:82:12)
at Array.forEach (<anonymous>)
at DerivedLogger.Logger.configure (/Users/NS/yk/node_modules/winston/lib/winston/logger.js:81:24)
at DerivedLogger.Logger (/Users/NS/yk/node_modules/winston/lib/winston/logger.js:22:8)
at new DerivedLogger (/Users/NS/yk/node_modules/winston/lib/winston/create-logger.js:24:44)
at Object.module.exports [as createLogger] (/Users/NS/yk/node_modules/winston/lib/winston/create-logger.js:58:10)
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Comments: 23 (12 by maintainers)
Commits related to this issue
- [fix] possible solution to #1334 — committed to winstonjs/winston by ChrisAlderson 6 years ago
- Completed GCP BUild flow. From gcloudBuild.bat to deployment via unit & e2e test. Also some minor isAuthenticated$ changes on login.html. diff --git a/.editorconfig b/.editorconfig index 82f367c..773... — committed to cname87/project-perform by cname87 5 years ago
- Completed GCP BUild flow. From gcloudBuild.bat to deployment via unit & e2e test. Also some minor isAuthenticated$ changes on login.html. diff --git a/.editorconfig b/.editorconfig index 82f367c..773... — committed to cname87/pp-cloudbuild by cname87 5 years ago
- fix: event emitter memory leaks (#298) The application threw warnings of possible memory leaks caused by adding too many listeners to specific events. It turned out to be coming from the Winston pac... — committed to syntest-framework/syntest-framework by dstallenberg a year ago
- Removed warning from too many loggers - Fixed this issue: https://stackoverflow.com/questions/58653678/winston-maxlistenersexceededwarning-possible-eventemitter-memory-leak-detecte - See https://gi... — committed to BawdyInkSlinger/sugarcube-e2e-test by deleted user 6 months ago
Yep. My case: I’m trying to label messages from different modules with winston 3.0, e.g.
[DB] Connected ok,[Main] Server started ok. So what i want to do, is simple call on the top of file, like this:const logger = createNamedLogger('Main');, wherecreateNamedLoggeris my wrapper to create logger with labeled Console and File transports.I tried to find easy way to do such trivial thing, but i did not found it in docs.
Problem still exists for DailyRotateFile. Code above is enough to reproduce issue.
The creation of child loggers can (with current winston version) easily be achieved with … child loggers, e.g. to overwrite the label in child loggers - based on the code from @trykers
Hi.
I was also having problems with my app. I started to get this warnings
Possible EventEmitter memory leak detected. 16 unpipe listeners added. Use emitter.setMaxListeners() to increase limit. After installing this modulemax-listeners-exceeded-warning, I found out it was something wrong withwinston. After searching for the fix, I found this issue and solution from @DABH helped me get rid of the warning.We were using
Consoletransport in such way:After removing
const transports = [new winston.transports.Console()];and putting it directly intotransports, the warnings were gone. Now I do it this way:@DABH, thank you for your example. It pushed me to combine few solutions of my own and yours and to get result i need. Let me show how i did it, i think some of that ideas can be included in winston or winston modules because they are very common for users.
Goals:
All above should work together. Here is my current realization:
There are few things to polish in future (and remove hardcode), of course .
see my updated gist below… https://gist.github.com/radiumrasheed/9dafdadabd1674b8f9ea967acfbd3947
Yeah, the Console transport is less complex and has fewer event emitters/listeners.
A better (more efficient) design for your use case is to use a singleton logger+transport plus a custom formatter, something like
It is slightly awkward to pass arguments to formatters at log-time, but that is one potential solution (note: untested, there may be syntax errors etc.!). But the overall point is that you probably only need one
Logger, and probably only oneTransportper logging destination (file, console, etc.).I found it would happen if using an instance of
transportincreateLoggermore than maybe 10 times, for example:After running the code above, I got this result:
@DABH don’t reuse
transportinstance if you are doing that.But in my project, I don’t think I did anything like this, so I am still trying to find out what makes this issue in my code.