-
Notifications
You must be signed in to change notification settings - Fork 30.2k
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
CreateReadStream doesn't close the file #1180
Comments
Can you show the relevant code, or at least a minimal, reproducible example? |
There is a known problem when you pipe a stream to a response and the client aborts request. Try this package: https://github.com/jshttp/on-finished |
@mscdex @vkurchatkin the problem still persists, but the simulation is harder. Here is a video: @vkurchatkin I tested this problem more. I destroyed the stream via Thanks! |
please don't ask people to download zip files to test your code. just show us a gistfile. the second example is incorrect. var destroy = require('destroy');
var http = require('http');
var onFinished = require('on-finished');
var fs = require('fs');
http.createServer(function (req, res) {
res.writeHead(200, { 'Content-Type': 'image/jpeg' });
var stream = fs.createReadStream('bg.jpg');
stream.pipe(res);
onFinished(res, function(err) {
res.on('finish', function() {
destroy(stream);
});
});
}).listen(1337, '127.0.0.1');
console.log(process.argv[0] + ': ' + process.pid + '\nhttp://127.0.0.1:1337'); you're basically doing something like: res.on('finish', =>
res.on('finish', =>
destroy(stream)
)
) which isn't going to work because onFinished(res, function () {
destroy(stream)
}) if the above doesn't work, please file an issue with |
see the bottom example: https://github.com/jshttp/on-finished#example |
@jonathanong ohh sorry, my mistake. |
I have tested it and with I think that it's a bug. The test result with
Can you explain to me, why does it behaving like that? |
This has been dormant for a long time. Does anyone know if it is a confirmed bug? If so, any idea if it's been fixed? |
Without further confirmation it's difficult to say. I'd recommend closing and we can reopen later if necessary. |
Going to close given the lack of any further confirmation or discussion. Can reopen if necessary. |
i believe this is the correct issue to post under... i have a read stream piping a binary file to the response object,
on first call it sends the complete file to the client but doesn't close the stream, on the second call it fails but raises the close event. once the close event has been fired, the following call will succeed and the subsequent call will fail in the same way.
in the logs, the only line is "pipe close" from the second call. this only happens if encoding is set to base64, when i transport the file without transformation it works perfectly. |
alright, i've figured out why it was only happening every second call - that's because the client's ajax calls weren't disconnecting properly (jquery). the only thing that still concerns me is that the end and finish events aren't raised, otherwise the close event is being raised just fine. |
You should really use http://npm.im/pump to pipe things, or those situations can happen. |
alright, i used pump, and it's easier to use (thanks!) but i have the same result. the only difference is that i'm able to catch the error properly on the second call (or any other call made using the jquery ajax function):
|
Can you please upload a full example to demonstrate your issue? |
the first call returns the file data, but doesn't close the pipe. the second call fails and produces the following error:
this is due to the jquery ajax call not completing properly, but clearly the stream should be closing regardless? again, no "end" of "finish" events raised. |
You mention an Ajax call, can you upload a full example to demonstrate your problem? |
|
@therightstuff I need something I can run on my laptop to help you. That's what I mean by a "Full" example. |
without sharing proprietary code i would have to write it new, thanks anyway. |
purpose: * ensure that file descriptors are closed, and never leak - if a fd were to leak as the result of the file having been requested by a client and served by httpd, then the underlying file will remain open and cause the OS to prevent the file from being deleted until the process running `serve` terminates potential causes for fd leak: 1) bug in `serve` https://github.com/vercel/serve-handler/blob/6.1.3/src/index.js#L751 summary: - the fd is opened BEFORE checking ETag to conditionally return a 304 Not Modified Response - when this occurs, the fd is never piped to the response, and it is never closed 2) bug in `nodejs` nodejs/node#1180 nodejs/node#1834 summary: - if the client closes the connection before the piped fd stream is fully written to the response, it has been reported that the fd is never closed workaround: https://github.com/jshttp/on-finished#example
I found a big problem in streams. I performed multiple tests on Ubuntu 14.04 LTS and OSX too and I see multiple opened files through
lsof -p PID
. I useautoClose: true
(in default) and I destroy the stream manually with this module https://github.com/stream-utils/destroy.This problem is not recorded for every request, but only if I performed multiple requests at the same time. My website falls down.
How can I prevent this problem? Is there a bug? How to close opened files? Extending
ulimit
is not a solution.Thanks for any advice.
PS: io.js v1.5.1
I reported the same problem on node.js GitHub.
The text was updated successfully, but these errors were encountered: