I have 2 systems using Nodejs 16.19.0 - one on my local Windows 11 and another in a GKE pod running a Ubuntu 20 container.
In both systems, I open an interactive Nodejs prompt and run the following, pointing to some IP address that I know will NOT reply and cause a timeout on the client side:
$ node # open interactive nodejs prompt and run the following at once:
console.log(new Date());
req=http.request('http://x.x.x.x');
req.on('error', ()=>{}); // just to cleanup the output
req.on('close', () => { console.log('close ' + new Date()); });
I print the start and end dates to see how long it takes the client to close with the timeout.
In my local system, it takes ~20 seconds. In the other system, it takes 130 seconds. I didn't configure anything special in my Node. Why is there a difference?
Also, the consequence of this, is that when I also add a "timeout" handler for, say, 30 seconds, it will NOT fire on Windows and WILL fire in the pod...
Related
I have a process running over a ubuntu server. I only have access on terminal.
I made this script:
index.js
let i = 0;
setInterval( () => {
i++;
console.log(`try ${i}`);
}, 1000);
I run with: node index.js &
Now I open a new terminal and I want to see the result on console.log.
How can I do it?
New edit:
The principal idea is send a console.log in a terminal and, recovery this console.log in another terminal. This is the goal. Recovery the console log in another terminal. How can I do it?
Of top of my head, I'd suggest going for a combination of https://www.npmjs.com/package/commander and some sort of IPC - redis-based,*mq or plain https://www.npmjs.com/package/node-ipc
If you don't have wide variety of commands you'd need to send to that process, you can also get away using signals, for example: SIGUSR1, SIGUSR2.
I'm looking for a way to build a node.js service that runs in the background and polls a Redis Stream (it could be anything really). While i understand how to build a web server in node.js, this "background service that stays alive and polls something (say invokes a REST endpoint or polls a msg queue) every few seconds" is something i have not been able to find. If you can show it in a few lines of code, that'll be awesome
Start an interval that to stuff every x seconds
startInterval() {
const x = 1;
setInterval(() => {
// Do your Stuff every x seconds here
}, 1000 * x)
},
You can achieve this with PM2.
It is an production process manager for deploying and daemonizing Node.js applications.
In combination with #BraveButter answer you should be able to do what you want.
You may be overthinking this, since Node server processes by default stay alive and actively respond to requests as events. This is in contrast to some server runtime architectures (such as PHP) that will by default have a process per request and so start
the script 'from scratch' for every new request.
So, in case you are being confused by PHP or somesuch, where you have to jump through extra hoops to create a persistent process, then bear in mind that you shouldn't have to do that for a simple Node server script. You can just set an interval that will run a function every so often using setInterval
You can use CronJS.
Basic Cron Usage from the doc :
var CronJob = require('cron').CronJob;
new CronJob('* * * * * *', function() {
console.log('You will see this message every second');
}, null, true, 'America/Los_Angeles');
I got forever script for managing node.js site.
Sometimes node.js site hangs and response time go above 30 seconds. And in fact site is down. Then fast cure for it is restarting forever:
$ forever restart 3
where 3 is script number in forever list.
Is it possible to make it automatically? Is there option in forever which make it restart if response time will be more than 2 seconds for example?
Or maybe I got to run external script which will check response time and make descension to restart hanging forever script.
Or maybe I need to write this logic inside my node.js site?
I am assuming you want to restart the server if most of the reply are taking longer than x seconds. There are many tools that helps you to restart your instances based on their health. Monit is one of them. In this guide, monit restart the instance if reply doesn't come back in 10 seconds.
If you want to kill the instance if one request if any of the requests are taking too long, then you note down the time when you take in the request, and note down the time when request leaves. If the time is too long, throw an exception that you know will not get caught and the server would restart by itself. If you use express, then check the code for their logger under development mode, as it tracks the response time.
Aside leorex solution, I have something like this before to send 500 on timed out requests:
var writeHead = res.writeHead;
var timeout = setTimeout(function () {
res.statusCode = 500;
res.end('Response timed out');
// To avoid errors being thrown for writes after this, they should be ignored.
res.writeHead = res.write = res.end = function () {};
}, 40000);
res.writeHead = function () {
// This was called in time.
clearTimeout(timeout);
writeHead.apply(this, arguments);
};
You can use addTimeout module to take away the timeout clearing part.
Once you implemented, you can handle as you like, you can just call process.exit(1); so forever will immediately replaces you.
You can make this smarter. Also in my application, if an uncaught error happens, I signal the supervisor process so that it will spin up another worker process and gracefully go down(close http server and wait for all pending requests to finish). You can do the same in your application, but make sure everything has a timeout callback as a failover/backup plan.
Here is a simple script
var http = require("http");
http.get( WEBSITE, function(res) {
console.log("Does not return");
return;
});
if WEBSITE variable is 'http://google.com' or 'http://facebook.com' script does not return to console.
but if WEBSITE variable is 'http://yahoo.com' or 'http://wikipedia.org' it returns to console. What is the difference?
By "return to console" I'm assuming you mean that node exits and drops you back at a shell prompt.
In fact, node does eventually exit for all of those domains you listed. (You were just impatient.)
What you are seeing is the result of HTTP keep-alives. By default, node keeps the TCP connection open after a HTTP request completes. This makes subsequent requests to the same server faster. As long as a TCP connection is still open, node will not exit.
Eventually, either node or the server will close the idle connection (and thus node will exit). It's likely that Google and Facebook allow idle connections to live for longer amounts of time than Yahoo and Wikipedia.
If you want your script to make a request and exit as soon as it completes, you need to disable HTTP keep-alives. You can do this by disabling Agent support.
http.get({ host:'google.com', port:80, path:'/', agent:false }, function(res) {
...
});
Only disable the Agent if you need this specific functionality. In a normal, long-running app, disabling the Agent can cause many problems.
There are also some other approaches you can take to avoid keep-alives keeping node running.
I'm a web developer who is new to the whole "run your own (v)Server" so it might be a simple server problem I haven't figured out yet
My problem is this: I'm running a simple Node.js (0.6.6) script on my vServer and I'm using "forever" to daemonize the script. The script checks for connecting sockets, increments a variable and sends the number to the user. If the sockets disconnects, the variable is decremented by one.
The script works fine, showing me around 100-200 "active" users but after around 10-50 minutes, the script just stops working. After the script stops, the vServer responds very slowly (at least I imagine that) - is it possible that my vServer is just too weak?
Here is the code:
var io = require('socket.io').listen(8222);
var count = 0
io.sockets.on('connection', function(socket) {
count++;
io.sockets.socket(socket.id).emit('message', {count: count});
socket.on('disconnect', function () {
count--;
});
});
One last thing: I'm using a managed server for my project (from where the socket is opened) and a vServer from a different hoster for the node.js part.
You could try running top in a different window and watch the server load, see if it occurs the same time as when the server stops responding.