Worker Processes (org.z2env.worker)¶
A worker process component, when prepared starts a new z2 Java process that keeps running until invalidated or some configured Runnable or Main class completes.
See also JAVADOC IWorkerProcess
The point in using worker process components is that this allows you to configure process configuration such as heap size via a component declaration in a central repository rather than using some scripting rules. Also, when using worker processes, the home process can be used to make sure actual application processes get restarted, in case of process crashes. Finally, in nontrivial and distributed scenarios, where a number of different node types are required, starting any combination of those from a single home process makes scale out configuration simple and robust.
A worker process component is declared by specifying some process configuration and some target states, e.g. like this:
org.z2env.component.type=org.z2env.worker
worker.process.vmOptions=-Xmx1024M
worker.states=mymodule/workerUp
or like this, in case the component mymodule/main is a main component or supplies a Runnable.
org.z2env.component.type=org.z2env.worker
worker.process.vmOptions=-Xmx1024M
worker.states=mymodule/workerUp
worker.main=mymodule/main
Some Details¶
Some noteworthy facts:
- The command line for a worker process is computed by using the VM options defined in the worker process configuration, possibly adding debug configuration, and by copying all command line system properties found for the home process. That is: Command line system properties (some -D<name>=<value> params) will be passed on to worker processes.
- In general the worker.debug=true setting may be set in order to turn on remote debugging. This will only be effective, if the home process was started in debug mode.
- Worker processes may be detached. This means that a worker process is marked as obsolete but may still be kept running until all work has completed. This is the underpinning of the Gateway feature that allows to keep web applications running in update situations until all sessions have completed. New worker process instances may be started already. In order to avoid port conflicts (in JMX and debug), the port settings are base numbers that will be increased with every new generation of worker process.
Properties¶
| name | values |
|---|---|
| org.z2env.component.type | org.z2env.worker |
| worker.process.vmOptions | General virtual machine parameters for the worker process. See for example http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html for a general overview. |
| worker.mainComponent | Main component of the worker process. If specified this component will be invoked after loading the target states. The component is either a Main class with a main method (that is, it supports a java.lang.Class lookup) or a {@link Runnable} (lookup as {@link Runnable} that is). |
| worker.states | Comma-separated list of target states (or dependency components) of the worker process (see above). The worker process will try to attain these target states (or prepare these dependency components) and will try so again during each verification and synchronization. |
| worker.process.timeouts.start | Timeout in milliseconds. This time out determines when the worker process implementation will forcibly kill the worker process if it has not reported startup completion until then. |
| worker.process.timeouts.termination | Timeout in milliseconds. This time out determines when the worker process implementation will forcibly kill the worker process if it has not terminated after this timeout has passed since it was asked to terminate. |
| worker.process.timeouts.communication | Timeout in milliseconds. This time out is the default timeout that determines the time passed after which the worker process implementation will forcibly kill a worker process if a message request has not returned. |
| worker.concurrency | Size of application thread pool (see {@link ApplicationThreadPool}). This pool is used by z2 internals but may be used by applications as well. Ignore this, if you do not use the built-in thread pool |
| worker.debug | Debugging for the worker process will be configured if this property is set to true and the home process has debugging enabled. Otherwise the worker process will not be configured for debugging. |
| worker.debug.port | The debug port to use for this worker process, if it is configured for debugging. This port is subject to variant computation in the presence of detached worker processes. |
| worker.jmx.port | The jmx port to use for this worker process. This port is subject to variant computation in the presence of detached worker processes. |
Updated by Henning Blohm about 9 years ago · 6 revisions