You are viewing the documentation for Blueriq 17. Documentation for other versions is available in our documentation directory.
Properties
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.location.
Read best practices to know every insight on how to use these properties.
Quartz Properties
Examples
In memory
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.
spring.quartz.job-store-type=memory
If you want to use jdbc mode you must specify in the application-scheduler-quartz.properties:
spring.quartz.job-store-type=jdbc
Direct Database connection
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
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
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
Info
For more details about JNDI connection visit JobStoreCMT.
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
Info
Clustered environment can be configured only for JDBC JobStore (JobStoreTX and JobStoreCMT).
For more information about clustered setup read Configuring Clustered Environment.
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 Properties
These properties are needed to enable or personalize scheduler functionalities from blueriq runtime perspective.
Examples
Default configuration file:
blueriq.scheduler-quartz.enable-task-migration=false blueriq.scheduler-quartz.retryInterval=30
Generate the Quartz Database
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
Using spring cloud config
Configure the runtime in cloud. For more details about how to do this visit The runtime in the 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
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:
-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
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:
- quartz.properties with one of the following configurations: In-Memory Configuration, Direct Connection([Editor]Scheduler Configuration, Oracle, or other), JNDI Connection
and - application-scheduler-quartz.properties (Check here for example).
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.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
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 true
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)
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.