Skip to content
This repository has been archived by the owner on Apr 22, 2023. It is now read-only.

Commit

Permalink
cluster: add example for message passing
Browse files Browse the repository at this point in the history
  • Loading branch information
@ry
ry committed Nov 4, 2011
1 parent 5496e67 commit 1e3e6b7
Showing 1 changed file with 38 additions and 0 deletions.
38 changes: 38 additions & 0 deletions doc/api/cluster.markdown
View file
Expand Up @@ -34,6 +34,44 @@ Running node will now share port 8000 between the workers:
Worker 2438 online
Worker 2437 online

The difference between `cluster.fork()` and `child_process.fork()` is simply
that cluster allows TCP servers to be shared between workers. `cluster.fork`
is implemented on top of `child_process.fork`. The message passing API that
is available with `child_process.fork` is available with `cluster` as well.
As an example, here is a cluster which keeps count of the number of requests
in the master process via message passing:

var cluster = require('cluster');
var http = require('http');
var numReqs = 0;

if (cluster.isMaster) {
// Fork workers.
for (var i = 0; i < 2; i++) {
var worker = cluster.fork();

worker.on('message', function(msg) {
if (msg.cmd && msg.cmd == 'notifyRequest') {
numReqs++;
}
});
}

setInterval(function() {
console.log("numReqs =", numReqs);
}, 1000);
} else {
// Worker processes have a http server.
http.Server(function(req, res) {
res.writeHead(200);
res.end("hello world\n");
// Send message to master process
process.send({ cmd: 'notifyRequest' });
}).listen(8000);
}



### cluster.fork()

Spawn a new worker process. This can only be called from the master process.
Expand Down

3 comments on commit 1e3e6b7

@defunctzombie
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Question about cluster and the use case for why I would spin up multiple forks versus manage the processes myself. My goal is to have a zero downtime environment on one box. So for this, I usually run 2 of my server processes (on different ports, behind a proxy). Then when I want to do an upgrade or bounce the webserver, I bounce the first one (it stops accepting new connections and gracefully ends old ones). This means the proxy now uses the second one for all requests. I then bring back the first one and do the same with the second process (different port).

My understanding (and it may be wrong) is that with cluster, I will have the benefit of multiple processes, but I won't have the nice zero downtime capability because if I bounce the master process the children are also brought down and there is potentially a service gap. Is this correct?

@bnoordhuis
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shtylman: You can have two masters listening on different ports, each with its own set of workers. Not sure what you mean by 'bounce'. If you stop forwarding requests to one of the masters, eventually it'll have processed all outstanding requests and then you can safely upgrade it. I don't see how that is different from a non-clustered solution.

@defunctzombie
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess my point was that the reason I use different processes is to be able to do a stable rollout, not because I have 4 cores and if I just ran 1 process I would not be using the cores. I am not against cluster, just thought maybe some notes about a zero downtime usecase would be helpful for new people starting out. I can deff see many people thinking that they can just run one instance (having cluster shard to N cores) and not think about the benefits of multiple disjoint processes.

Please sign in to comment.