Properties
Anchor |
propertiesproperties | Info |
---|
Quartz is configured using a set of properties that are available for the Runtime. Quartz uses a job store in order to persist jobs details, triggers and other job related information. All quartz related properties are stored in application-scheduler-quartz.properties in spring.config.additional-location.
Read best practices to know every insight on how to use these properties. For more information visit Quartz |
Properties
Info |
In this section can find a list of properties which we use to set up a job store for quartz. These properties should be placed in the application-scheduler-quartz.properties file in spring.config.location.
UI Expand |
---|
|
JobStore Properties |
---|
Quartz Property Key | Example Value | Default Value | Description |
---|
JobStore Properties |
---|
Quartz Property Key | Example Value | Default Value | Description |
---|
spring.quartz.job-store-type | jdbc | memory | The type of job store to be used by quartz. Do not use memory in production environments as there is no way to save quartz jobs during downtime. The preferred way is to use Direct or JNDI Connection. To configure a Direct or JNDI Connection please visit Quartz Scheduler Configuration. |
spring.quartz.properties.org.quartz.jobStore. | classorg.quartz.simpl.RAMJobStore | org.quartz.simpl.RAMJobStore | The name of the job store you whish to use. RamJobStore is the default in-memory configuration. Do not use RAMJobStore in production environments as there is no way to save quartz jobs during downtime. tablePrefix | QRTZ_ | QRTZ_ | The table prefix you used for quartz tables in your database. In case of an in-memory connection, this property is not required. | spring.quartz.properties.org.quartz.jobStore.dataSource | NAME | null | Represents the name of your datasource. It can be any string, but be sure you will use the same value for your datasource properties described in the next section | The preferred way is to use Direct or JNDI Connection.To configure a Direct or JNDI Connection please visit Quartz Scheduler Configuration. | spring.quartz.properties.org.quartz.jobStore. | tablePrefixQRTZ_QRTZ_ | The table prefix you used for quartz tables in your database. In case of an in-memory connection, this property is not required. | 60000 | The number of milliseconds the scheduler will tolerate a trigger to pass its next-fire-time by, before being considered misfired. In case you do not specify this property, 60 sec is considered as misfire. | Datasource Properties in external datasources
|
---|
blueriq.datasource.scheduler-quartz.driverclassname | com.microsoft.sqlserver.jdbc.SQLServerDriver | null | Java class name of JDBC driver for your database connection.
To configure other types of datasources, visit Quartz Scheduler Configuration . | blueriq.datasource.scheduler-quartz.url | jdbc:sqlserver://[host]:[port];databaseName=[dbname];instance=SQLEXPRESS | null | Url Connection to your database. | blueriq.datasource.scheduler-quartz.username | test | "" | Username which is used for connecting to the database. | blueriq.datasource.scheduler-quartz.password | test | "" | Password which is used for connecting to the database. | Thread Pool |
---|
spring.quartz.properties.org.quartz.jobStore.dataSource | NAME | null | Represents the name of your datasource. It can be any string, but be sure you will use the same value for your datasource properties described in the next section. | spring.quartz.properties.org.quartz.jobStore.misfireThreshold | 60000 | 60000 | The the number of milliseconds the scheduler will tolerate a trigger to pass its next-fire-time by, before being considered misfired. In case you do not specify this property, 60 sec is considered as misfire. | Datasource Properties |
---|
spring.quartz.properties.org.quartz. | dataSourceNAME.driver commicrosoftsqlserverjdbc.SQLServerDriverJava class name of JDBC driver for your database connection.To configure other types of datasources, visit Quartz Scheduler Configuration The name of thread pool implementation you want to use. | spring.quartz.properties.org.quartz. | dataSourceNAME.URLjdbc:sqlserver://[host]:[port];databaseName=[dbname];instance=SQLEXPRESS | null | threadCount | 30 | -1 | Represents the number of threads that are available for concurrent execution of jobs. | Clustered Environment Properties |
---|
Url Connection to your database. |
---|
spring.quartz.properties.org.quartz. | dataSourceNAME.user test"" | Username which is used for connecting to the database. | spring.quartz.properties.org.quartz. | dataSourceNAME.password test"" | Password which is used for connecting to the database. | 15000 | Represents the number of threads that are available for concurrent execution of jobs. | Quartz Scheduler |
---|
Thread Pool Properties |
---|
spring.quartz.properties.org.quartz. | threadPoolclassorg.quartz.simpl.SimpleThreadPool | null | instanceName | MyScheduler | QuartzScheduler | Name of the cluster. Must be the same for all nodes in the cluster | The name of thread pool implementation you want to use.
| spring.quartz.properties.org.quartz. | threadPoolthreadCount30 | -1 | Represents the number of threads that are available for concurrent execution of jobs. | AUTO | NON_CLUSTERED | Instance id of the quartz node. Each node in the cluster must use a unique instanceId. (This is done by setting AUTO) | Clustered Environment Properties | spring.quartz.properties.org.quartz. | jobStoreisClusteredEnables clustering. | spring.quartz.properties.org.quartz.jobStore.clusterCheckinInterval | 90000 | 15000 | Represents the number of threads that are available for concurrent execution of jobs. | Quartz Scheduler Properties |
---|
spring.quartz.properties.org.quartz.scheduler.instanceName | MyScheduler | QuartzScheduler | Name of the cluster. Must be the same for all nodes in the cluster.spring.quartz.properties.org.quartz.scheduler.instanceId | AUTO | NON_CLUSTERED | Instance id of the quartz node. Each node in the cluster must use a unique instanceId. (This is done by setting AUTO) | spring.quartz.properties.org.quartz.scheduler.skipUpdateCheck | true | false | If this is true skips running a request which checks if there is an updatd version of Quartz available. It is recommended to be true for production environment so Quartz updates do not interfere with the application. | |
Examples
In memory Anchor |
---|
InMemory | If this is true, quartz skips running a request which checks if there is an updated version of Quartz available. It is recommended to be true for production environment so Quartz updates do not interfere with the application. |
|
Installation
Steps:
- Add scheduler-quartz to the list of spring active profiles in the bootstrap.properties (this profile is active when using the installer). More information on how to configure the application using Spring Profiles can be found here: External application configuration with Spring Profiles.
- Add the application-scheduler-quartz.properties file in the configuration location. This properties file is added in the
Include Page |
---|
| _ConfigLocation |
---|
| _ConfigLocation |
---|
|
when using the installer. Otherwise, please create this according to the documentation below. - Run the provided scripts for creating the quartz tables in the database: msssql.sql or oracle.sql. The scripts are located in the release zip in \Runtime\Java\Webapp\DBScripts\blueriq-component-scheduler-quartz
- Define quartz database connection in the application-externaldatasources.properties file.
Info |
---|
Steps 3 and 4 are applicable only if a job store database connection is chosen instead of in memory job store. |
Configuration
Info |
---|
Every Quartz configuration property has to be specified in application-scheduler-quartz.properties for Runtime. |
In order to tune resources for job execution we provided a few details about the Thread Pool.
Quartz is configured using a set of properties. Quartz uses a job store in order to persist jobs details, triggers and other job related information. We support two types of job stores:
Memory (default)
Info |
---|
|
This is the default configuration for java environments. For more details about in memory job store configuration please visit Config RAM Job Store. |
By default memory mode is enabled which should not be used unless for demo's and standalone development. For recommended settings please check the database settings. For memory the following setting should appear in the application-scheduler-quartz.properties.
InMemory | Info |
---|
|
This is the default configuration for java environments. For more details about in memory job store configuration please visit Config RAM Job Store. |
By default memory mode is enabled. The following setting should appear in the application-scheduler-quartz.properties.
Code Block |
---|
title | application-scheduler-quartz.properties |
---|
|
spring.quartz.job-store-type=memory |
If you want to use jdbc mode you must specify in the application-scheduler-quartz.properties:
Code Block |
---|
title | application-scheduler-quartz.properties |
---|
|
spring.quartz.job-store-type=jdbcmemory |
Direct
Database
connection Anchor |
---|
DatabaseConnection | Scripts to create the required database content are provided for the following databases:
- SQL Server
- Oracle
- PostgreSQL
There are two types of connection that are supported:
Generate the Quartz Database
Warning |
---|
Generate the quartz database with respect to the database used (either oracle, mssql or postgresql). In the blueriq deliverable there is a scheduler-quartz-component that contains sql scripts. Use the favorite database viewer to run those scripts against the database server. - Connect to the database server with the favorite viewer.
- Create a new database dedicated to quartz - pick a meaningful name for this, e.g. 'QuartzScheduler'.
- Depending on the database viewer used, one must make sure that the new database created is selected and set by default in the editor.
- Import the mssql.sql (for mssql server) or oracle.sql (for oracle server) and run it in the editor. If the run was successful new tables should be present under the newly created database.
|
JDBC Connection
To enable the JDBC Connection the externaldatasources profile must enabled and the following properties have to be used:
Code Block |
---|
language | powershell |
---|
title | application-scheduler-quartz.properties |
---|
|
spring.quartz.job-store-type=jdbc
spring.quartz.properties.org.quartz.jobStore.class=org.quartz.impl.jdbcjobstore.JobStoreTX
spring.quartz.properties.org.quartz.jobStore.tablePrefix=QRTZ_
# This example we use MSSQL, please check the online quartz documentation which driverDelegateClass to use
spring.quartz.properties.org.quartz.jobStore.driverDelegateClass=org.quartz.impl.jdbcjobstore.MSSQLDelegate
#spring.quartz.properties.org.quartz.jobStore.driverDelegateClass=org.quartz.impl.jdbcjobstore.oracle.OracleDelegate
|
Code Block |
---|
language | powershell |
---|
title | application-externaldatasources.properties - mssql |
---|
|
blueriq.datasource.scheduler-quartz.driverClassName=com.microsoft.sqlserver.jdbc.SQLServerDriver
blueriq.dataSource.scheduler-quartz.url=jdbc:sqlserver://<server_url>:<port>;databaseName=<database_name>;instance=<instance_name>
blueriq.datasource.scheduler-quartz.username=<user>
blueriq.datasource.scheduler-quartz.password=<password>
spring.quartz.properties.org.quartz.jobStore.dataSource=schedulerBlueriqQuartzDataSource
spring.quartz.properties.org.quartz.dataSource.schedulerBlueriqQuartzDataSource.driver=com.microsoft.sqlserver.jdbc.SQLServerDriver
spring.quartz.properties.org.quartz.dataSource.schedulerBlueriqQuartzDataSource.URL=jdbc:sqlserver://<server_url>:<port>;databaseName=<database_name>;instance=<instance_name>
spring.quartz.properties.org.quartz.dataSource.schedulerBlueriqQuartzDataSource.user=<user>
spring.quartz.properties.org.quartz.dataSource.schedulerBlueriqQuartzDataSource.password=<password>
|
Code Block |
---|
language | powershell |
---|
title | application-externaldatasources.properties - oracle |
---|
|
blueriq.datasource.scheduler-quartz.driverClassName=oracle.jdbc.driver.OracleDriver
blueriq.dataSource.scheduler-quartz.url=jdbc:oracle:thin:@<server_url>:<port>:<SID>
blueriq.datasource.scheduler-quartz.username=<user>
blueriq.datasource.scheduler-quartz.password=<password> |
DatabaseConnection | Info |
---|
|
If you want to use jdbc for quartz externaldatasources profile must be enabled.
The database connection for quartz is defined in application-externaldatasources.properties file in spring.config.location. Jdbc settings can be used only if the externaldatasources profile is enabled too.
For more details about direct database connection visit JobStoreTX. You can find there a list of supported database types. In this sections we present an example of quartz.properties/Web.config files for MsSql and Oracle database connections.
|
MSSQL Anchor |
---|
MsSql | MsSql | Code Block |
---|
title | application-externaldatasources.properties - mssql |
---|
|
blueriq.datasource.scheduler-quartz.url=com.microsoft.sqlserver.jdbc.SQLServerDriver
org.quartz.dataSource.<datasource_name>.URL=jdbc:sqlserver://<server_url>:<port>;databaseName=<database_name>;instance=SQL_EXPRESS
blueriq.datasource.scheduler-quartz.user=<user>
blueriq.datasource.scheduler-quartz.password=<password>
|
Oracle Anchor |
---|
Oracle | Oracle | Code Block |
---|
title | application-externaldatasources.properties - mssql |
---|
|
blueriq.datasource.scheduler-quartz.url=oracle.jdbc.driver.OracleDriver
org.quartz.dataSource.<datasource_name>.URL=jdbc:oracle:thin:@<server_url>:<port>:xe
blueriq.datasource.scheduler-quartz.user=<user>
blueriq.datasource.scheduler-quartz.password=<password>
|
JNDI connection Anchor |
---|
JNDI | JNDI | Info |
---|
|
For more details about JNDI connection visit JobStoreCMT. |
Code Block |
---|
title | quartz.properties - jndi |
---|
|
org.quartz.threadPool.class=org.quartz.simpl.SimpleThreadPool
org.quartz.threadPool.threadCount=2
org.quartz.jobStore.class=org.quartz.impl.jdbcjobstore.JobStoreCMT
org.quartz.jobStore.tablePrefix=QRTZ_
org.quartz.jobStore.dataSource=quartz
org.quartz.jobStore.nonManagedTXDataSource=quartz
// JBoss Example provided that the jndi name is set to java:jboss/jdbc/quartzdb
org.quartz.dataSource.quartz.jndiURL=java:jboss/jdbc/quartzdb
// Tomcat Example provided that the jndi name is set to jdbc/quartzdb
org.quartz.dataSource.quartz.jndiURL=java:/comp/env/jdbc/quartzdb |
Cluster Anchor |
---|
clusterProperties | clusterProperties | Info |
---|
|
Clustered environment can be configured only for JDBC JobStore (JobStoreTX and JobStoreCMT). For more information about clustered setup read Configuring Clustered Environment. |
Code Block |
---|
title | applcation-scheduler-quartz.properties - cluster |
---|
|
spring.quartz.properties.org.quartz.threadPool.class=org.quartz.simpl.SimpleThreadPool
spring.quartz.properties.org.quartz.threadPool.threadCount=2
spring.quartz.properties.org.quartz.jobStore.class=org.quartz.impl.jdbcjobstore.JobStoreTXdataSource=schedulerBlueriqQuartzDataSource
spring.quartz.properties.org.quartz.dataSource.jobStoreschedulerBlueriqQuartzDataSource.tablePrefix=QRTZ_
driver=oracle.jdbc.OracleDriver
spring.quartz.properties.org.quartz.dataSource.jobStoreschedulerBlueriqQuartzDataSource.isClustered = trueURL=jdbc:oracle:thin:@<server_url>:<port>:<SID>
spring.quartz.properties.org.quartz.jobStore.clusterCheckinInterval = 90000dataSource.schedulerBlueriqQuartzDataSource.user=<user>
spring.quartz.properties.org.quartz.dataSource.schedulerschedulerBlueriqQuartzDataSource.instanceName password= MyClusteredScheduler
spring.quartz.properties.org.quartz.scheduler.instanceId = AUTO
spring.quartz.properties.org.quartz.scheduler.skipUpdateCheck = true
|
JobStoreTX allows Quartz managing quartz related transactions.
JDBCJobStore’s “table prefix” property is a string equal to the prefix given to Quartz’s tables that were created in your database. You can have multiple sets of Quartz’s tables within the same database if they use different table prefixes.
Info |
---|
When changing the org.quartz.jobStore.tablePrefix, please change the create scripts accordingly. |
Info |
---|
For more information and properties related to the connection JobStoreTX please visit JDBC-JobStoreTX. |
JNDI Connection
To enable JNDI Connection jndidatasources profile must be activated and the following properties have to be used:
Scheduler Properties Anchor |
---|
SchedulerProperties | SchedulerProperties | Info |
---|
In this section can find a list of scheduler related properties. These should be placed in a file named | application-scheduler-quartz.properties |
|
in spring. config.location. These properties are needed to enable or personalize scheduler functionalities from blueriq runtime perspective. |
UI Expand |
---|
|
Blueriq Property Key | Default Value | Description |
---|
blueriq.scheduler-quartz.enable-task-migration | false | Used to enable quartz migration.
For more information about the migration API visit Migration API, for details about this property visit Migration.blueriq.scheduler-quartz.retryInterval | 30 | Represents a number used for jobs retry mechanism in case of misfire.
For more information about this property visit Retry Interval.blueriq.scheduler-quartz.handleModelChanges | false | Used to enable updates on tasks and jobs when model changes. For more information about this property visit Handle Model Changes. |
Examples
Default configuration file: Anchor |
---|
SchedulerProperties | SchedulerProperties | Code Block |
---|
title | application-scheduler-quartz.properties |
---|
|
blueriq.scheduler-quartz.enable-task-migration=false
blueriq.scheduler-quartz.retryInterval=30 |
Generate the Quartz Database Anchor |
---|
SetupJava | SetupJava | Warning |
---|
Generate the quartz database with respect to the database used (either oracle or mssql). In the blueriq deliverable there is a scheduler-quartz-component that contains sql scripts. Use the favourite database viewer to run those scripts against the database server. - Connect to the database server with the favorite viewer.
- Create a new database dedicated to quartz - pick a meaningful name for this, e.g. 'QuartzScheduler'.
- Depending on the database viewer used, one must make sure that the new database created is selected and set by default in the editor.
- Import the mssql.sql (for mssql server) or oracle.sql (for oracle server) and run it in the editor. If the run was successful new tables should be present under the new created database.
|
Setup Quartz Anchor |
---|
SetupJava | SetupJava | Using spring cloud config Anchor |
---|
Cloud | Cloud | Actions
- Place your scheduler properties in application-scheduler-quartz.properties (Check here for example) in the searchLocations you specified for spring cloud.
- Place your quartz.properties file in the same folder with one of the following configurations: In-Memory Configuration, Direct Connection([Editor]Scheduler Configuration, Oracle, or other), JNDI Connection. If you do not provide this file the default configuration will be used, the in-memory configuration.
Not using spring config location Anchor |
---|
NoSpringConfig | NoSpringConfig | Default quartz properties will be used because quartz.properties file is not present. The default setup is in-memory configuration.
Scheduler properties can be personalized via JVM arguments:
Code Block |
---|
|
-Dblueriq.scheduler-quartz.enable-task-migration=false
-Dblueriq.scheduler-quartz.retryInterval=30 |
If no property is defined, the default ones will be used.
Using spring config location Anchor |
---|
SpringConfig | SpringConfig | Info |
---|
Configure a spring.config.location for your application. For more details about how to do this visit Installing Runtime. |
Without quartz.properties
Actions
- Place your scheduler properties in application-scheduler-quartz.properties (Check here for example) in spring.config.location folder.
- Since quartz.properties is not present in this folder, the default in-memory configuration will be used.
With quartz.properties
In spring.config.location folder place the two files used by the quartz scheduler:
Using existing scheduled tasks Anchor |
---|
setupWithSchedule | setupWithSchedule | In order for the already scheduled tasks to be executed in time, you need to do a migration to the scheduler.
Before running the migration you need to create the following files and place them in your spring.config.location folder:
Create a quartz.properties file with one of the following configurations: Direct Connection([Editor]Scheduler Configuration, Oracle), JNDI Connection.We advise you not to use an In-Memory Configuration or leave the default one for this purpose.Create application-scheduler-quartz.properties file, set blueriq.scheduler-quartz.enable-task-scheduler and blueriq.scheduler-quartz.enable-task-migration to true (Check here for example). Info |
---|
|
For more information regarding migration preconditions read Migration API Preconditions.
We exposed four endpoints to migrate timer, expiration, priority and pending automatic tasks to quartz scheduler. In order to use them follow the steps described in Scheduler Migration API.Setup quartz in cluster Anchor |
---|
cluster | cluster | The quartz evaluation of time dependent task (timer nodes, priority algorithms, expiration tasks etc.) is done per Process Engine per Project installed on the Runtime. A quartz job is created for every single project in the cluster. The number of jobs in Quartz is dependent on the number of projects in a cluster and not the number of runtimes.
This means that in every interval, for each loaded project, a Runtime instance in the cluster will evaluate time dependent tasks. The Runtime instances are selected for execution almost randomly, more busy servers have a lower chance to be selected for the execution.The main advantage for this is that: One Runtime server can run time dependent tasks for a project and another server can run other project in the same time.
The quartz job is created in the cluster when the project is started. This means whenever a project is published in a Runtime, that Runtime will try to start the job for the project if the job is not already created.
The execution of quartz jobs is being done on any Runtime in the cluster as soon as the Runtime is started. This might happen even though in that Runtime no projects are published yet.
Info |
---|
|
In order to run the Quartz Scheduler on multiple Runtime instances in a cluster, every Runtime instance has to be identical and have the same projects installed. Each instance in the cluster needs to have the same quartz.properties and application-scheduler-quartz.properties files. You may set different thread pool size on each node. To read more about quartz clustered environment visit Quartz in Cluster. |
To set up quartz in cluster create the following two files and place them in your spring config location:Create a quartz.properties file (check Quartz Properties Cluster for an example)Make sure the following were added: 1.1 Set org.quartz.jobStore.isClustered to truequartz.job-store-type=jdbc
spring.quartz.properties.org.quartz.jobStore.class=org.quartz.impl.jdbcjobstore.JobStoreCMT
spring.quartz.properties.org.quartz.jobStore.tablePrefix= QRTZ_
# This example we use MSSQL, please check the online quartz documentation which driverDelegateClass to use
spring.quartz.properties.org.quartz.jobStore.driverDelegateClass=org.quartz.impl.jdbcjobstore.MSSQLDelegate
#spring.quartz.properties.org.quartz.jobStore.driverDelegateClass=org.quartz.impl.jdbcjobstore.oracle.OracleDelegate
# quartz needs a non JDNI datasource for some parts to function
spring.quartz.properties.org.quartz.jobStore.dataSource=schedulerBlueriqQuartzDataSource
spring.quartz.properties.org.quartz.dataSource.schedulerBlueriqQuartzDataSource.driver=com.microsoft.sqlserver.jdbc.SQLServerDriver
spring.quartz.properties.org.quartz.dataSource.schedulerBlueriqQuartzDataSource.URL=jdbc:sqlserver://<server_url>:<port>;databaseName=<database_name>;instance=<instance_name>
spring.quartz.properties.org.quartz.dataSource.schedulerBlueriqQuartzDataSource.user=<user>
spring.quartz.properties.org.quartz.dataSource.schedulerBlueriqQuartzDataSource.password=<password>
|
The scheduler always uses the datasource with the name scheduler-quartz which we define inside application-jndidatasources.properties:
Code Block |
---|
language | powershell |
---|
title | application-jndidatasources.properties - jndi - tomcat |
---|
|
# Tomcat Example provided that the jndi name is set to jdbc/quartzdb
blueriq.datasource.scheduler-quartz.jndiName=java:/comp/env/jdbc/quartzdb
spring.quartz.properties.org.quartz.jobStore.dataSource=java:/comp/env/jdbc/quartzdb |
Code Block |
---|
language | powershell |
---|
title | application-jndidatasources.properties - jndi - jboss |
---|
|
# JBoss Example provided that the jndi name is set to java:jboss/jdbc/quartzdb
blueriq.datasource.scheduler-quartz.jndiName=java:jboss/jdbc/quartzdb
spring.quartz.properties.org.quartz.jobStore.dataSource=java:jboss/jdbc/quartzdb
|
JobStoreCMT relies upon transactions being managed by the application which is using Quartz.
Info |
---|
For more information and properties related to the connection JobStoreCMT please visit JDBC-JobStoreCMT. |
Thread Pool
If the Database configuration is chosen we recommend to also add the thread pool with the following default values:
Each DCM project gets it's own trigger. The process engine only allows one process engine (one project) to evaluate timers at a time. Setting the threadCount higher then 1 only will only create waiting threads, this means the best setting for threadCount is 1.
The quartz documentation suggests the following configuration: provided that the database allows X connections, then the threadCount should never be higher then X - 3.
Thread Pool properties are the following:
Code Block |
---|
language | powershell |
---|
title | application-scheduler-quartz.properties |
---|
|
spring.quartz.properties.org.quartz.threadPool.class = org.quartz.simpl.SimpleThreadPool
spring.quartz.properties.org.quartz.threadPool.threadCount = 1 |
Cluster
Info |
---|
|
Clustered environment can be configured only for JDBC JobStore (JobStoreTX and JobStoreCMT). For more information about clustered setup read Configuring Clustered Environment. |
In order to run the Quartz Scheduler on multiple Runtime instances in a cluster, every Runtime instance has to be identical and have the same projects installed.
Each instance in the cluster needs to have the same application-scheduler-quartz.properties files. You may set different thread pool size on each node.
To read more about quartz clustered environment visit Quartz in Cluster.
To set up quartz in cluster create the following two files and place them in your spring config additional location:
- Create a application-scheduler-quartz.properties file (check Quartz Properties Cluster for an example)
Make sure the following were added:- Set spring.quartz.properties.org.quartz.jobStore.isClustered to true
- Set spring.quartz.properties.org.quartz.scheduler.instanceId to AUTO, or a different id for each instance node.
- (optional) When instanceid is set to AUTO it generates a unique id after every restart, to have a stable id set spring.quartz.properties.org.quartz.scheduler.instanceIdGenerator.class to org.quartz.simpl.HostnameInstanceIdGenerator this
- Create application-scheduler-quartz.properties file
Warning |
---|
title | Do not enable this setting in clustered environment |
---|
|
When quartz is used in a clustered environment one must not set the blueriq.processengine.cancel-started-tasks=true. The property can be set in the application-scheduler-quartz.properties file and the default value is false. When a single server is restarted and the blueriq.processengine.cancel-started-tasks is set to true all opened task are reset so they can be opened again. In a multi node environment the danger is when a single node is restarted and could result in having all tasks that are in progress being reset while they are still in progress on the other server. |
Cluster properties example
Code Block |
---|
title | applcation-scheduler-quartz.properties - cluster |
---|
|
spring.quartz.properties.org.quartz.threadPool.class=org.quartz.simpl.SimpleThreadPool
spring.quartz.properties.org.quartz.threadPool.threadCount=2
spring.quartz.properties.org.quartz.jobStore.class=org.quartz.impl.jdbcjobstore.JobStoreTX
spring.quartz.properties.org.quartz.jobStore.tablePrefix=QRTZ_
spring.quartz.properties.org.quartz.jobStore.isClustered=true
spring.quartz.properties.org.quartz.jobStore.clusterCheckinInterval=90000
spring.quartz.properties.org.quartz.scheduler.instanceName=MyClusteredScheduler
spring.quartz.properties.org.quartz.scheduler.instanceId=AUTO
spring.quartz.properties.org.quartz.scheduler.skipUpdateCheck=true
|
Scheduler Maintenance Properties
Info |
---|
In this section you can find a list of scheduler related properties. These should be placed in a file named application-scheduler-quartz.properties in spring.config.additional-location. These properties are needed to enable or personalize scheduler functionalities from blueriq runtime perspective. |
UI Expand |
---|
|
Blueriq Property Key | Default Value | Description |
---|
blueriq.scheduler-quartz.retryInterval | 30 | Represents a number in minutes, which is used for jobs retry mechanism in case of misfire.
For more information about this property visit Retry Interval. |
|
Examples
Default configuration file:
Code Block |
---|
title | application-scheduler-quartz.properties |
---|
|
blueriq.scheduler-quartz.enable-task-migration=false
blueriq.scheduler-quartz.retryInterval=30 |
Retry Interval
If the case is locked when a timer job or expiring job is fired a new quartz job will be scheduled. The reschedule interval for this job can be configured in minutes, with a property in application-scheduler-quartz.properties file. The default value is 30 minutes.
Code Block |
---|
title | application-scheduler-quartz.properties |
---|
|
blueriq.scheduler-quartz.retryInterval=30 |
Setup Quartz
Various spring configurations
Using spring cloud config
Actions
- Place your scheduler properties in application-scheduler-quartz.properties (Check here for example) in the searchLocations you specified for spring cloud.
- Place application-externaldatasources.properties or application-jndidasarouces.properties files in the searchLocations you specified for spring cloud.
Not using spring config additional location
Default quartz properties will be used because application-scheduler-quartz.properties file is not present. The default setup is in-memory configuration.
Scheduler properties can be personalized via JVM arguments:
Code Block |
---|
|
-Dblueriq.scheduler-quartz.enable-task-migration=false
-Dblueriq.scheduler-quartz.retryInterval=30 |
If no property is defined, the default ones will be used.
Using spring config additional location
Info |
---|
Configure a spring.config.additional-location for your application. For more details about how to do this visit Installing Runtime. |
- In spring.config.additional-location folder place the application-scheduler-quartz.properties (Check here for example) file.
- In spring.config.additional-location folder place the application-externaldatasources.properties or application-jndidasarouces.properties files
Using existing scheduled tasks
In order for the already scheduled tasks to be executed in time, you need to do a migration to the scheduler.
Before running the migration you need to create the following files and place them in your spring.config.additional-location folder:
- Create a application-scheduler-quartz.properties file with one of the following configurations: Direct Connection(MsSql, Oracle), JNDI Connection.
We advise you not to use an In-Memory Configuration or leave the default one for this purpose. - In the application-scheduler-quartz.properties file, set blueriq.scheduler-quartz.enable-task-scheduler and blueriq.scheduler-quartz.enable-task-migration to true (Check here for example).
Setup quartz in cluster
Overview
Basic Scheduler
The quartz evaluation of time dependent tasks (timer nodes, tasks with priority algorithms, expiration tasks, automatic recovery tasks) is done per Process Engine per Project installed on the Runtime. A quartz job is created for every single project which uses a process engine in the cluster. The number of jobs in Quartz equals with the number of initialized projects from the cluster which are using a process engine. The number of jobs in quartz does not depend on the number of runtime instances available in the cluster.
An interval is defined in the application.properties file which marks the triggering and execution of the job. If the interval is MINUTE, the quartz job will be triggered and executed every minute. The execution consists in finding and evaluating all the timer tasks, expiration tasks, tasks with priority which should fire in that period.
The Runtime instances are selected for execution almost randomly, more busy servers have a lower chance to be selected for the execution.The main advantage for this is that: As multiple runtime instances are available in cluster, the execution of the jobs might be done in parallel.
The quartz job is created in the cluster when the project which uses a process engine is initialized. This means whenever a project is published and the process engine is initialized in a Runtime, that Runtime will try to start the job for the project if the job is not already created.
The execution of quartz jobs is being done on any Runtime in the cluster as soon as the Runtime is started. This might happen even though in that Runtime no projects are published yet.
Anchor |
---|
| Troubleshooting |
---|
| Troubleshooting |
---|
|
Troubleshooting Warning |
---|
|
There might be a side scenario in which one runtime in a cluster does not have all the projects available but it is started. In this case, Quartz might trigger a job on that server without having a project to run on. If this happens the job for that project is deleted and won't trigger until the project is loaded - this usually means that there is a configuration problem in the cluster. Loading/publishing a project in a Runtime will trigger the creation of the job in the cluster if the job doesn't already exist. If you're uncertain that a job is running or not, you can check the logs. Starting or deleting a job is always logged. Besides this you can check the quartz database. In the table QRTZ_JOB_DETAILS there should be a column JOB_NAME. That field should contain the project and process engine name for which that job was created. It is very recommended that no changes to be done in quartz tables and you let only Quartz manage the data there. |
Info |
---|
title | Atomikos transaction log |
---|
|
If you want to run multiple runtimes on one machine, Atomikos tends to fail to access it's transaction log. This will result in a runtime that doesn't start. To fix this problem, add a VM argument to one of your runtimes to set the folder of the Atomikos transaction log files to something other than the default (which is '${user.home} ').
Code Block |
---|
-Dcom.atomikos.icatch.log_base_dir=C:/tmlogs/tmlog-development/ |
For more information please refer to the Atomikos documentation |
1.2 Set org.quartz.scheduler.instanceId to AUTO, or a different if for each instance node.Create application-scheduler-quartz.properties file (Check here for example) Warning |
---|
title | Do not enable this setting in clustered environment |
---|
|
When quartz is used in a clustered environment one must not set the blueriq.processengine.cancel-started-tasks=true. The property can be set in the application-scheduler-quartz.properties file and the default value is false. When a single server is restarted and the blueriq.processengine.cancel-started-tasks is set to true all opened task are reset so they can be opened again. In a multi node environment the danger is when a single node is restarted and could result in having all tasks that are in progress being reset while they are still in progress on the other server. |
Info |
---|
|
For more information regarding migration preconditions read Migration API Preconditions.
We exposed four endpoints to migrate timer, expiration, priority and pending automatic tasks to quartz scheduler. In order to use them follow the steps described in Scheduler Migration API.Troubleshooting
Warning |
---|
|
There might be a side scenario in which one runtime in a cluster does not have all the projects available but it is started. In this case, Quartz might trigger a job on that server without having a project to run on. If this happens the job for that project is deleted and won't trigger until the project is loaded - this usualy means that there is a configuration problem in the cluster. Loading/publishing a project in a Runtime will trigger the creation of the job in the cluster if the job doesn't already exist. If you're uncertain that a job is running or not, you can check the logs. Starting or deleting a job is always logged. Besides this you can check the quartz database. In the table QRTZ_JOB_DETAILS there should be a column JOB_NAME. That field should contain the project and process engine name for which that job was created. It is very recommended that no changes are done in quartz tables and you let only Quartz manage the data there.https://www.atomikos.com/Documentation/JtaProperties#Transaction_logs
|