Could you share how you did that?
I intend to test that kind of thing *before* building a real
application, I am new to node (I came from C++) and it may be an
interesting learning path (even if a bit difficult)
Thanks
Alain
=== Minha MesaXYZ: <http://mesa-reprap.blogspot.com.br/> ===
Em 16-01-2014 06:48, Bruno Jouhier escreveu:
No water-tight technical solution? There are some. Problem is that
people are reluctant to go with them.
For me, the exception handling problem has been solved 3 years ago.
Our server is robust. If someone messes up in some kind of obscure
piece of code that nobody tested, nothing dramatic will happen. The
client of the service will get a 500, the full stacktrace will be
logged (with both long and row stacktraces) and the server will go on
with the other requests.
Bruno
On Thursday, January 16, 2014 7:02:17 AM UTC+1, Tomasz Janczuk wrote:
In general I'm trying to solve the problem of keeping the
server running despite bad code in a particular request
Given that no water-tight technical solution to this problem has
been suggested on this thread, perhaps this entire problem should
be approached from a different angle. Instead of trying to
/prevent /server failures, let's /embrace /the fact the server
will fail, and for a variety of reasons (bad user code, memory
leak in Node or V8, etc). Then design the overall system around
this assumption. Some ideas to that end:
1. Create a cluster of many more child processes than the number
of CPU cores would suggest to reduce the impact of any one of
them failing.
2. Add graceful shutdown logic to reduce the impact of failures
you can actually detect (like a JavaScript level exception),
but do not /prevent/ the server from failing. For example,
within an uncaught exception handler shut down the HTTP server
and only exit the process after requests in flight have
completed. But exit it.
3. Build failure recovery at all levels of the application stack.
For example, retry your ajax requests a number of times.
4. Build planned failures into your code to keep yourself honest
as to the quality of your recovery mechanism. Throw an
unhandled exception within 5-10 minutes of every process start
time, by design.
5. Look at your software process to see if the bugs getting into
the production code could be avoided in the first place.
--
--
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.