Node.js httpserver.listen method ambiguity

Question

I have been working in Node.js and I am wondering what exactly does listen method do, in terms of eventloop. If I had a long running request, does it mean that server will never listen since it can only do one work at a time.

var http = require('http');
function handleRequest(request, response) {
    response.end('Some Response at ' + request.url);
}
var server = http.createServer(handleRequest);
server.listen(8083, function() {
    console.log('Listening...')
})

Is server.listen listening to some event?

Node.js is single threaded, and uses intensively asynchronous activities to ensure nothing blocks the thread. See [How the single threaded non blocking IO model works in Node.js](http://stackoverflow.com/questions/14795145/how-the-single-threaded-non-blocking-io-model-works-in-node-js). — mins, May 27 '15 at 18:08

jfriend00 · Accepted Answer · 2015-05-27T18:14:30.020

You can think of server.listen() as starting your web server so that it is actually listening for incoming requests at the TCP level. From the node.js http documentation for .listen():

Begin accepting connections on the specified port and hostname.

The callback passed to server.listen() is optional. It is only called once to indicate that the server has been successfully started and is now listening for incoming requests. It is not what is called on every new incoming request. The callback passed to .createServer() is what is called for every new incoming request.

Multiple incoming requests can be in process at the same time though due to the single-threaded nature of node.js only one request is actually executing JS code at once.

But, a long running request is generally idle most of the time (e.g. waiting for database I/O or disk I/O or network I/O) so other requests can be processed and run during that idle time. This is the async nature of node.js and why it is important to use asynchronous I/O programming with node.js rather than synchronous I/O processing because asynchronous I/O allows other requests to run during the time when node.js is just waiting for I/O.

score 1 · Answer 2 · answered May 27 '15 at 18:00

1

Yes, it basically binds an event listener to that port; similar to how event listeners work in your own code. Going more in depth would involve sockets, etc...

https://nodejs.org/api/net.html#net_server_listen_port_host_backlog_callback

answered May 27 '15 at 18:00

ChadF

1,750
10
22

Ethan Brown · Answer 3 · 2015-05-27T18:13:15.360

The other answers are essentially correct, but I wanted to add more detail.

When you call createServer, the handler you pass in is what gets called on every incoming HTTP connection. But that is merely setting that up: it does not actually start the server or start listening for those connections. That doesn't happen until you call listen.

The (optional) callback for listen is just what gets called when the server has successfully started and is now listening for connections. Most of the time, it's simply used to log to the console that the server is started. You could also use it to record server start time for uptime monitoring. That callback is NOT invoked for every HTTP request: only once on server startup.

You don't even have to supply the callback for listen; it works fine without it. Here are some common variations (note that it's a good practice to let the port be specified by an environment variable, usually PORT; if that environment variable isn't set, there is a default):

// all in one line, no startup message
var server = http.createServer(handler).listen(process.env.PORT || 8083);

// two lines, no startup message
var server = http.createServer(handler);  // server NOT started
server.listen(process.env.PORT || 8083);  // server started, no confirmation

// most typical variation
var server = http.createServer(handler);
server.listen(process.env.PORT || 8083, function() {
    // server started, startup confirmed - note that this only gets called once
    console.log('server started at ' + Date.now());
});

Node.js httpserver.listen method ambiguity

3 Answers3