Worker is a standalone JVM running separately from the Server Core. This provides an isolation of the Server Core from executed jobs (e.g. graphs, jobflows, etc.). Therefore, an issue caused by a job in Worker will not affect the Server Core.
Worker does not require any additional installation - it is started and managed by the Server. Worker runs on the same host as the Server Core, i.e. it is not used for parallel or distributed processes. In case of a Cluster, each Cluster node has its own Worker.
Worker is a relatively light-weight and simple executor of jobs. It handles job execution requests from the Server Core, but does not perform any high-level job management or scheduling. It communicates with the Server Core via an API for more complex activities, e.g. to request execution of other jobs, check file permissions, etc.
Worker is started by the Server Core as a standalone JVM process. The default configuration of Worker can be changed in the Setup:
The settings are stored in the usual Server configuration file. Worker is configured via special configuration properties.
A full command line of Worker is available in the Monitoring section.
Cluster should use a single portRange:
all nodes should have identical value of
That is the preferred configuration, although different ranges for individual nodes are possible.
The Server manages the runtime of Worker, i.e. it is able to start, stop, restart Worker, etc. Users don’t need to manually install and start Worker.
Status of Worker and actions are available in the Monitoring Worker section.
In case of problems with Worker, see Chapter 26, Troubleshooting Worker.
By default, all jobs are executed in Worker; yet the Server Core still keeps the capability to execute jobs. It is possible to set specific jobs or whole sandboxes to run in the Server Core via the worker_execution property on the job or sandbox. It is also possible to disable Worker completely, in which case all jobs will be executed in the Server Core.
Executing jobs in the Server Core should be an exception.
To see where the job was executed, look in the run details in
Execution History - in the Executor field.
Jobs started in Worker also log a message in their log, e.g.
Job is executed on Worker:[worker0@node01:10500].
The following areas of Worker configuration affect job execution:
Graphs running in Worker cannot use JNDI as defined in the application container of the Server Core, because Worker is a separate JVM process. Worker provides its own JNDI configuration.
The classpath is not shared between the Server Core and Worker. If you need to add a library to the Worker classpath, e.g. a JDBC driver, follow the instructions in Adding Libraries to the Worker's Classpath.