@ -101,294 +101,219 @@ will be dropped and new connections will be refused. Node.js does not
automatically manage the number of workers for you, however. It is your
responsibility to manage the worker pool for your application's needs.
## cluster.schedulingPolicy
The scheduling policy, either `cluster.SCHED_RR` for round-robin or
`cluster.SCHED_NONE` to leave it to the operating system. This is a
global setting and effectively frozen once you spawn the first worker
or call `cluster.setupMaster()` , whatever comes first.
`SCHED_RR` is the default on all operating systems except Windows.
Windows will change to `SCHED_RR` once libuv is able to effectively
distribute IOCP handles without incurring a large performance hit.
`cluster.schedulingPolicy` can also be set through the
`NODE_CLUSTER_SCHED_POLICY` environment variable. Valid
values are `"rr"` and `"none"` .
## cluster.settings
* {Object}
* `execArgv` {Array} list of string arguments passed to the Node.js
executable. (Default=`process.execArgv`)
* `exec` {String} file path to worker file. (Default=`process.argv[1]`)
* `args` {Array} string arguments passed to worker.
(Default=`process.argv.slice(2)`)
* `silent` {Boolean} whether or not to send output to parent's stdio.
(Default=`false`)
* `uid` {Number} Sets the user identity of the process. (See setuid(2).)
* `gid` {Number} Sets the group identity of the process. (See setgid(2).)
After calling `.setupMaster()` (or `.fork()` ) this settings object will contain
the settings, including the default values.
## Class: Worker
It is effectively frozen after being set, because `.setupMaster()` can
only be called once.
A Worker object contains all public information and method about a worker.
In the master it can be obtained using `cluster.workers` . In a worker
it can be obtained using `cluster.worker` .
This object is not supposed to be changed or set manually, by you.
### Event: 'disconnect'
## cluster.isMaster
Similar to the `cluster.on('disconnect')` event, but specific to this worker.
* {Boolean}
cluster.fork().on('disconnect', function() {
// Worker has disconnected
});
True if the process is a master. This is determined
by the `process.env.NODE_UNIQUE_ID` . If `process.env.NODE_UNIQUE_ID` is
undefined, then `isMaster` is `true` .
### Event: 'error'
## cluster.isWorker
This event is the same as the one provided by `child_process.fork()` .
* {Boolean}
In a worker you can also use `process.on('error')` .
True if the process is not a master (it is the negation of `cluster.isMaster` ).
[ChildProcess.send()]: child_process.html#child_process_child_send_message_sendhandle_callback
## Event: 'fork '
### Event: 'exit '
* `worker` {Worker object}
* `code` {Number} the exit code, if it exited normally.
* `signal` {String} the name of the signal (eg. `'SIGHUP'` ) that caused
the process to be killed.
When a new worker is forked the cluster module will emit a 'fork' event.
This can be used to log worker activity, and create your own timeout.
Similar to the `cluster.on('exit')` event, but specific to this worker.
var timeouts = [];
function errorMsg() {
console.error("Something must be wrong with the connection ...");
var worker = cluster.fork();
worker.on('exit', function(code, signal) {
if( signal ) {
console.log("worker was killed by signal: "+signal);
} else if( code !== 0 ) {
console.log("worker exited with error code: "+code);
} else {
console.log("worker success!");
}
cluster.on('fork', function(worker) {
timeouts[worker.id] = setTimeout(errorMsg, 2000);
});
cluster.on('listening', function(worker, address) {
clearTimeout(timeouts[worker.id]);
});
cluster.on('exit', function(worker, code, signal) {
clearTimeout(timeouts[worker.id]);
errorMsg();
});
## Event: 'online '
### Event: 'listening'
* `worker` {Worker o bject}
* `address` {Object}
After forking a new worker, the worker should respond with an online message.
When the master receives an online message it will emit this event.
The difference between 'fork' and 'online' is that fork is emitted when the
master forks a worker, and 'online' is emitted when the worker is running.
Similar to the `cluster.on('listening')` event, but specific to this worker.
cluster.on('online', function(worker ) {
console.log("Yay, the worker responded after it was forked");
cluster.fork().on('listening', function(address) {
// Worker is listening
});
## Event: 'listening'
It is not emitted in the worker.
* `worker` {Worker object}
* `address` {Object}
### Event: 'message'
After calling `listen()` from a worker, when the 'listening' event is emitted on
the server, a listening event will also be emitted on `cluster` in the master.
* `message` {Object}
The event handler is executed with two arguments, the `worker` contains the worker
object and the `address` object contains the following connection properties:
`address` , `port` and `addressType` . This is very useful if the worker is listening
on more than one address.
Similar to the `cluster.on('message')` event, but specific to this worker.
cluster.on('listening', function(worker, address) {
console.log("A worker is now connected to " + address.address + ":" + address.port);
});
This event is the same as the one provided by `child_process.fork()` .
The `addressType` is one of:
In a worker you can also use `process.on('message')` .
* `4` (TCPv4)
* `6` (TCPv6)
* `-1` (unix domain socket)
* `"udp4"` or `"udp6"` (UDP v4 or v6)
As an example, here is a cluster that keeps count of the number of requests
in the master process using the message system:
## Event: 'disconnect'
var cluster = require('cluster');
var http = require('http');
* `worker` {Worker object}
if (cluster.isMaster) {
Emitted after the worker IPC channel has disconnected. This can occur when a
worker exits gracefully, is killed, or is disconnected manually (such as with
worker.disconnect()).
// Keep track of http requests
var numReqs = 0;
setInterval(function() {
console.log("numReqs =", numReqs);
}, 1000);
There may be a delay between the `disconnect` and `exit` events. These events
can be used to detect if the process is stuck in a cleanup or if there are
long-living connections.
// Count requests
function messageHandler(msg) {
if (msg.cmd & & msg.cmd == 'notifyRequest') {
numReqs += 1;
}
}
cluster.on('disconnect', function(worker) {
console.log('The worker #' + worker.id + ' has disconnected');
// Start workers and listen for messages containing notifyRequest
var numCPUs = require('os').cpus().length;
for (var i = 0; i < numCPUs ; i + + ) {
cluster.fork();
}
Object.keys(cluster.workers).forEach(function(id) {
cluster.workers[id].on('message', messageHandler);
});
## Event: 'exit'
} else {
* `worker` {Worker object}
* `code` {Number} the exit code, if it exited normally.
* `signal` {String} the name of the signal (eg. `'SIGHUP'` ) that caused
the process to be killed.
// Worker processes have a http server.
http.Server(function(req, res) {
res.writeHead(200);
res.end("hello world\n");
When any of the workers die the cluster module will emit the 'exit' event.
// notify master about the request
process.send({ cmd: 'notifyRequest' });
}).listen(8000);
}
This can be used to restart the worker by calling `.fork()` again.
### Event: 'online'
cluster.on('exit', function(worker, code, signal) {
console.log('worker %d died (%s). restarting...',
worker.process.pid, signal || code);
cluster.fork();
Similar to the `cluster.on('online')` event, but specific to this worker.
cluster.fork().on('online', function() {
// Worker is online
});
See [child_process event: 'exit' ](child_process.html#child_process_event_exit ) .
It is not emitted in the worker .
## Event: 'message'
### worker.disconnect()
* `worker` {Worker object}
* `message` {Object}
In a worker, this function will close all servers, wait for the 'close' event on
those servers, and then disconnect the IPC channel.
Emitted when any worker receives a message.
In the master, an internal message is sent to the worker causing it to call
`.disconnect()` on itself.
See
[child_process event: 'message' ](child_process.html#child_process_event_message ).
Causes `.suicide` to be set.
## Event: 'setup'
Note that after a server is closed, it will no longer accept new connections,
but connections may be accepted by any other listening worker. Existing
connections will be allowed to close as usual. When no more connections exist,
see [server.close() ](net.html#net_event_close ), the IPC channel to the worker
will close allowing it to die gracefully.
* `settings` {Object}
The above applies *only* to server connections, client connections are not
automatically closed by workers, and disconnect does not wait for them to close
before exiting.
Emitted every time `.setupMaster()` is called.
Note that in a worker, `process.disconnect` exists, but it is not this function,
it is [disconnect ](child_process.html#child_process_child_disconnect ).
The `settings` object is the `cluster.settings` object at the time
`.setupMaster()` was called and is advisory only, since multiple calls to
`.setupMaster()` can be made in a single tick.
Because long living server connections may block workers from disconnecting, it
may be useful to send a message, so application specific actions may be taken to
close them. It also may be useful to implement a timeout, killing a worker if
the `disconnect` event has not been emitted after some time.
If accuracy is important, use `cluster.settings` .
if (cluster.isMaster) {
var worker = cluster.fork();
var timeout;
## cluster.setupMaster([settings])
worker.on('listening', function(address) {
worker.send('shutdown');
worker.disconnect();
timeout = setTimeout(function() {
worker.kill();
}, 2000);
});
* `settings` {Object}
* `exec` {String} file path to worker file. (Default=`process.argv[1]`)
* `args` {Array} string arguments passed to worker.
(Default=`process.argv.slice(2)`)
* `silent` {Boolean} whether or not to send output to parent's stdio.
(Default=`false`)
worker.on('disconnect', function() {
clearTimeout(timeout);
});
`setupMaster` is used to change the default 'fork' behavior. Once called,
the settings will be present in `cluster.settings` .
} else if (cluster.isWorker) {
var net = require('net');
var server = net.createServer(function(socket) {
// connections never end
});
Note that:
server.listen(8000);
* any settings changes only affect future calls to `.fork()` and have no
effect on workers that are already running
* The *only* attribute of a worker that cannot be set via `.setupMaster()` is
the `env` passed to `.fork()`
* the defaults above apply to the first call only, the defaults for later
calls is the current value at the time of `cluster.setupMaster()` is called
process.on('message', function(msg) {
if(msg === 'shutdown') {
// initiate graceful close of any connections to server
}
});
}
Example:
### worker.id
var cluster = require('cluster');
cluster.setupMaster({
exec: 'worker.js',
args: ['--use', 'https'],
silent: true
});
cluster.fork(); // https worker
cluster.setupMaster({
args: ['--use', 'http']
});
cluster.fork(); // http worker
This can only be called from the master process.
## cluster.fork([env])
* `env` {Object} Key/value pairs to add to worker process environment.
* return {Worker object}
Spawn a new worker process.
This can only be called from the master process.
## cluster.disconnect([callback])
* `callback` {Function} called when all workers are disconnected and handles are
closed
Calls `.disconnect()` on each worker in `cluster.workers` .
When they are disconnected all internal handles will be closed, allowing the
master process to die gracefully if no other event is waiting.
The method takes an optional callback argument which will be called when finished.
This can only be called from the master process.
* {Number}
## cluster.worker
Each new worker is given its own unique id, this id is stored in the
`id` .
* {Object}
While a worker is alive, this is the key that indexes it in
cluster.workers
A reference to the current worker object. Not available in the master process.
### worker.isConnected()
var cluster = require('cluster');
This function returns `true` if the worker is connected to its master via its IPC
channel, `false` otherwise. A worker is connected to its master after it's been
created. It is disconnected after the `disconnect` event is emitted.
if (cluster.isMaster) {
console.log('I am master');
cluster.fork();
cluster.fork();
} else if (cluster.isWorker) {
console.log('I am worker #' + cluster.worker.id);
}
### worker.isDead()
## cluster.workers
This function returns `true` if the worker's process has terminated (either
because of exiting or being signaled). Otherwise, it returns `false` .
* {Object}
### worker.kill([signal='SIGTERM'])
A hash that stores the active worker objects, keyed by `id` field. Makes it
easy to loop through all the workers. It is only available in the master
* `signal` {String} Name of the kill signal to send to the worker
process.
A worker is removed from cluster.workers after the worker has disconnected _and_
exited. The order between these two events cannot be determined in advance.
However, it is guaranteed that the removal from the cluster.workers list happens
before last `'disconnect'` or `'exit'` event is emitted.
// Go through all workers
function eachWorker(callback) {
for (var id in cluster.workers) {
callback(cluster.workers[id]);
}
}
eachWorker(function(worker) {
worker.send('big announcement to all workers');
});
Should you wish to reference a worker over a communication channel, using
the worker's unique id is the easiest way to find the worker.
socket.on('data', function(id) {
var worker = cluster.workers[id];
});
## Class: Worker
A Worker object contains all public information and method about a worker.
In the master it can be obtained using `cluster.workers` . In a worker
it can be obtained using `cluster.worker` .
### worker.id
This function will kill the worker. In the master, it does this by disconnecting
the `worker.process` , and once disconnected, killing with `signal` . In the
worker, it does it by disconnecting the channel, and then exiting with code `0` .
* {Number}
Causes `.suicide` to be set.
Each new worker is given its own unique id, this id is stored in the
`id` .
This method is aliased as `worker.destroy()` for backwards compatibility.
While a worker is alive, this is the key that indexes it in
cluster.workers
Note that in a worker, `process.kill()` exists, but it is not this function,
it is [kill ](process.html#process_process_kill_pid_signal ).
### worker.process
@ -405,24 +330,6 @@ Note that workers will call `process.exit(0)` if the `'disconnect'` event occurs
on `process` and `.suicide` is not `true` . This protects against accidental
disconnection.
### worker.suicide
* {Boolean}
Set by calling `.kill()` or `.disconnect()` , until then it is `undefined` .
The boolean `worker.suicide` lets you distinguish between voluntary and accidental
exit, the master may choose not to respawn a worker based on this value.
cluster.on('exit', function(worker, code, signal) {
if (worker.suicide === true) {
console.log('Oh, it was just suicide\' – no need to worry').
}
});
// kill worker
worker.kill();
### worker.send(message[, sendHandle][, callback])
* `message` {Object}
@ -450,198 +357,293 @@ This example will echo back all messages from the master:
});
}
### worker.kill([signal='SIGTERM'])
### worker.suicide
* `signal` {String} Name of the kill signal to send to the worker
process.
* {Boolean}
This function will kill the worker. In the master, it does this by disconnecting
the `worker.process` , and once disconnected, killing with `signal` . In the
worker, it does it by disconnecting the channel, and then exiting with code `0` .
Set by calling `.kill()` or `.disconnect()` , until then it is `undefined` .
Causes `.suicide` to be set.
The boolean `worker.suicide` lets you distinguish between voluntary and accidental
exit, the master may choose not to respawn a worker based on this value.
This method is aliased as `worker.destroy()` for backwards compatibility.
cluster.on('exit', function(worker, code, signal) {
if (worker.suicide === true) {
console.log('Oh, it was just suicide\' – no need to worry').
}
});
Note that in a worker, `process.kill()` exists, but it is not this function,
it is [kill ](process.html#process_process_kill_pid_signal ).
// kill worker
worker.kill();
### worker.disconnect()
## Event: 'disconnect'
In a worker, this function will close all servers, wait for the 'close' event on
those servers, and then disconnect the IPC channel.
* `worker` {Worker object}
In the master, an internal message is sent to the worker causing it to call
`.disconnect()` on itself.
Emitted after the worker IPC channel has disconnected. This can occur when a
worker exits gracefully, is killed, or is disconnected manually (such as with
worker.disconnect()).
Causes `.suicide` to be set.
There may be a delay between the `disconnect` and `exit` events. These events
can be used to detect if the process is stuck in a cleanup or if there are
long-living connections.
Note that after a server is closed, it will no longer accept new connections,
but connections may be accepted by any other listening worker. Existing
connections will be allowed to close as usual. When no more connections exist,
see [server.close() ](net.html#net_event_close ), the IPC channel to the worker
will close allowing it to die gracefully.
cluster.on('disconnect', function(worker) {
console.log('The worker #' + worker.id + ' has disconnected');
});
The above applies *only* to server connections, client connections are not
automatically closed by workers, and disconnect does not wait for them to close
before exiting.
## Event: 'exit'
Note that in a worker, `process.disconnect` exists, but it is not this function,
it is [disconnect ](child_process.html#child_process_child_disconnect ).
* `worker` {Worker object}
* `code` {Number} the exit code, if it exited normally.
* `signal` {String} the name of the signal (eg. `'SIGHUP'` ) that caused
the process to be killed.
Because long living server connections may block workers from disconnecting, it
may be useful to send a message, so application specific actions may be taken to
close them. It also may be useful to implement a timeout, killing a worker if
the `disconnect` event has not been emitted after some time.
When any of the workers die the cluster module will emit the 'exit' event.
if (cluster.isMaster) {
var worker = cluster.fork();
var timeout;
This can be used to restart the worker by calling `.fork()` again.
worker.on('listening', function(address) {
worker.send('shutdown');
worker.disconnect();
timeout = setTimeout(function() {
worker.kill();
}, 2000);
cluster.on('exit', function(worker, code, signal) {
console.log('worker %d died (%s). restarting...',
worker.process.pid, signal || code);
cluster.fork();
});
worker.on('disconnect', function() {
clearTimeout(timeout);
});
See [child_process event: 'exit' ](child_process.html#child_process_event_exit ).
} else if (cluster.isWorker) {
var net = require('net');
var server = net.createServer(function(socket) {
// connections never end
});
## Event: 'fork'
server.listen(8000);
* `worker` {Worker object}
process.on('message', function(msg) {
if(msg === 'shutdown') {
// initiate graceful close of any connections to server
When a new worker is forked the cluster module will emit a 'fork' event.
This can be used to log worker activity, and create your own timeout.
var timeouts = [];
function errorMsg() {
console.error("Something must be wrong with the connection ...");
}
cluster.on('fork', function(worker) {
timeouts[worker.id] = setTimeout(errorMsg, 2000);
});
cluster.on('listening', function(worker, address) {
clearTimeout(timeouts[worker.id]);
});
cluster.on('exit', function(worker, code, signal) {
clearTimeout(timeouts[worker.id]);
errorMsg();
});
}
### worker.isDead()
## Event: 'listening'
This function returns `true` if the worker's process has terminated (either
because of exiting or being signaled). Otherwise, it returns `false` .
* `worker` {Worker object}
* `address` {Object}
### worker.isConnected()
After calling `listen()` from a worker, when the 'listening' event is emitted on
the server, a listening event will also be emitted on `cluster` in the master.
This function returns `true` if the worker is connected to its master via its IPC
channel, `false` otherwise. A worker is connected to its master after it's been
created. It is disconnected after the `disconnect` event is emitted.
The event handler is executed with two arguments, the `worker` contains the worker
object and the `address` object contains the following connection properties:
`address` , `port` and `addressType` . This is very useful if the worker is listening
on more than one address.
### Event: 'message'
cluster.on('listening', function(worker, address) {
console.log("A worker is now connected to " + address.address + ":" + address.port);
});
The `addressType` is one of:
* `4` (TCPv4)
* `6` (TCPv6)
* `-1` (unix domain socket)
* `"udp4"` or `"udp6"` (UDP v4 or v6)
## Event: 'message'
* `worker` {Worker object}
* `message` {Object}
Similar to the `cluster.on('message')` event, but specific to this worker.
Emitted when any worker receives a message .
This event is the same as the one provided by `child_process.fork()` .
See
[child_process event: 'message' ](child_process.html#child_process_event_message ).
In a worker you can also use `process.on('message')` .
## Event: 'online'
As an example, here is a cluster that keeps count of the number of requests
in the master process using the message system:
* `worker` {Worker object}
var cluster = require('cluster');
var http = require('http');
After forking a new worker, the worker should respond with an online message.
When the master receives an online message it will emit this event.
The difference between 'fork' and 'online' is that fork is emitted when the
master forks a worker, and 'online' is emitted when the worker is running.
if (cluster.isMaster) {
cluster.on('online', function(worker) {
console.log("Yay, the worker responded after it was forked");
});
// Keep track of http requests
var numReqs = 0;
setInterval(function() {
console.log("numReqs =", numReqs);
}, 1000);
## Event: 'setup'
// Count requests
function messageHandler(msg) {
if (msg.cmd & & msg.cmd == 'notifyRequest') {
numReqs += 1;
}
}
* `settings` {Object}
// Start workers and listen for messages containing notifyRequest
var numCPUs = require('os').cpus().length;
for (var i = 0; i < numCPUs ; i + + ) {
cluster.fork();
}
Emitted every time `.setupMaster()` is called.
Object.keys(cluster.workers).forEach(function(id) {
cluster.workers[id].on('message', messageHandler);
});
The `settings` object is the `cluster.settings` object at the time
`.setupMaster()` was called and is advisory only, since multiple calls to
`.setupMaster()` can be made in a single tick.
} else {
If accuracy is important, use `cluster.settings` .
// Worker processes have a http server.
http.Server(function(req, res) {
res.writeHead(200);
res.end("hello world\n");
## cluster.disconnect([callback])
// notify master about the request
process.send({ cmd: 'notifyRequest' });
}).listen(8000);
}
* `callback` {Function} called when all workers are disconnected and handles are
closed
### Event: 'online'
Calls `.disconnect()` on each worker in `cluster.workers` .
Similar to the `cluster.on('online')` event, but specific to this worker.
When they are disconnected all internal handles will be closed, allowing the
master process to die gracefully if no other event is waiting.
cluster.fork().on('online', function() {
// Worker is online
});
The method takes an optional callback argument which will be called when finished.
It is not emitted in the worker .
This can only be called from the master process.
### Event: 'listening'
## cluster.fork([env])
* `address` {Object}
* `env` {Object} Key/value pairs to add to worker process environment.
* return {Worker object}
Similar to the `cluster.on('listening')` event, but specific to this worker .
Spawn a new worker process .
cluster.fork().on('listening', function(address) {
// Worker is listening
});
This can only be called from the master process.
It is not emitted in the worker.
## cluster.isMaster
### Event: 'disconnect'
* {Boolean}
Similar to the `cluster.on('disconnect')` event, but specific to this worker.
True if the process is a master. This is determined
by the `process.env.NODE_UNIQUE_ID` . If `process.env.NODE_UNIQUE_ID` is
undefined, then `isMaster` is `true` .
cluster.fork().on('disconnect', function() {
// Worker has disconnected
## cluster.isWorker
* {Boolean}
True if the process is not a master (it is the negation of `cluster.isMaster` ).
## cluster.schedulingPolicy
The scheduling policy, either `cluster.SCHED_RR` for round-robin or
`cluster.SCHED_NONE` to leave it to the operating system. This is a
global setting and effectively frozen once you spawn the first worker
or call `cluster.setupMaster()` , whatever comes first.
`SCHED_RR` is the default on all operating systems except Windows.
Windows will change to `SCHED_RR` once libuv is able to effectively
distribute IOCP handles without incurring a large performance hit.
`cluster.schedulingPolicy` can also be set through the
`NODE_CLUSTER_SCHED_POLICY` environment variable. Valid
values are `"rr"` and `"none"` .
## cluster.settings
* {Object}
* `execArgv` {Array} list of string arguments passed to the Node.js
executable. (Default=`process.execArgv`)
* `exec` {String} file path to worker file. (Default=`process.argv[1]`)
* `args` {Array} string arguments passed to worker.
(Default=`process.argv.slice(2)`)
* `silent` {Boolean} whether or not to send output to parent's stdio.
(Default=`false`)
* `uid` {Number} Sets the user identity of the process. (See setuid(2).)
* `gid` {Number} Sets the group identity of the process. (See setgid(2).)
After calling `.setupMaster()` (or `.fork()` ) this settings object will contain
the settings, including the default values.
It is effectively frozen after being set, because `.setupMaster()` can
only be called once.
This object is not supposed to be changed or set manually, by you.
## cluster.setupMaster([settings])
* `settings` {Object}
* `exec` {String} file path to worker file. (Default=`process.argv[1]`)
* `args` {Array} string arguments passed to worker.
(Default=`process.argv.slice(2)`)
* `silent` {Boolean} whether or not to send output to parent's stdio.
(Default=`false`)
`setupMaster` is used to change the default 'fork' behavior. Once called,
the settings will be present in `cluster.settings` .
Note that:
* any settings changes only affect future calls to `.fork()` and have no
effect on workers that are already running
* The *only* attribute of a worker that cannot be set via `.setupMaster()` is
the `env` passed to `.fork()`
* the defaults above apply to the first call only, the defaults for later
calls is the current value at the time of `cluster.setupMaster()` is called
Example:
var cluster = require('cluster');
cluster.setupMaster({
exec: 'worker.js',
args: ['--use', 'https'],
silent: true
});
cluster.fork(); // https worker
cluster.setupMaster({
args: ['--use', 'http']
});
cluster.fork(); // http worker
### Event: 'exit'
This can only be called from the master process.
* `code` {Number} the exit code, if it exited normally.
* `signal` {String} the name of the signal (eg. `'SIGHUP'` ) that caused
the process to be killed.
## cluster.worker
Similar to the `cluster.on('exit')` event, but specific to this worker.
* {Object}
var worker = cluster.fork();
worker.on('exit', function(code, signal) {
if( signal ) {
console.log("worker was killed by signal: "+signal);
} else if( code !== 0 ) {
console.log("worker exited with error code: "+code);
} else {
console.log("worker success!");
A reference to the current worker object. Not available in the master process.
var cluster = require('cluster');
if (cluster.isMaster) {
console.log('I am master');
cluster.fork();
cluster.fork();
} else if (cluster.isWorker) {
console.log('I am worker #' + cluster.worker.id);
}
});
### Event: 'error'
## cluster.workers
This event is the same as the one provided by `child_process.fork()` .
* {Object}
In a worker you can also use `process.on('error')` .
A hash that stores the active worker objects, keyed by `id` field. Makes it
easy to loop through all the workers. It is only available in the master
process.
[ChildProcess.send()]: child_process.html#child_process_child_send_message_sendhandle_callback
A worker is removed from cluster.workers after the worker has disconnected _and_
exited. The order between these two events cannot be determined in advance.
However, it is guaranteed that the removal from the cluster.workers list happens
before last `'disconnect'` or `'exit'` event is emitted.
// Go through all workers
function eachWorker(callback) {
for (var id in cluster.workers) {
callback(cluster.workers[id]);
}
}
eachWorker(function(worker) {
worker.send('big announcement to all workers');
});
Should you wish to reference a worker over a communication channel, using
the worker's unique id is the easiest way to find the worker.
socket.on('data', function(id) {
var worker = cluster.workers[id];
});
Tristian Flanagan
9 years ago
James M Snell