Node.js and JavaScript bring with them great power and performance, but at two costs. One is the relative newness of JavaScript as a general-purpose programming language; the other is the peculiar way error reporting and debugging work in the Node.js stack.
When I took some time to talk with recently anointed project Node.js project lead Timothy J. Fontaine about these issues, he was able to shed light on how Joyent -- and other users of Node.js -- have dealt with them.
"Node.js uses JavaScript and is dynamic," he said, "so when you hit a problem, it's difficult to figure out what's going on. With a traditional app, you get a core file and symbols [when it crashes]. With [the Node.js JavaScript engine] V8, if the process dies, you don't have enough information to figure out where you died, since all the JavaScript information is gone. You're left trying to add more logging or trying to figure out from the existing logs where things went wrong."
One of the more widely publicized deployments of Node.js that experienced problems was Walmart's. There, a memory leak in Node.js turned out to be the culprit, but Fontaine believes such things are the extreme exception. The majority of the time, he claims, the problems lie in the way Node.js and JavaScript are used and how they are unlike the environments developers might already be used to.
"One thing that's difficult about Node.js is that it's inherently asynchronous," Fontaine said, "with many things in flight at the same time. PHP, Python, Ruby, are all debugging only one process or one thread per request. So with JavaScript, even a stack trace may not be enough."
To that end, most of the issues Joyent sees with Node.js deployments in the wild is unexpected encounters with application bugs that might not have been obvious earlier the development cycle.
"A byproduct of Node's design," said Fontaine, "both good and bad, depending on how you're used to developing, is that JavaScript is a dynamic language, so you don't get a static pass from the compiler. A lot of these use cases are just normal application bugs people are hitting. The problem is trying to reconstruct the history of how they got there."
To aid in the debugging process, Joyent use its own SmartOS as a development platform. SmartOS, an offshoot of OpenSolaris, features that platform's DTrace technology (authored by, among others, Joyent CTO Bryan Cantrill). DTrace lets an application's execution be profiled at runtime with little impact on performance, something Fontaine and the others find useful for examining Node.js as it's actually running.
"You can see the JavaScript stack frames as they happen," Fontaine explained. "With other environments, you don't have the ability to introspect at that level. On other platforms, you have to run Node with special flags to get that extra debug information, which incurs a performance hit.
"Part of why Joyent exists the way it does is because we wrote the tools to help ourselves with the same issues. We then turn around and use that to help other people."
SmartOS itself is freely available under the CDDL license, but most people ostensibly want the best possible debugging tools on the platform they already use -- something, presumably, for Joyent to delve into further as Node.js moves toward a proper 1.0 release.
[An earlier version of this article identified Bryan Cantrill as CEO of Joyent. He is CTO, not CEO.]
This story, "How Joyent debugs Node code," was originally published at InfoWorld.com. Get the first word on what the important tech news really means with the InfoWorld Tech Watch blog. For the latest developments in business technology news, follow InfoWorld.com on Twitter.