You won't get the problem is you use either streamline.js or fibers. A try/catch in your request handler will catch all exceptions that may be thrown by the current request (and only those exceptions). Streamline will also give you a TLS (thread local storage) equivalent: useful if you need to propagate a security/locale context through all your calls.
Bruno On Tuesday, January 14, 2014 9:28:52 PM UTC+1, Gregg Caines wrote: > > Hey all... I'm wondering if anyone can point me to the current > best-practice for isolating requests in a web app. In general I'm trying > to solve the problem of keeping the server running despite bad code in a > particular request. Are domains my only shot? Do they completely solve > it? Does anyone have existing code? > > I'm on a somewhat large team, working on a somewhat large codebase, and > until now I've been just logging restarts and combing logs for these types > of errors, then fixing them (which I'll always do), but I'm starting to > feel a bit silly with PHP having solved this 10 years ago. ;) When a bug > does get through, it would be nice to not lose the whole server and the > possible 10,000+ customer requests attached to it, while I scramble to fix > it. > > Thanks for any ideas or pointers! > > G > -- -- 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.
