Page tree
Skip to end of metadata
Go to start of metadata

Basic information

Task Manager is configured using the <taskManager> section of the midPoint configuration.
A simple example:

<taskManager>
  <threads>10</threads>
  <clustered>false</clustered>
</taskManager>

(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:

<taskManager>
  <threads>10</threads>
  <clustered>true</clustered>
  <jdbcUrl>jdbc:h2:tcp://localhost/~/midpoint-quartz;MVCC=TRUE;DB_CLOSE_ON_EXIT=FALSE</jdbcUrl>
</taskManager>

Most frequently used configuration items are:

ItemDescriptionDefault value
threadsNumber of threads that will be available for running tasks on this node.10
clusteredWhether this node is part of a cluster. If set to true, it implies the use of the JDBC job store.false
jdbcJobStoreWhether JDBC job store should be used. See the discussion below.true if clustered, false otherwise

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:

ItemDescriptionDefault value
jdbcDriverJDBC driver to use for the connection.the value from repository configuration
jdbcUrlURL used to connect to the database.the value from repository configuration
jdbcUser, jdbcPasswordCredentials used to connect to the database.the value from repository configuration
dataSourceAlternative way of obtaining the connection.the value from repository configuration
sqlSchemaFileDatabase 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
jdbcDriverDelegateClassHelper 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

 ItemDescriptionDefault value
useThreadInterrupt

How tasks are stopped, e.g. on node shutdown or on task suspend operation. Normally, the task is signaled to stop by setting its canRun flag to false. Task handler should periodically check this flag and act accordingly. However, there may be situations when Thread.interrupt() has to be used, for example when a long Thread.sleep() is invoked. But the interrupt() call may be dangerous in some cases, as - for example - for some database drivers it may cause the current database operation to be cancelled. As a solution, midPoint provides the following options on use of interrupt() call:

  • never = never uses interrupt() calls
  • always = always uses interrupt() calls (along with setting canRun = true)
  • whenNecessary = first sets canRun = true, and if the task run does not finish within predefined time period (approx. 5 seconds), calls interrupt(). For implementation reasons, this mode works only for tasks running at local node; for remote tasks, if useThreadInterrupt = whenNecessary, interrupt() is never called.
whenNecessary
TODO other parameters  
  • No labels