@ -6,8 +6,8 @@ A single instance of Node.js runs in a single thread. To take advantage of
multi-core systems the user will sometimes want to launch a cluster of Node.js
processes to handle the load.
The cluster module allows you to easily create child processes that
all share server ports.
The cluster module allows easy creation of child processes that all share
server ports.
```js
const cluster = require('cluster');
@ -88,27 +88,24 @@ Node.js process and a cluster worker differs:
idea of what the number 7 file descriptor references.
2. `server.listen(handle)` Listening on handles explicitly will cause
the worker to use the supplied handle, rather than talk to the master
process. If the worker already has the handle, then it's presumed
that you know what you are doing.
process.
3. `server.listen(0)` Normally, this will cause servers to listen on a
random port. However, in a cluster, each worker will receive the
same "random" port each time they do `listen(0)` . In essence, the
port is random the first time, but predictable thereafter. If you
want to listen on a unique port, generate a port number based on the
cluster worker ID.
port is random the first time, but predictable thereafter. To listen
on a unique port, generate a port number based on the cluster worker ID.
There is no routing logic in Node.js, or in your program, and no shared
state between the workers. Therefore, it is important to design your
program such that it does not rely too heavily on in-memory data objects
for things like sessions and login.
*Note*: Node.js does not provide routing logic. It is, therefore important to
design an application such that it does not rely too heavily on in-memory data
objects for things like sessions and login.
Because workers are all separate processes, they can be killed or
re-spawned depending on your program's needs, without affecting other
re-spawned depending on a program's needs, without affecting other
workers. As long as there are some workers still alive, the server will
continue to accept connections. If no workers are alive, existing connections
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.
will be dropped and new connections will be refused. Node.js does not
automatically manage the number of workers, however. It is the application's
responsibility to manage the worker pool based on its own needs.
@ -141,7 +138,7 @@ added: v0.7.3
This event is the same as the one provided by [`child_process.fork()`][].
In a worker you can also use `process.on('error')` .
Within a worker, `process.on('error')` may also be used .
### Event: 'exit'
<!-- YAML
@ -192,8 +189,9 @@ added: v0.7.0
* `message` {Object}
* `handle` {undefined|Object}
Similar to the `cluster.on('message')` event, but specific to this worker. In a
worker you can also use `process.on('message')` .
Similar to the `cluster.on('message')` event, but specific to this worker.
Within a worker, `process.on('message)` may also be used.
See [`process` event: `'message'` ][].
@ -336,9 +334,9 @@ added: v6.0.0
Set by calling `.kill()` or `.disconnect()` . Until then, it is `undefined` .
The boolean `worker.exitedAfterDisconnect` lets you distinguish between voluntary
and accidental exit, the master may choose not to respawn a worker based on
this value.
The boolean `worker.exitedAfterDisconnect` allows distinguishing between
voluntary and accidental exit, the master may choose not to respawn a worker
based on this value.
```js
cluster.on('exit', (worker, code, signal) => {
@ -369,9 +367,9 @@ cluster.workers
added: v0.11.14
-->
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.
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
has been created. It is disconnected after the `'disconnect'` event is emitted.
### worker.isDead()
<!-- YAML
@ -469,7 +467,7 @@ An alias to [`worker.exitedAfterDisconnect`][].
Set by calling `.kill()` or `.disconnect()` . Until then, it is `undefined` .
The boolean `worker.suicide` lets you distinguish between voluntary
The boolean `worker.suicide` is used to distinguish between voluntary
and accidental exit, the master may choose not to respawn a worker based on
this value.
@ -540,7 +538,7 @@ added: v0.7.0
* `worker` {cluster.Worker}
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.
This can be used to log worker activity, and create a custom timeout.
```js
const timeouts = [];
@ -568,13 +566,14 @@ added: v0.7.0
* `worker` {cluster.Worker}
* `address` {Object}
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.
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.
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.
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.
```js
cluster.on('listening', (worker, address) => {
@ -610,8 +609,9 @@ See [child_process event: 'message'][].
Before Node.js v6.0, this event emitted only the message and the handle,
but not the worker object, contrary to what the documentation stated.
If you need to support older versions and don't need the worker object,
you can work around the discrepancy by checking the number of arguments:
If support for older versions is required but a worker object is not
required, it is possible to work around the discrepancy by checking the
number of arguments:
```js
cluster.on('message', (worker, message, handle) => {
@ -713,8 +713,8 @@ added: v0.11.2
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()` , what ever comes first.
global setting and effectively frozen once either the first worker is spawned,
or `cluster.setupMaster()` is called, which ever 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
@ -750,7 +750,7 @@ changes:
After calling `.setupMaster()` (or `.fork()` ) this settings object will contain
the settings, including the default values.
This object is not supposed to be changed or set manually, by you .
This object is not intended to be changed or set manually .
## cluster.setupMaster([settings])
<!-- YAML
@ -850,8 +850,7 @@ eachWorker((worker) => {
});
```
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.
Using the worker's unique id is the easiest way to locate the worker.
```js
socket.on('data', (id) => {