On Thu, Aug 22, 2013 at 9:37 PM, ming <[email protected]> wrote: > Thank you for your input, Forrest. > > > You're never ending / destroying / disposing any of the responses, > > so they're just piling up inside the callback closures. > > In foo1, there is a "return" statement immediately after the asynchronous > setTimeout(foo1,0); > so i would assume the responses are marked as GC-able after the return from > the callback closure. > > Just because you've exited the function doesn't mean that the underlying Agent or Socket objects can be garbage collected. They will need to be closed and destroyed, but it takes some time for that to happen, and if you're creating new requests as fast as the event loop will allow, you will exhaust the heap or run out of available sockets long before most of those requests will have been destroyed, especially if you're not doing anything with the response's body (which is a stream -- so if the response body is long enough to be more than a single read chunk, this could well be the source of your problem).
> Therefore, i think the real culprit here is that setTimeout(foo1,0) never > lets go of the next tick so GC never gets a chance to kick off. Is that so? > > In general, it's not possible to block garbage collection in V8 from JavaScript code. Eventually the runtime will force a full mark and sweep operation, even if it pauses execution of a tight loop. You can see this for yourself by running node with '--trace-gc' enabled. Here's a little gist I threw together based on your sample: https://gist.github.com/othiym23/6315838 When I run the client with 'node --trace-gc badulator.js' (using Node 0.10.17), not only does the GC work just fine, but the client never crashes. The only significant change I made from your example was disabling the global HTTP agent for HTTP requests so that it wouldn't do 5 requests and just hang. setTimeout will never cause the kind of resource starvation you're talking about, because it will always defer execution of its callback until a subsequent turn of the event loop, which gives Node a chance to handle I/O, run any functions queued with process.nextTick, and deal with any other things coming out of the libuv side of Node. In this particular example, even running process.nextTick won't even cause starvation, although it will eventually crash, probably due to my OS X laptop running out of available ephemeral sockets on the server side. What else is going on with your client and the HTTP server you're talking to? Forrest -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
