Background Process Cluster Support

Contents 1 Introduction 2 Configuration 2.1 Openbravo.properties 2.2 quartz.properties 2.2.1 Common configuration 2.2.2 instance.name 2.2.3 jobStore 3 Changes in Process Monitor 4 Restricting the Cluster Instances that Can Run Each Process 4.1 Misfirings

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