Configure the Runtime Built-in Scheduler

The scheduler built in the runtime stores all the schedules into a database.

The schedules database is by default an H2 database built in the runtime, which provides a ready-to-use configuration. You can alternately store the schedules in a dedicated database.

Configuring Scheduler Storage

To configure the runtime schedules storage:

  1. Create in the database of your choice the necessary schema/database to host the schedules, as well as the database user to access this storage.

  2. Manually create the tables in the target database/schema using the script corresponding to your database technology. The script is in the /scripts/scheduler folder of the runtime installation directory.

  3. Copy the sample engineScheduler.properties from the /properties/samples/schedules/common directory to the /properties directory, and configure it as explained below.

  4. Restart the runtime or reinstall the runtime service.

Configure the Scheduler Datasource

In the engineScheduler.properties file, the org.quartz.jobStore.dataSource parameter defines the datasource used to store the schedules.

By default, the schedules are stored in the H2 database built in the runtime, which provides ready-to-use configuration.

For production environments, we recommend using a dedicated database storage, using for example an Oracle, Microsoft SQL Server (MSSQL), etc dedicated database. See Certified Database Servers.

#============================================================================
# Configure Main Scheduler Properties
#============================================================================

org.quartz.scheduler.instanceName = RUNTIME_H2_STD
org.quartz.scheduler.instanceId = RUNTIME_H2_STD

#============================================================================
# Configure ThreadPool
#============================================================================

org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool
org.quartz.threadPool.threadCount = 50
org.quartz.threadPool.threadPriority = 5

#============================================================================
# Configure JobStore
#============================================================================

org.quartz.jobStore.misfireThreshold = 10000

#org.quartz.jobStore.class = org.quartz.simpl.RAMJobStore

org.quartz.jobStore.class=org.quartz.impl.jdbcjobstore.JobStoreTX
org.quartz.jobStore.driverDelegateClass=org.quartz.impl.jdbcjobstore.StdJDBCDelegate
org.quartz.jobStore.useProperties=false
org.quartz.jobStore.dataSource=database01
org.quartz.jobStore.tablePrefix=STB_
org.quartz.jobStore.isClustered=false

#============================================================================
# Configure Datasources
#============================================================================

org.quartz.dataSource.database01.driver = org.h2.Driver
org.quartz.dataSource.database01.URL = jdbc:h2:file:scheduler/internalDb;SCHEMA=SCHEDULER
org.quartz.dataSource.database01.user = backend-user
org.quartz.dataSource.database01.password = backend-password
org.quartz.dataSource.database01.connectionProvider.class=com.indy.engine.scheduler.XdiQuartzConnectionProvider
org.quartz.dataSource.database01.maxConnections = 5
org.quartz.dataSource.database01.module = internal
The built-in H2 database is, by default, only accessible from the runtime itself, and is NOT recommended for production use. See Built-in H2 database.
For the Runtime to communicate with the database hosting your schedules, you must install that database’s JDBC driver and librairies in a the module that you specified for the datasource.
The org.quartz.jobStore.misfireThreshold property defines the number of milliseconds to wait after a delivery schedule gets misfired, before considering the next schedules of this delivery. For example, if a delivery schedule is misfired because another one was still running, the scheduler will wait this amount of time before considering the next schedules for this delivery.