http.Agent might hand out a destroyed socket
Closed this issue · 6 comments
It's possible for socket._destroy and the Agent 'free' event callback to run before the socket 'close' event fires. This causes the Agent to give a destroyed socket to the next request if one is pending in the agent.requests list.
Once the request is assigned the destroyed socket nothing happens, i.e. no errors or events. Writing to the request buffers the data and waits for an event that will never fire, causing the request to never complete.
The following gist demonstrates the issue:
We discovered this issue while experimenting with HTTP keep-alive and realized it was a general case. This may not be a practical problem for the default Agent since with it connections are relatively short lived. Even with keep-alive we only observed about 5 instances per process in a 24h period with full production load.
We worked around it with this code: https://github.com/ceejbot/keep-alive-agent/blob/master/index.js
@dannycoates Do you mind if I totally rip off your gist for a test?
Go for it :)
Connect Four!
(sorry, couldn't resist)
On Thu, Feb 14, 2013 at 3:48 PM, Danny Coates notifications@github.comwrote:
Go for it :)
—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4373#issuecomment-13585588.
We're using node 0.8.23 in production and see some connections not cleaning up from the https.globalAgent...
globalAgent:
{ domain: null,
_events: { free: [Function] },
_maxListeners: 10,
options: {},
requests: {},
sockets: { 'xxx.xxxxxx.com:443': [Object] },
maxSockets: 250,
createConnection: [Function: createConnection] },
We proofed these connections are not active in the systems network stack anymore by doing the usually netstatting...
$ netstat -an | grep 443
$
I'm not 100% sure if this is related, but I didn't want to open a new issue if this is the case.
@sreuter v0.8 is in maintenance mode. Can you retest with v0.10?