WatchDogCurrent version of Valuemation differentiates WatchDog functions on the web client and on the rich client. While WatchDog on web can monitor other nodes and start the engine on any node defined in the configuration, WatchDog on the rich client is supposed to be used by Process Engineer in the development/test phase, but it should not be used in the productive environment. WatchDog on the Web client WatchDog takes care of starting the engines with the parameter startOnLoad. To start the process engine together with the web client, uncomment the parameter load-on-startup of cxf servlet in web.xml. WatchDog will then be created during the web client startup. WatchDog parameters are specified in cxf-servlet.xml. Note: WatchDog should run ONLY on a node specified in Process engine configuration file. If there is a web client dedicated to end users, not listed in the configuration, WatchDog should be switched OFF there. To do it set theWatchDog.stepInMillis = -1 in cxf-servlet.xml WatchDog running on a node which is NOT listed in the process engine configuration file is not being informed about user actions requesting to STOP the engine in the process engine console. It would try to start the engine immediately after recognizing that the engine is no longer running, breaking thus the users request to STOP the engine. cxf-servlet.xml: theWatchDog
userName and cryptedPassword WatchDog needs a valid user account to run. Credentials are specified by parameters userName and cryptedPassword.
User PEWATCHDOG has a role -Bpm.Engine.WatchDog which has a minimal permission All | Default | No Read/No Execute. stepsInMillis Parameter stepsInMillis specifies the interval between checks whether the engines are still running. Recommended value is > 180000 ms (3 minutes).
delayStartInMillis Parameter delayStartInMillis specifies a delay in which WatchDog performs the first check and thus starts the engines according to the configuration. Delay allows other nodes in cluster to start and thus to start engines on preferred nodes. Recommended value is > 30000 ms (30 sec). logSteps When parameter logSteps = true, detailed information about performed steps are written into stdout. Example:
timeoutToMailProblemAgainInMinutes Parameter timeoutToMailProblemAgainInMinutes specifies an interval after which WatchDog can send a notification email about problem, having the same subject. Recommended value is 30 min.
Controllers A list of controllers specifies implementing endpoints available on a node. By default each node provides endpoints theProcessInterpreterEndpoint, taskExecutorEndpointA, taskExecutorEndpointB, which allow to start the Process Interpreter and 2 Task Executors on a node at a time. WatchDog is created after all controllers are created. When a server is being shut down, WatchDog stops all controllers at first and then stops itself. Next chapter describes how to add a new endpoint for Task Executor. When a new endpoint and corresponding controller are defined, the new controller should be listed in the list of controllers to be managed by the WatchDog. cxf-servlet.xml: taskExecutorControllerC To enable to run additional Task Executors on a node, a new endpoint with the corresponding controller have to be defined in cxf-servlet.xml.
WatchDog on rich client WatchDog on rich client periodically checks whether the process engine is still running after it was started. In a contrary to the web client, it does not start engine(s). Engines are started by the rich client, provided the corresponding java system properties ProcessInterpreter.*, TaskExecutor.* are defined. See example below. The following Java system properties are used to configure the WatchDog:
07/26 10:25:22.261 FINEST: main | PE-WatchDog is created Example: modify set_env.bat and admin.bat to define java system properties below. -DPEWatchDog.stepInMillis=15000 -DProcessInterpreter.enabled=true | |||||