http.Agent: idle sockets throw unhandled ECONNRESET

[thorn0]

Please see this code: https://gist.github.com/thorn0/0812cdb7eb12b2348337
That's what it outputs for me (Node 4.2.1 and 5.0.0, Windows 7 x64):

1.108s: Complete
121.193s: uncaughtException
Error: read ECONNRESET
    at exports._errnoException (util.js:874:11)
    at TCP.onread (net.js:544:26)

It's reproduced with most servers that run Microsoft IIS.

[bnoordhuis]

Reproducing your code here for the sake of posterity:

var http = require("http");
var domain = require("domain");

function log() {
  var args = [].slice.call(arguments);
  args.unshift(process.uptime()+"s:");
  console.log.apply(console, args);
}

var agent = new http.Agent({
  keepAlive: true,
  keepAliveMsecs: 10000
});

var req = http.request({
  hostname: "www.asp.net",
  port: 80,
  path: "/",
  method: "GET",
  agent: agent
}, function(res) {
  res.on("data", function() {
  });
  res.on("end", function() {
    log("Complete");
  });
});

req.on("socket", function(sock) {
  sock.on("close", function() {
    log("socket closed");
  });
});

req.on("error", function(err) {
  log("an error ocurred", err);
});

process.on('uncaughtException', function(err) {
  log("uncaughtException");
  console.error(err.stack);
  process.exit();
});
req.end();

setTimeout(function() {
  log("done");
}, 300000);

I'm not sure what you think keepAlive and keepAliveMsecs do but they enable TCP (not HTTP) keep-alive on your side. It's completely transparent to the remote end (the IIS server). Most HTTP servers will disconnect after a period of inactivity, hence the ECONNRESET.

I don't see a bug here. I'll close the issue.

[thorn0]

I'm really confused. https://nodejs.org/api/http.html states the opposite:

If you opt into using HTTP KeepAlive, you can create an Agent object with that flag set to true.

[bnoordhuis]

Maybe I should have said: keepAlive in conjunction with keepAliveMsecs. The latter sets the TCP keep-alive interval, the former tells node to reuse the socket when it can. The point is though that regardless of using TCP or HTTP keep-alive on your end, the remote end can still elect to close the connection.

If you think the documentation is unclear, can you file an issue for that and suggest improvements or send a pull request?

[thorn0]

I still can't get it. http.Agent encapsulates all the other parts of the socket pool management logic. Why doesn't it catch this ECONNRESET at that?

[bnoordhuis]

Because ECONNRESET is an exceptional error, it means the remote end forcibly closed the connection. If the agent swallowed the error you couldn't distinguish an empty reply from unclean termination, for example.

[thorn0]

An empty reply to what? The discussed exception happens when the socket is waiting in the pool and isn't used for a request.

[bnoordhuis]

With all due respect, that's not very clear from your original message. I'll reopen the issue, pull requests welcome.

[bnoordhuis]

For whoever is picking this up, it's probably worth mentioning that the naive solution of attaching an error listener in the agent's 'free' event listener introduces a race window in lib/_http_client.js between the removal of the socket's 'error' event listener in responseOnEnd() and returning it to the pool in emitFreeNT().

[livesankp]

Hello,

I am facing the same issue in signalr which uses long polling and my program stops in 2 mins. This was working fine before node.js upgrade from 0.12.6 to 4.1.2