Task Manager is configured using the <taskManager> section of the midPoint configuration.
A simple example:
(Actually, this is the default configuration that will be applied if you would not create this section at all.)
An example of more complex, and clustered, configuration:
Most frequently used configuration items are:
|threads||Number of threads that will be available for running tasks on this node.||10|
|clustered||Whether this node is part of a cluster. If set to true, it implies the use of the JDBC job store.|
|jdbcJobStore||Whether JDBC job store should be used. See the discussion below.|
For more information how to setup task manager for a cluster, please see this wiki article.
JDBC scheduler job store
MidPoint uses Quartz Scheduler to schedule its tasks. Quartz can use either persistent (JDBC) or temporary (in-memory) store for managing information about tasks, or jobs in Quartz speak.
By default, in-memory job store is used. This is usually sufficient, because almost all scheduling information can be retrieved from midPoint repository. The only exception is information on planned task start times.
Therefore, if you use in-memory job store, the configuration will be a little bit simpler, but, after restart of midPoint, some tasks would perhaps execute one more or one less time than you would expect. For simple installations, this is not a problem. If you need precise task scheduling even during midPoint restarts, use JDBC job store. Also, as already said, for clustered deployments the JDBC job store is also required.
Configuration parameters related to JDBC job store:
|jdbcDriver||JDBC driver to use for the connection.||the value from repository configuration|
|jdbcUrl||URL used to connect to the database.||the value from repository configuration|
|jdbcUser, jdbcPassword||Credentials used to connect to the database.||the value from repository configuration|
|dataSource||Alternative way of obtaining the connection.||the value from repository configuration|
|sqlSchemaFile||Database schema of the Quartz-related tables in database. Normally you do not have to change this parameter.||derived from the kind of SQL database used for repository|
|jdbcDriverDelegateClass||Helper class used by Quartz scheduler to access the database. Normally you do not have to change this parameter.||derived from the kind of SQL database used for repository|
|TODO other parameters|
A note for H2 users: For this database Quartz requires slightly different mode of access, in comparison to SQL repository: Quartz needs to have
MVCC parameter set to TRUE, while SQL repository uses
LOCK_MODE=1 instead. These settings cannot be used on one database, so when using H2 database and JDBC Quartz job store, one has to use two separate database instances - one for SQL repository and the second one for Task Manager (i.e. Quartz scheduler). When using default URL for H2 for SQL repository, midPoint will fill-in reasonable default for task manager as well. However, if you provide your own H2 database URL for the repository, do not forget to provide custom H2 URL for task manager as well, providing MVCC=TRUE. But overall, we recommend H2 only for demo and testing deployments, so usually there is no need to use JDBC job store with H2 altogether.
Less frequently used configuration items
How tasks are stopped, e.g. on node shutdown or on task suspend operation. Normally, the task is signaled to stop by setting its
|quartzClusterCheckinInterval||How often should Quartz nodes check into the Quartz cluster. Specified in milliseconds. Usually does not need to be changed. Available since midPoint 4.1.||7500|
|quartzClusterCheckinGracePeriod||After what time should other nodes consider a Quartz node to be "down". Specified in milliseconds. Increase if you experience "This scheduler instance (...) is still active but was recovered by another instance in the cluster. This may cause inconsistent behavior." messages and you are sure that clocks in your cluster are correctly synchronized. See MID-5500. Available since midPoint 4.1.||7500|
|checkForTaskConcurrentExecution||EXPERIMENTAL. An additional approximate check that task is not started at two nodes at once. (This can occur e.g. on unwanted Quartz node recovery described above.) Available since midPoint 4.1.||false|
|TODO other parameters|