-
Notifications
You must be signed in to change notification settings - Fork 7.3k
Error: EMFILE, open - createReadStream crashes after many files have been opened - no cleanup is happening #6041
Comments
Can you post your question to the mailing list? The issue tracker is for when you have discovered flat out bugs in node.js core but that's still to be determined here. If you are confident there is a bug in node.js somewhere, then please reduce your test case and make sure it only uses core modules (and mention what versions of node.js you have tested it with.) As a general word of advice, don't use fs.*Sync() methods in your HTTP handler. |
As i'm pretty sure there is bug, will reduce the code to core modules like you suggest, |
should i open a new issue? this happens after running 3-4 ab tests: one of the strange things is that when i close a browser window which plays the end / close events are emitted only when the stream reaches its end... I think this might explain some of the leaking of the EMFILE handlers or something
|
You're creating the file stream with |
I've put the attribute autoClose:false on purpose :) |
please note, that I'm closing manually:
|
I actually did not observe any stability improvement via autClose:true / false, But, what i find peculiar... is that no request emits close / end It only emits the close/end event when the stream reaches its end |
Ok, i've run many tests, again. eventually i get to: :error on readstream:Error: EMFILE, open. Seems to happen every time a specific file is requested more then 1000 times. As much as i would like to use nodejs, i guess for this project we'll focus |
I don't mind looking into this but let me repeat:
|
will try to reproduce on other distros... prepare an ab test with a filename to serve, you don't have to wait for all the video to stream, Ctrl-c
|
I've also managed to reproduce it in Ubuntu (digital ocean): nodejs version: v0.11.5-pre let me know if i can assist further, and thanks for your attention so far -) |
Thanks, I can confirm the issue with v0.10 and master. Here is the test case stripped to its essentials: var http = require('http');
var fs = require('fs');
var filename = process.argv[0];
var filesize = fs.statSync(filename).size;
http.createServer(function(req, res){
var file = fs.createReadStream(filename);
res.writeHead(200, { 'Content-Length': '' + filesize });
//res.on('close', file.destroy.bind(file));
file.pipe(res);
}).listen(8080); Uncommenting the call to @isaacs The response object emits 'close' and 'unpipe' when the connection is aborted but the fs.ReadStream object doesn't seem to emit (or do!) anything. Reading |
i personally consider this a streams2 regression. also, some streams, like crypto streams, don't have |
+1 |
see also #7065 |
@tjfontaine, some questions:
|
There is a solution,it may be help you. #8232 |
@bnoordhuis @trevnorris ... still an issue? |
Still an issue. I filed it over at io.js because I think it's a moderately serious bug: nodejs/node#1834 |
I'm creating a video server under http,
http:/localhost:8080/media/video/xxxx1.mp4
using a simple createReadStream files are read and served via pipe(res)
all works well at first, but the more files are being served, the more i get network and response timeoue errors until, not even one file is served.
the strange thing is that i get not errors, there is not memory leak, no cpu usage (2%-6%), simply something inside does not read the file and does not send the stream of bytes to the client,
and no timeout expires...
have been using ab apache benchmark and loader.io, same results.
It is as if something is being clogged and does not get released inside the node <-> file system, via createReadStream.
since i serve 1-2 GB files, it is a only logical solution to use createReadStream,
here is all the Code, should work, simply change mediapath to point to your media files.
ps. i use graceful-fs to overcome the known " EMFILE,open " error.
Needless to say, when i close the process and restart, everything starts up fresh...
is there a good way to see and provide logs on what is happening inside?...
The text was updated successfully, but these errors were encountered: