These parameter values have somewhat sensible defaults, but can be overridden for a given BatchCluster.
Should batch-cluster try to clean up after spawned processes that don't shut down?
Only disable this if you have another means of PID cleanup.
this.end() is called, or Node broadcasts the
event, this is the milliseconds spent waiting for currently running
tasks to finish before sending kill signals to child processes.
Setting this value to 0 means child processes will immediately receive a kill signal to shut down. Any pending requests may be interrupted. Must be >= 0. Defaults to 500ms.
Child processes will be recycled when they reach this age.
If this value is set to 0, child processes will not "age out".
This value must not be less than
Defaults to 5 minutes.
No more than
maxProcs child processes will be run at a given time
to serve pending tasks.
Defaults to 1.
If the initial
versionCommand fails for new spawned processes more
than this rate, end this BatchCluster and throw an error, because
something is terribly wrong.
If this backstop didn't exist, new (failing) child processes would be created indefinitely.
Must be >= 0. Defaults to 10.
Processes will be recycled after processing
tasks. Depending on the commands and platform, batch mode commands
shouldn't exhibit unduly memory leaks for at least tens if not
hundreds of tasks. Setting this to a low number (like less than 10)
will impact performance markedly, due to OS process start/stop
maintenance. Setting this to a very high number (> 1000) may result in
more memory being consumed than necessary.
Must be >= 0. Defaults to 500
If maxProcs > 1, spawning new child processes to process tasks can slow down initial processing, and create unnecessary processes.
Must be >= 0ms. Defaults to 1.5 seconds.
This is the minimum interval between calls to
runs pending tasks and shuts down old child processes.
Must be > 0. Defaults to 5 seconds.
Spawning new child processes and servicing a "version" task must not
take longer than
spawnTimeoutMillis before the process is considered
failed, and need to be restarted. Be pessimistic here--windows can
regularly take several seconds to spin up a process, thanks to
Must be >= 100ms. Defaults to 15 seconds.
When a task sees a "pass" or "fail" from either stdout or stderr, it needs to wait for the other stream to finish flushing to ensure the task's Parser sees the entire relevant stream contents. A larger number may be required for slower computers to prevent internal errors due to lack of stream coercion.
Note that this puts a hard lower limit on task latency. You don't want to set this to a large number.
Defaults to 10ms.
If commands take longer than this, presume the underlying process is dead and we should fail the task.
This should be set to something on the order of seconds.
Must be >= 10ms. Defaults to 10 seconds.
Generated using TypeDoc