You can use this module: https://github.com/CrabDude/trycatch
It won't require any major changes to the app. I think this is exactly what are you looking for.
As for better general solution, I'd second @tj on that, generators are a nice idea. I didn't try koa, but looks promising. Also, this article - http://spion.github.io/posts/why-i-am-switching-to-promises.html - can be useful and almost made me change the way I do that, but not completely. :)
15.01.2014, 09:43, "Gregg Caines" <cai...@gmail.com>:
--Well even though all the responses so far would require some pretty non-standard solutions (and therefore major changes to our current app), I really do appreciate them. We have logging, metrics and alerts on server restarts, so we know about and fix restarts as fast as possible I believe, but losing 10,000+ user requests at once (per server! and we have dozens of servers running!) due to one bad api endpoint is just not worth the risk of running like this anymore. I'm definitely forced to consider the weirder solutions if there isn't a standard one.There have got to be others working on a standard yet somewhat large deployment that have similar concerns though. How is everyone else managing this? (And if your answer is "Be more careful", I'm going to assume you're not in the same situation. Also: we've got a staging environment we test in first and nearly 100% test coverage )G
On Tuesday, January 14, 2014 7:40:51 PM UTC-8, tjholowaychuk wrote:check out Koa http://koajs.com/ you won't get separate stacks like you do with node-fibers but similar otherwise (built with generators)
On Tuesday, 14 January 2014 12:28:52 UTC-8, 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.
--
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.
