Question about how CF handles stability. I don't recall ever seeing CF "crash" per se, like - the whole server/service just stop and need a manual restart. On the other hand, I've worked some with Node.js and have seen the Node process occasionally die, and from what I understand (I've never personally shipped any Node code to a production environment), people use tools like

pm2

to Node restart processes if they die. Does CF just have a great big try/catch around the server itself that I've just never breached, or does it internally use something to quickly restart the process if it dies? Or is Node just shaky as all get-out and people are just firedog this is fine we'll just use

pm2

and it's "good enough" that the stability issues have never been resolved like they have been for CF?

I have not met an app server that i haven't been able to crash....

There are huge architectural differences in the underlying platforms (JVM vs Node.js) that lead to difference approaches to management/recovery. It certainly is possible for the JVM (and therefore CF) to get overloaded to the point that it is unable to serve requests due to a lack of available memory, and an inability to recover memory. That can require a full server restart but if you have a large heap and no runaway processes it's usually pretty rare. The JVM itself can also crash completely -- but that's also fairly rare (and usually indicative of an underlying bug in the JVM itself). The JVM is a pretty heavyweight, multi-threaded system, so restarting it can be a "big deal" so it tries hard to recover problems internally -- for example, a badly-behaved thread can just die and all the memory will be recovered. Node.js is a much lighterweight process and not designed around a multi-threaded paradigm like the JVM (it has some multi-threading but it isn't really core to how you write JS programs). So it's much faster to restart Node.js and that's an easy way to recover from memory and/or out-of-control processes. Erlang/OTP is another platform that takes the "let it crash" approach and relies on supervisor processes to restart things. It's just a different approach to dealing with the real world.

mmm - gotcha. Sounds like the JVM is expected to be insulated from its threads and therefore relatively immune to any of them dying, where some other things (like Node) rely on the user to supply the life support mechanism. Which is totally fine - just different approaches w/ tradeoffs, like everything.

AFC and Lucee will hang based on how you have your JVM and CF Engine configured, but the only time I have seen it crash was over a decade ago, and it was a Microsoft IIS issue, not an AFC issue.

Back in the CF 4.0 days i had a collection of content management systems on an Intranet that I had utilized Verity to do searching. The customer wanted these indexes refreshed quite often, I was very much lets do it without thinking of the consequences and not knowing the right thing to do. I setup a scheduled task on my pc to open a web browser and run the re-index. I had it scheduled to do it early in the morning off hours... I didn't communicate this with anyone, because I never thought the consequences, I just wanted to solve the problem at hand. At the same time the server folks were curious why ColdFusion was crashing every morning when no one should have been using it. It tooks month for them to reach out and I realized that I was causing these nightly crashes in a large way. That to say I have learned that none of us is in a vacuum and to slow down when solving said problems. 🙂 Just a story from my past.

You can definitely burn down a CF server just like how you can ruin an Acura or Lexus engine if you abuse it or set it up wrong. Node is like an Alpha Romeo. Beautiful, elegant and ridiculously performant in a particular way, and also fragile in similar ways. Fix is simple: befriend a mechanic. In this case, rely on fixer processes. But there’s a reason the guy who wrote node moved on and made Deno to “replace” it (that didn’t exactly work out)