<commit_before># cluster-service

[![Build Status](https://travis-ci.org/godaddy/node-cluster-service.png)](https://travis-ci.org/godaddy/node-cluster-service) [![NPM version](https://badge.fury.io/js/cluster-service.png)](http://badge.fury.io/js/cluster-service) [![Dependency Status](https://gemnasium.com/godaddy/node-cluster-service.png)](https://gemnasium.com/godaddy/node-cluster-service)


## Install

	npm install cluster-service

https://npmjs.org/package/cluster-service


## What is it?

The short answer:

	Turns your single process code into a fault-resilient multi-process service with
	built-in REST & CLI support.

The long answer:

	Adds the ability to execute worker processes over N cores for extra service resilience,
	includes worker process monitoring and restart on failure, continuous integration,
	as well as HTTP & command-line interfaces for health checks, cluster commands,
	and custom service commands.


 
## Getting Started

Turning your single process node app/service into a fault-resilient multi-process service with all of the bells and whistles has never been easier!

Your existing application, be it console app or service of some kind:

	// server.js
	console.log("Hello World");

Now, with a few extra lines of code, you can add considerably resilience and capabilities to your existing services:

	// server.js
	require("cluster-service").start({ worker: "./worker.js", accessKey: "<KEY>" });

	// worker.js
	console.log("Hello World"); // notice we moved our original app logic to the worker
	require("cluster-service").workerReady(); // this new line is required



## Talk to it

Now that your service is resilient to worker failure, and utilizing all cores of your machine, lets talk to it.

	restart all

or for a full list of commands...

	help
	
Check out Cluster Commands for more details.



## Start Options

When initializing your service, there are a number of options that expose various features:

	require("cluster-service").start({ accessKey: "123" });

* worker (default: "./worker.js")- Path of worker to start.
* accessKey - A secret key that must be specified if you wish to invoke commands to your service.
  Allows CLI & REST interfaces.
* restartonFailure (default: true) - When a worker stops unexpectedly, should it be automatically
  restarted?
* host (default: "localhost") - Host to bind to for REST interface. (Will only bind if accessKey
  is provided)
* port (default: 11987) - Port to bind to. If you leverage more than one cluster-service on a
  machine, you'll want to assign unique ports. (Will only bind if accessKey is provided)
* workerCount (default: os.cpus().length) - Gives you control over the number of processes to
  run the same worker concurrently. Recommended to be 2 or more for fault resilience. But some
  workers do not impact availability, such as task queues, and can be run as a single instance.
* restartDelayMs (default: 100) - The delay between failure detection and restart.
* restartsPerMinute (default: 10) - How many restarts are permitted by a worker in a minute
  before determining too critical to recover from.
* allowHttpGet (default: false) - For development purposes, can be enabled for testing, but is
  not recommended otherwise.
* cliEnabled (default: true) - Enable the command line interface. Can be disabled for background
  services, or test cases.
* ssl - If provided, will bind using HTTPS by passing this object as the
  [TLS options](http://nodejs.org/api/tls.html#tls_tls_createserver_options_secureconnectionlistener).
 


## Console & REST API

A DPS Cluster Service has two interfaces, the console (stdio), and an HTTP REST API. The two interfaces are treated identical, as console input/output is piped over the REST API. The reason for the piping is that a DPS Cluster Service is intentionally designed to only support one version of the given service running at any one time, and the port binding is the resource constraint. This allows secondary services to act as console-only interfaces as they pipe all input/output over HTTP to the already running service that owns the port. This flow enables the CLI to background processes.
The REST API is locked to a "accessKey" expected in the query string. The console automatically passes this key to the REST API, but for external REST API access, the key will need to be known.

	{ host: "localhost", port: 11987, accessKey: "<KEY>" }

<commit_msg>Added config option<commit_after># cluster-service

[![Build Status](https://travis-ci.org/godaddy/node-cluster-service.png)](https://travis-ci.org/godaddy/node-cluster-service) [![NPM version](https://badge.fury.io/js/cluster-service.png)](http://badge.fury.io/js/cluster-service) [![Dependency Status](https://gemnasium.com/godaddy/node-cluster-service.png)](https://gemnasium.com/godaddy/node-cluster-service)


## Install

	npm install cluster-service

https://npmjs.org/package/cluster-service


## What is it?

The short answer:

	Turns your single process code into a fault-resilient multi-process service with
	built-in REST & CLI support.

The long answer:

	Adds the ability to execute worker processes over N cores for extra service resilience,
	includes worker process monitoring and restart on failure, continuous integration,
	as well as HTTP & command-line interfaces for health checks, cluster commands,
	and custom service commands.


 
## Getting Started

Turning your single process node app/service into a fault-resilient multi-process service with all of the bells and whistles has never been easier!

Your existing application, be it console app or service of some kind:

	// server.js
	console.log("Hello World");

Now, with a few extra lines of code, you can add considerably resilience and capabilities to your existing services:

	// server.js
	require("cluster-service").start({ worker: "./worker.js", accessKey: "<KEY>" });

	// worker.js
	console.log("Hello World"); // notice we moved our original app logic to the worker
	require("cluster-service").workerReady(); // this new line is required



## Talk to it

Now that your service is resilient to worker failure, and utilizing all cores of your machine, lets talk to it.

	restart all

or for a full list of commands...

	help
	
Check out Cluster Commands for more details.



## Start Options

When initializing your service, there are a number of options that expose various features:

	require("cluster-service").start({ worker: "worker.js", accessKey: "123" });

* worker (default: "./worker.js") - Path of worker to start.
* accessKey - A secret key that must be specified if you wish to invoke commands to your service.
  Allows CLI & REST interfaces.
* config - A filename to the configuration to load. Useful to keep options from having to be inline.
* restartonFailure (default: true) - When a worker stops unexpectedly, should it be automatically
  restarted?
* host (default: "localhost") - Host to bind to for REST interface. (Will only bind if accessKey
  is provided)
* port (default: 11987) - Port to bind to. If you leverage more than one cluster-service on a
  machine, you'll want to assign unique ports. (Will only bind if accessKey is provided)
* workerCount (default: os.cpus().length) - Gives you control over the number of processes to
  run the same worker concurrently. Recommended to be 2 or more for fault resilience. But some
  workers do not impact availability, such as task queues, and can be run as a single instance.
* restartDelayMs (default: 100) - The delay between failure detection and restart.
* restartsPerMinute (default: 10) - How many restarts are permitted by a worker in a minute
  before determining too critical to recover from.
* allowHttpGet (default: false) - For development purposes, can be enabled for testing, but is
  not recommended otherwise.
* cliEnabled (default: true) - Enable the command line interface. Can be disabled for background
  services, or test cases.
* ssl - If provided, will bind using HTTPS by passing this object as the
  [TLS options](http://nodejs.org/api/tls.html#tls_tls_createserver_options_secureconnectionlistener).
 


## Console & REST API

A DPS Cluster Service has two interfaces, the console (stdio), and an HTTP REST API. The two interfaces are treated identical, as console input/output is piped over the REST API. The reason for the piping is that a DPS Cluster Service is intentionally designed to only support one version of the given service running at any one time, and the port binding is the resource constraint. This allows secondary services to act as console-only interfaces as they pipe all input/output over HTTP to the already running service that owns the port. This flow enables the CLI to background processes.
The REST API is locked to a "accessKey" expected in the query string. The console automatically passes this key to the REST API, but for external REST API access, the key will need to be known.

	{ host: "localhost", port: 11987, accessKey: "<KEY>" }


{'fraction_non_alphanumeric': 0.07831123983513423, 'fraction_numerical': 0.0042330399910883365, 'mean_word_length': 4.271873165002936, 'pattern_counts': {'":': 0, '<': 7, '<?xml version=': 0, '>': 7, 'https://': 12, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '273594', 'n_tokens_mistral': 2441, 'n_tokens_neox': 2283, 'n_words': 1171}