[latchkey]

In working with my app, I've found that Domains http://nodejs.org/api/domain.html are crucial for wrapping 3rd party async code that can crash on errors.

[aroman]

I've had a similar need in my app, which has been in use since 0.6. I ended up basically abusing child_process.fork() -- every call to a certain rather long-running, possibly exploding async function is made not from the main node.js process, but is actually spawned as a separate process from node. So if it explodes, the core app instance isn't affected. Of course I do some intelligent things such as kill these "worker forks" if they take longer than 30 seconds, and I check for various UNIX signals to watch if they die and react appropriately.

I also tie the worker PID to each user's session, so they can't spawn an infinite number of workers and cause serious strain on the server -- the server just kills the previous worker and spawns a new one if it's asked to run the function again.

I was actually thinking about opensourcing this, but I guess it's pointless now that domains basically do what I hacked together.

[gnw]

Absolutely, although Domains are a new feature in 0.8 and will need some time for maturity.

[latchkey]

When your nodejs instances are crashing several times an hour due to facebook randomly returning html instead of json and the 3rd party library crashing as a result, who has time for maturity? =)

[doomslice]

Wouldn't a simple uncaughtException handler be sufficient to prevent most crashes?

    process.on('uncaughtException', function (err) {
      // log it
    });

[latchkey]

From the documentation:

"Don't use it, use domains instead. If you do use it, restart your application after every unhandled exception!"

http://nodejs.org/api/process.html#process_event_uncaughtexc...