On Sunday, October 27, 2013 1:42:48 PM UTC-7, Forrest L Norvell wrote: > > Personally, I'm excited about this low-level hook because it should make >> it possible to implement automatic long-stack traces without hacks (though >> this is probably something you would want to have only in debug mode due to >> the performance implications). It might even make it possible to avoid >> littering the code with "if (err) return cb(err)" (or d.intercept) at ever >> layer of asynchrony -- that would be quite nice. > > > You should take a look at https://github.com/joyent/node/pull/6011, which > is the API to which Isaac is alluding. It's ready to be landed on node > master pending review, and has the error-handling hooks you describe (in > fact, in #6011, domains have been reimplemented in terms of the > asyncListener API). I've been working with this API for a month or two now > (I maintain the polyfill that brings its functionality back into 0.10 and > 0.8: https://github.com/othiym23/async-listener), and while I think it > offers a lot of improvements in terms of capturing information about > errors, it's not a full replacement for traditional Node error-handling. In > particular, you still need something like domains to keep the > error-handling happening as close to the scope of where the errors are > signaled as possible. >
Thanks Forrest. Guess I should jump in on this being my PR and all (though huge props to the New Relic team helping me test/debug the sucker). So, here's and example script I threw together (completely unoptimized) using the new AsyncListener API to create long stack traces: https://gist.github.com/trevnorris/7209654 As far as performance, I dunno what people are expecting. I ran the script in benchmark/http_simple.js and ran wrk directly against it. Here are the results of a couple different runs: wrk -c 32 -t 4 -d 10 'http://127.0.0.1:8000/bytes/1024' Normal: 15,000 req/sec @ 47MB Long Stack: 6500 req/sec @ 55MB wrk -c 32 -t 4 -d 10 'http://127.0.0.1:8000/bytes/1024/4' Normal: 800 req/sec @ 25MB Long Stack: 775 req/sec @ 55MB As far as what you can get from it, there's no other library that can give you as in depth information as you can get from the AsyncListener API. It runs for _every_ asynchronous event, including the internal ones you're not alerted about. You're also given access to the request context so it can be inspected at error time. The request context meaning the object that wraps the C++ request in process. So technically a native module could be written to inspect all the classes in the call stack as well. Let's definitively clarify something. Domains were mostly layered onto existing code. AsyncListeners are fundamental to how Node operates. It was the only way to include the feature w/o introducing performance impact when not in use (unlike domains). There is nothing asynchronous in core that doesn't use the AsyncWrap class, thus giving you an easy hook into all asynchronous events. So, honestly, i'm interested to see how the community can push the limits of this new feature. -- -- 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.
