I just have to wonder - after listing all those projects which already do this job and do it well... Why create / use `forever` which didn't get the same exposure to the production environments yet?
Keeping node.js servers up forever
11–20 of 41 posts
Re: Keeping node.js servers up forever
#12By using the 'http' module we can run a stand-alone web server in node.js without the need for a separate server like Apache or nginx. Last I checked Ryan was saying this was a very bad idea. Has that changed? It's certainly enticing.
When did you last check with him? I've been running w/o a separate server (effectively) for ~3 months.
Oh, I just meant last I checked on blogs and such (not with him personally). IIRC, his main reason for advising against it was that there were too many security holes. This was in a video talk from several months ago if not longer. I'm curious to know if conditions have changed.
Re: Keeping node.js servers up forever
#13This reminds me of the bad old days of Rails, when every man and his dog had some random hacky and myopic solution to keep Rails and Mongrel running. Just say no to Node/Rails/whatever specific-stuff, kids--use system level tools for running processes. Edit: removed references to "proprietary", as indexzero is correct about meaning of that.
That's a strange usage for "proprietary" since it's all free and open source (MIT). Either way, the nodejs child_process module is really just a light weight wrapper to execvp():
http://linux.die.net/man/3/execvp
I haven't dug through the source for tools like monit, daemontools, but I'm sure near the metal they're using POSIX or similar system APIs.
EDIT: There's really no reason Forever has to be node specific, I actually say that in the article:
"Honestly, it's a one line fix here (https://github.com/indexzero/forever/blob/master/lib/forever...), but I'm not sure if users want to put 'node' in-front of every command."
I'll file your comment as a +1 for that feature ;)
Re: Keeping node.js servers up forever
#14I just have to wonder - after listing all those projects which already do this job and do it well... Why create / use `forever` which didn't get the same exposure to the production environments yet?
Well, we can call native node.js code from our process monitor now.
We can extend our process monitor with functionality that would be difficult to implement in those other tools.
Re: Keeping node.js servers up forever
#15I just have to wonder - after listing all those projects which already do this job and do it well... Why create / use `forever` which didn't get the same exposure to the production environments yet?
Well, we can call native node.js code from our process monitor now. We can extend our process monitor with functionality that would be difficult to implement in those other tools.
Any examples of when this would be desirable? Seems to me that monitoring and running tools should just, you know, monitor and run things. Separation of concerns.
Re: Keeping node.js servers up forever
#16I just have to wonder - after listing all those projects which already do this job and do it well... Why create / use `forever` which didn't get the same exposure to the production environments yet?
Well, we can call native node.js code from our process monitor now. We can extend our process monitor with functionality that would be difficult to implement in those other tools.
@intranation Just to toss out a scenario: Lets say under high traffic your application hits an edge case and starts to crash very frequently. Suppose you want to receive an email, SMS, or IM when something like this happens as a devops person.
Would you consider that a valid concern of process monitoring?
Planned features to Forever include this from the command line, but if you use it from node directly one could implement that feature now:
Re: Keeping node.js servers up forever
#17bookmarked. thank you.
Re: Keeping node.js servers up forever
#18Earlier quoted context omitted.
Well, we can call native node.js code from our process monitor now. We can extend our process monitor with functionality that would be difficult to implement in those other tools.
Any examples of when this would be desirable? Seems to me that monitoring and running tools should just, you know, monitor and run things. Separation of concerns.
How would you setup alerts for your monitoring?
I'd much rather have access to a well structured library (node.js) where sockets and http are first class citizens, opposed to being forced into a solution or having to write C or bash.
Re: Keeping node.js servers up forever
#19Earlier quoted context omitted.
Well, we can call native node.js code from our process monitor now. We can extend our process monitor with functionality that would be difficult to implement in those other tools.
@intranation Just to toss out a scenario: Lets say under high traffic your application hits an edge case and starts to crash very frequently. Suppose you want to receive an email, SMS, or IM when something like this happens as a devops person. Would you consider that a valid concern of process monitoring? Planned features to Forever include this from the command line, but if you use it from node directly one could im…
I want my monitoring process to be rock solid. Extensions such as notifications should be done in another process, otherwise you're at the mercy of whatever email/SMS/IM library you include to do the notification.
Re: Keeping node.js servers up forever
#20This leads to a very bad practice though, which is to cause bugs to be left laying around in production systems. You should really form the habit of analyzing such crashes, getting to the root cause of the problem and making sure that it never ever happens again.
It's good to have a system like this in place, but it should be used as an insurance policy against unknown bugs, not as a way to work around known and reproducible ones.