Winston 3.0.0 still halts logging in high stress. Makes it unusable for us.
See original GitHub issuePlease tell us about your environment:
- version
winston@3.0.0
node -v
outputs:v8.10.0
- Operating System:
Ubuntu 18.04
- Language:
ES6
This issue has been closed, but running the following code (which I also posted here) still stops Winston logs from working within a second or so:
"use strict";
let winston = require('winston');
const myFormat = winston.format.printf(info => {
return `${info.timestamp} ${info.level}: ${info.message}`;
});
const logger = winston.createLogger({
level: 'info',
format: winston.format.timestamp(),
transports: [
new winston.transports.File({filename: 'logs/combined.log'}),
new winston.transports.Console({format: winston.format.combine(winston.format.timestamp(), myFormat), level: 'debug'})
]
});
while (true) {
let random_string = Math.random().toString(36).substring(7);
logger.info(random_string); // This one stops after a while
console.log(random_string); // while this one continues to function properly
}
Issue Analytics
- State:
- Created 5 years ago
- Reactions:16
- Comments:50 (12 by maintainers)
Top Results From Across the Web
Winston not logging at any log level, what could be wrong?
On the new production server, Winston logs the very first log message per .js file, period. It stops logging after that, and changing...
Read more >Announcing winston@3.0.0! — GoDaddy Engineering Blog
Announcing winston@3.0.0! winston is the most popular logging solution for Node.js. In fact, when measured in public npm downloads winston is so popular ......
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@mempf We had the same problem within our project. We use “bottleneck” to prevent the problem. In our case, we sometimes log a bunch of entries at once and winston hung up in the past. We use bottleneck to “queue” calls of the log function. This fixed our problem. Our LoggerService looks like this (typescript):
I believe I have found a work around and it’s a lot simpler then you might think. It turns out that “readable-stream” automatically "unpipe"s the writable stream on any transport error.
Workaround:
Here is the test now correctly passing