Background Process Cluster Support
 | This feature is available starting from 3.0PR20Q4. |
Contents |
Introduction
Background processes can be executed in several instances of a clustered environment. This document explains how to configure this, and the features enabled by this clusterization support.
Configuration
Openbravo.properties
In single instance environments, there was no need to set any extra configuration in the Openbravo.properties, by default background processes will be executed in that instance.
In a clustered environment it was important to ensure that only one cluster instance was in charge of executing background processes. To do that, its Openbravo.properties file (or its extension file) should set the background.policy parameter to default, or not define at all. The rest of the cluster instances must set the background.policy parameter to no-execute.
Now that there is support to execute background processes in several cluster instances, there no need anymore to enforce that only one instance uses background.policy=default, that configuration can be set in all instances that are meant to execute background processes.
If for some reason there is a cluster instance that should never execute background processes, setting the background.policy to no-execute will achieve the same result as before.
quartz.properties
Common configuration
Configuration similar for both non-clustered and clustered environments:
org.quartz.scheduler.instanceId = AUTO org.quartz.scheduler.instanceIdGenerator.class = org.openbravo.scheduling.quartz.OpenbravoInstanceIdGenerator org.quartz.scheduler.rmi.export = false org.quartz.scheduler.rmi.proxy = false org.quartz.scheduler.wrapJobExecutionInUserTransaction = false org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool org.quartz.threadPool.threadCount = 10 org.quartz.threadPool.threadPriority = 5 org.quartz.threadPool.threadsInheritContextClassLoaderOfInitializingThread = true org.quartz.jobStore.misfireThreshold = 60000
Note: instanceIdGenerator will allow quartz to use the machine.name of the instance running a Background Process as identifier.
instance.name
Non-clustered environment:
org.quartz.scheduler.instanceName = DefaultQuartzScheduler
Clustered environment:
org.quartz.scheduler.instanceName = OpenbravoClusteredScheduler
jobStore
Non-clustered environment:
org.quartz.jobStore.class = org.quartz.simpl.RAMJobStore
Clustered environment:
org.quartz.jobStore.class = org.openbravo.scheduling.quartz.OpenbravoPersistentJobStore
org.quartz.jobStore.driverDelegateClass = org.openbravo.scheduling.quartz.OpenbravoDriverDelegate
org.quartz.jobStore.useProperties = false
org.quartz.jobStore.dataSource = quartzDS
org.quartz.jobStore.tablePrefix = OBSCHED_
org.quartz.jobStore.isClustered = true
org.quartz.jobStore.acquireTriggersWithinLock = true
org.quartz.jobStore.clusterCheckinInterval = 10000
org.quartz.dataSource.quartzDS.connectionProvider.class = org.openbravo.scheduling.quartz.QuartzConnectionProvider
Changes in Process Monitor
Process Monitor subtab of the Process Request window now shows the name of the instance where a background process was run.
Restricting the Cluster Instances that Can Run Each Process
By default, a background process will be executed in any of the cluster instances whose background.policy property is not no-execute.
If for some reason there are restrictions on the cluster instances when a specific background process must be executed, this can be configured in the Report and Process window. There are two configuration options:
- Allow execution in any instance of the cluster. (default) To do that, remove all records from Cluster Instance subtab.
- Allow execution only in specific cluster instances. To do that, add to the Cluster Instance subtab all the cluster instances allowed to execute the background process.
The default configuration of all existing process is "All instances of the cluster", with no records in cluster instance subtab. As a result of this by default all processes are allowed to be executed in any cluster instance.
Misfirings
If for some reason none of the instances allowed to execute a backgroud process are available when the process needs to be executed, then a misfiring will occur. In that case a new misfire entry will be created in the Process Monitor subtab of the Process Request window