> Just because you've exited the function doesn't mean that the underlying
Agent or Socket objects can be garbage collected.
Agreed. Yes, that's a more precise description. Thanks.
> especially if you're not doing anytyhing ...
For the "someBadURI" in foo1 in my very first post of this topic, the
server @ someBadURI always returns 500.
> In general, it's not possible to block garbage collection in V8 from
JavaScript code.
Ah, i was not aware of that. Thanks again. Where can i find the pertinent
doc about the above?
> not only does the GC work just fine, but the client never crashes
By the way, i should have mentioned that the version of Node i use is
0.8.22. Not sure if that plays any role in the crash. i know 0.8.22 is
not the latest (and likely the greatest) but that's what i'm stuck with.
Whether/when the resource will be depleted also depends on the macho-ness
of the hardware, :-)
> ... so that it wouldn't do 5 requests and just hang.
As far as i can tell, my program keeps running instead of getting stuck
after 5 requests. i could still see tons of the stdout output (via
util.log)
util.log("!!!!! bad ....");
before the invocation of
setTimeout(foo1,0);
There client is very thin so foo1 is pretty much all there it is. The
server in the tiny self-contained test suite that i have is of little
interest as well: it just returns 500 all the time - a very dumb server.
i don't think my real server is of any importance here since the dumb
server can re-produce the "out-of-memory" error.
However, if you're interested, my real server is a RESTful HTTP server
which is a minimalistic layer over Apache Zookeeper via Apache Curator API:
http://curator.incubator.apache.org/
To be even more specific (which again i don't think is relevant to the
problem experienced): i was doing Apache ZooKeeper service discovery with
more than one ZooKeeper services available. The services may or may not
reside on the same Linux box. If ZooKeeper itself is down, the server
returns 500 (res.statusCode != 200 in foo1) and i will immediately (thus
the 0-wait) ping ZooKeeper server (i now realize that is not a good idea
but am just curious about the root case of the "out-of-memory" error).
Thanks.
On Friday, August 23, 2013 1:44:12 AM UTC-4, Forrest L Norvell wrote:
>
> On Thu, Aug 22, 2013 at 9:37 PM, ming <hseu...@gmail.com <javascript:>>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 nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
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 nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
