node-everlast
This is an event driven supervisor for Node.js designed to be used in your code instead of a CLI. It allows you to spawn children processes based on specifications and define restart strategies. It is inspired by Erlang's supervisor.
For example, this would make starting and managing a worker process per core very easy.
Other tools in this area exist, but they can be unstable, are designed to be used from the CLI, or are weak alternatives to runit which solves a different problem.
One major difference between this supervisor and Erlang's is that you can stop a child, though the restart strategy will still kick in. If this is not desirable then you can set the strategy to Never, so it'll never trigger restarts.
Installing
npm install everlast
Using
See ./examples/run.js
for a quick code example and ./tests/Supervisor.js
for more complicated examples. Plenty of documentation below.
Run npm test
to run the unit tests.
Supervisor
Children are defined by their specs. See Child Spec below.
The children are managed internally in an array. When interacting with the supervisor you typically pass it a child index since multiple children can, and likely will, share an id. For example:
var everlast = ;var sup = ; //uses OneForOne(3, 1) by default sup; sup; sup;
See Child Reference below.
Inherits from EventEmitter. Each event callback gets passed two arguments,
ref
(child reference, schema is promised) and context
(contextual
information about the event, no schema is promised).
These events are emitted:
- starting - A child is starting.
- running - A child is running, it should be considered "up".
- stopping - A child is stopping, likely due to
stopChild()
. - restarting - A child is restarting, likely due to either
restartChild()
or the restart strategy. - stopped - A child is stopped. See the context for whether the restart strategy will attempt to revive the child.
- down - A child is stopped and won't be restarted due to the strategy's constraints (max time and retries).
General events:
- error - Your typical Node.js error event. The only arg is a
Error
. Used when an asynchronous process hits an error and can't return it to you.
All functions return false
on success and a new Error
on failure. See
./src/Supervisor.js
for more detailed per function documentation.
-
startChild(spec) - Starts the child, validating the spec internally.
-
stopChild(idx) - Stops the child, then deletes it with
deleteChild()
. -
restartChild(idx) - Restarts the child, settings its state to
restarting
. -
stopAllChildren(idxIgnores) - Stops all the children from right-to-left, skipping any indexes in the
idxIgnores
array. -
deleteChild(idx) - Deletes the child, which must be already stopped.
-
getChild(idx) - Retrieves the current child ref.
-
countChildren() - Returns a count for the children regardless of their statel
-
checkChildSpecs(specs) - Takes an array of child specs and validates them.
-
getRestartStrategy() - Returns the current restart strategy.
Child Spec
This is the structure passed to startChild()
to define how the child will
behave.
id: string //the id, typically something like "web-server" path: string //the path to the server (ex., `process.cwd() + '/bin/run.js'`) args: //optional, passed to `child_process.spawn()`, env: {} //optional, extends process.env, passed to `child_process.spawn()`
Child Reference
This is the structure passed in all child events. The index (idx
) can then be
used to trigger further actions, such as adding more children of that type.
id: string //the same as the child spec you passed idx: int //the internal index of the child pid: int //the child's process's PID //Internal to Supervisor only (never sent outside): args: //from child spec env: {} //from child spec process: ChildProcess //return value from `child_process.spawn()` state: int //array index from CHILD_STATES
Restart Strategies
Each strategy tracks how often a child stops in a given time period. It then compares this against your defined maxRestarts and maxTime to decide whether a restart should be triggered.
If a threshold of restarts happens (maxRestarts
) within a given time period
(maxTime
), then the child is not restarted. For example, using OneForOne
with maxRestarts=2
and maxTime=1
, if your process stops twice in one second
it will not be restarted.
The strategies:
-
everlast.restartStrategies.OneForOne
- If a child stops, then only that child will be restarted. -
everlast.restartStrategies.OneForAll
- If a child stops, then restart all children including that one. -
everlast.restartStrategies.RestForOne
- If a child stops, then restart it and the children to the right of it in the start up order, iterating from right-to-left (ex., child at idx 3 stops and 5 children are linked, it restarts 5, then 4, then 3). -
everlast.restartStrategies.Never
- Never triggers restarts. -
everlast.restartStrategies.Base
- All strategies inherit from this. Not meant for use in your code.
Child Spawning
Children are spawned with child_process.spawn()
. Their stdout and stderr
streams are piped to the process's respective stdout and stderr without
modification.
If you tell it to, Supervisor will augment the log lines by replacing %s
with
the child process's id and PID. For example:
//parent.jsvar sup = null 3 2 true;sup;sup; //child.jsconsole;
The resulting output would be:
running with pid 123
[foo@123] doing something
TODO
A list of features that will be implemented which you might expect, especially if you've used Erlang's supervisor.
- Allow children to be another Supervisor, enabling multi-level trees.