I want to skip current execution after some blocks of code executed but the server should not stop, It has to be Up and running on the same port using Node js.
I have tried using Process.exit(), Process.kill() and Process.abort() methods as well. It didn't worked as per my expectations. Those are stopping the server.
Related
I am using node with vue.js as front-end and Express as back-end. I am furthermore using nodemon. Everything has been working properly until 1 hour ago. Since then, every time I save my code, express crashes with the following error (4000 being my port used):
Error: listen EADDRINUSE: address already in use :::4000
I am required to kill the process (kill -15 PID) and then re-start the server, which re-crashes again upon saving the code. Please note that I haven't launched any new processes or applications since that time.
Edit: I have also noticed that if I run pgrep node, I obtain a list of a dozen processes. Is this normal?
How could this happen?
I have a question about how server.listen method keep node process running. Is there any setInterval method inside?
I have read answer in post How does `server.listen()` keep the node program running. But still didn't understand it.
Anyone know please explain to me. Thanks.
Node.js internally in libuv has some sort of counter of the number of open resources that are supposed to keep the process running. It's not only timers that count here. Any type of open TCP socket or listening server counts too as would other asynchronous operations such as an in-process file I/O operations. You can see calls in the node.js source to uv_ref() and uv_unref(). That's how code internal to node.js marks resources that should keep the process running or release them when done.
Whenever the event loop is empty meaning there is no pending event to run, node.js checks this counter in libuv and if it's zero, then it exits the process. If it's not zero, then something is still open that is supposed to keep the process running.
So, let's supposed you have an idle server running with a listening server and an empty event loop. The libuv counter will be non-zero so node.js does not exit the process. Now, some client tries to connect to your server. At the lowest level, the TCP interface of the OS notifies some native code in node.js that there's a client that just connected to your server. This native code then packages that up into a node.js event and adds it to the node.js event queue. That causes the libuv to wake up and process that event. It pulls it from the event queue and calls the JS callback associated with that event, cause some JS code in node.js to run. That will end up emitting an event on that server (of the eventEmitter type) which the JS code monitoring that server will receive and then JS code can start processing that incoming request.
So, at the lowest level, there is native code built into the TCP support in node.js that uses the OS-level TCP interface to get told by the OS that an incoming connection to your server has just been received. That gets translated into an event in the node.js event queue which causes the interpreter to run the Javascript callback associated with that event.
When that callback is done, node.js will again check the counter to see if the process should exit. Assuming the server is still running and has not has .unref() called on it which removes it from the counter, then node.js will see that there are still things running and the process should not exit.
It's running through the event loop.
Every time event loop is looking for any pending operation, the server.listen() operation come forward.
Why node.js app created as a web server via http.createServer doesn't exit after end as simple console.log() app?
Is it because there is a forever while true {} cycle somewhere in http module?
Deep in the internals of Node.js there is bookkeeping being done. The number of active event listeners is being counted. Events and event-driven programming model are what make Node.js special. Events are also the life blood that keep a Node.js program alive.
A Node.js program will keep running as long as there are active event listeners present. After the last event listener has finished or otherwise terminated the Node.js program will also terminate.
For more details
GO HERE
This is the core of node, that while waiting for new connections, to not exit. Without using loops
There are many other ways, to keep node running, without forever while. For example:
window.setTimeout(function(){},10000000)
I am using Mocha to unit test some of the Kue (redis) functions of my node server. Of course Mocha starts its own process. This process has its own instance which is, of course, scope protected from the node server I have running on the same physical server (my laptop in this case as I am in dev env).
My question is: how can the mocha server check any variables or events from the main node server? I realize I could get tricky and have node push variables to redis and then poll redis from mocha but that seems arduous.
You can't. Since the mocha is launching in a separate node process, any javascript variables global or local are relatively scoped to that individual node process. You are correct with the redis suggestion to send a message from process to process or literally launch the node server inside your mocha framework.
I have a node application that uses Socket.IO for the messaging.
And I run it using
node --expose_gc /path/to/app.js
Now, when I check on the htop utility, I noticed that instead of 1, I am getting multiple processes of the same command.
Can someone, in noob terms, explain to me why and what is going on here? I'm also worried that it may consume unexpected memory/cpu usage too.
socket.io does not fork or spawn any child processes.
usually sub processes that run node.js are spawned via cluster module but socket.io does no such thing.
it just adds a handler on top of a http server.
socket.io is just a library that hooks into a web server and listens for certain incoming requests (those requests that initiate a webSocket/socket.io connection). Once a socket.io connection is initiated, it just uses normal socket programming to send/receive messages.
It does not start up any additional processes by itself.
Your multiple processes are either because you accidentally started your own app multiple times without shutting it down or there is something else in your app that is starting up multiple processes. socket.io does not do that.