4 ms·

Can you elaborate on the "major pain in the butt to monitor and keep Node.js running production-like" What sorts of issues did you face? Certainly .NET and Java

Can you elaborate on the "major pain in the butt to monitor and keep Node.js running production-like" What sorts of issues did you face? Certainly .NET and Java have more tooling, but I haven't noticed a difference between keeping a Node process up as opposed to a Python one. Hard to compare to stateless PHP.

stickfigure 10y ago
The default behavior for Node when there is an uncaught error is to crash the process, killing all requests in flight. Even if you go out of your way to stop this default behavior, errors still likely leave the process in an inconsistent state. Node can't just unwind a few stack frames like synchronous platforms. Do you read JSON from ajax post bodies? Do you access fields in that JSON without sanity checking it? Try passing JSON that's missing one of those critical fields (as, say, a griefer might do). What happened to your app?
- m1sta_ 10y ago
  If only node had exception handling and functions!
  - sgift 10y ago
    Node has - for me - the same problem as C#. Unchecked exceptions on every corner. You don't even know what can explode until it explodes. And then takes your Node instance down. But I am one of these weirdos who likes checked exceptions in Java, so maybe this is not a problem for others.
    - mattmanser 10y ago
      The same problem as C#? You're fighting a very old position. Exception handling in C# is amazingly good, you can't run C# production level apps. It suffers none of the problems that are being discussed above. All you're doing is confusing the discussion with a view point I haven't heard in a decade.
- manyxcxi 10y ago
  You nailed it. Three major things I care about for my application: - Logging - Metrics/Instrumentation/Tracing (memory usage, transactional performance monitoring, etc) - Surviving exceptions All of these are either very immature in Node or simply so far behind they may as well not exist. By nature of running in an application server, you do get a lot of benefits right off the bat for all of those, but even if you're running an executable jar instead of deploying to Tomcat stray exceptions will in almost no cases cause your application to simply die for all requests. Also, say what you want about the verbose try/catch Exception model, but at least you can count on it. Am I getting an Error in this callback or is an exception going to get thrown? Oh, they leaked an exception when I was prepared to handle an Error and now my entire server is down. Does your process automatically restart? Not likely unless you spent a lot of time hand crafting your service to be daemonized, which is generally FAR beyond the scope of most developers I've met in any language (which also upsets me).
  - JdeBP 10y ago
    If one is spending any time hand-crafting the program to daemonize itself on a Unix or a Unix-alike, one is doing things wrongly. On those operating systems, since the advent of the System Resource Controller in 1992 the right way to write a program that runs under a service manager is to write a program that runs in the normal way. No "daemonization" needed. * http://jdebp.eu./FGA/unix-daemon-design-mistakes-to-avoid.html http://jdebp.eu./FGA/unix-daemon-design-mistakes-to-avoid.ht... * http://jdebp.eu./FGA/systemd-house-of-horror/ http://jdebp.eu./FGA/systemd-house-of-horror/
  - NoInkling 10y ago
    Promises and now async/await go a long way to remedy the discrepancy between synchronous exceptions and asynchronous errors, by helping ensure that they both end up as promise rejections (as long as promises/async functions are your de facto async abstraction) while also being handleable with try/catch. The Koa framework (and in the future Express I believe) is designed around this concept, so middleware-level promise rejections can be handled in a single place, and by default simply produce an HTTP error response. It is a shame that it's going to take a while for the Node stdlib to catch up, however. Also I thought something like PM2 (https://github.com/Unitech/pm2 https://github.com/Unitech/pm2) or Forever (https://github.com/foreverjs/forever https://github.com/foreverjs/forever) was pretty much standard for production Node apps?
- NoInkling 10y ago
  The default error middleware built into my framework caught it and responded with a 502.
  - stickfigure 10y ago
    ...and almost certainly left a bunch of dangling state in your app that, at best, is a memory leak.
    - Can_Not 10y ago
      ... or almost certainly was correctly dereferenced, logged, and garbage collected.
- gbuk2013 10y ago
  I for one consider that a feature - it is easy enough to write bad code in JS as it is, so anything that encourages defensive coding and solid unit/functional tests is very appropriate for this particular language. A crash certainly draws attention to a problem much better than an error in a log that no one usually looks at. Yes it's a pain, but you deserve it for writing buggy code and then not catching it in testing (that's what I keep saying to myself, anyway). ;)
  - stickfigure 10y ago
    That crash, in your high-concurrency environment, produced "bad gateway" responses or closed connections for your users. I'm pretty sure they don't consider this a feature.
- Can_Not 10y ago
  > The default behavior for Node when there is an uncaught error is to crash the process. What language doesn't do that?
manyxcxi 10y ago
Love it or not, at least Python has uWSGI, which certainly helps keep things running through errors, and gives you more robust logging at a higher level, etc. if you lose your Node process it's just poof with no guarantees you'll get a good trace to pinpoint the fault.
- Can_Not 10y ago
  Huh, that's weird, I've never had a Node process silently die in production without a good trace or robust high level logging. Are you sure you're not just making stuff up?

stickfigure 10y ago

The default behavior for Node when there is an uncaught error is to crash the process, killing all requests in flight. Even if you go out of your way to stop this default behavior, errors still likely leave the process in an inconsistent state. Node can't just unwind a few stack frames like synchronous platforms. Do you read JSON from ajax post bodies? Do you access fields in that JSON without sanity checking it? Try passing JSON that's missing one of those critical fields (as, say, a griefer might do). What happened to your app?

m1sta_ 10y ago
If only node had exception handling and functions!
- sgift 10y ago
  Node has - for me - the same problem as C#. Unchecked exceptions on every corner. You don't even know what can explode until it explodes. And then takes your Node instance down. But I am one of these weirdos who likes checked exceptions in Java, so maybe this is not a problem for others.
  - mattmanser 10y ago
    The same problem as C#? You're fighting a very old position. Exception handling in C# is amazingly good, you can't run C# production level apps. It suffers none of the problems that are being discussed above. All you're doing is confusing the discussion with a view point I haven't heard in a decade.
manyxcxi 10y ago
You nailed it. Three major things I care about for my application: - Logging - Metrics/Instrumentation/Tracing (memory usage, transactional performance monitoring, etc) - Surviving exceptions All of these are either very immature in Node or simply so far behind they may as well not exist. By nature of running in an application server, you do get a lot of benefits right off the bat for all of those, but even if you're running an executable jar instead of deploying to Tomcat stray exceptions will in almost no cases cause your application to simply die for all requests. Also, say what you want about the verbose try/catch Exception model, but at least you can count on it. Am I getting an Error in this callback or is an exception going to get thrown? Oh, they leaked an exception when I was prepared to handle an Error and now my entire server is down. Does your process automatically restart? Not likely unless you spent a lot of time hand crafting your service to be daemonized, which is generally FAR beyond the scope of most developers I've met in any language (which also upsets me).
- JdeBP 10y ago
  If one is spending any time hand-crafting the program to daemonize itself on a Unix or a Unix-alike, one is doing things wrongly. On those operating systems, since the advent of the System Resource Controller in 1992 the right way to write a program that runs under a service manager is to write a program that runs in the normal way. No "daemonization" needed. * http://jdebp.eu./FGA/unix-daemon-design-mistakes-to-avoid.html http://jdebp.eu./FGA/unix-daemon-design-mistakes-to-avoid.ht... * http://jdebp.eu./FGA/systemd-house-of-horror/ http://jdebp.eu./FGA/systemd-house-of-horror/
- NoInkling 10y ago
  Promises and now async/await go a long way to remedy the discrepancy between synchronous exceptions and asynchronous errors, by helping ensure that they both end up as promise rejections (as long as promises/async functions are your de facto async abstraction) while also being handleable with try/catch. The Koa framework (and in the future Express I believe) is designed around this concept, so middleware-level promise rejections can be handled in a single place, and by default simply produce an HTTP error response. It is a shame that it's going to take a while for the Node stdlib to catch up, however. Also I thought something like PM2 (https://github.com/Unitech/pm2 https://github.com/Unitech/pm2) or Forever (https://github.com/foreverjs/forever https://github.com/foreverjs/forever) was pretty much standard for production Node apps?
NoInkling 10y ago
The default error middleware built into my framework caught it and responded with a 502.
- stickfigure 10y ago
  ...and almost certainly left a bunch of dangling state in your app that, at best, is a memory leak.
  - Can_Not 10y ago
    ... or almost certainly was correctly dereferenced, logged, and garbage collected.
gbuk2013 10y ago
I for one consider that a feature - it is easy enough to write bad code in JS as it is, so anything that encourages defensive coding and solid unit/functional tests is very appropriate for this particular language. A crash certainly draws attention to a problem much better than an error in a log that no one usually looks at. Yes it's a pain, but you deserve it for writing buggy code and then not catching it in testing (that's what I keep saying to myself, anyway). ;)
- stickfigure 10y ago
  That crash, in your high-concurrency environment, produced "bad gateway" responses or closed connections for your users. I'm pretty sure they don't consider this a feature.
Can_Not 10y ago
> The default behavior for Node when there is an uncaught error is to crash the process. What language doesn't do that?

manyxcxi 10y ago

Love it or not, at least Python has uWSGI, which certainly helps keep things running through errors, and gives you more robust logging at a higher level, etc. if you lose your Node process it's just poof with no guarantees you'll get a good trace to pinpoint the fault.

Can_Not 10y ago
Huh, that's weird, I've never had a Node process silently die in production without a good trace or robust high level logging. Are you sure you're not just making stuff up?