Task Manager

From the general point of view, task state is a superposition of persistence status and execution status. Additionally, each task can have a business-specific state, e.g. the live synchronization token, described below.

Some tasks in midPoint are single-run. A usual example is the initial import of accounts from a resource. This import is started by the system administrator, executes on background, and after its work is done (or a unsolvable error is encountered), it finishes. Another example is execution of an operation requiring an approval, e.g. assignment of a role to a user. After the approval is got and the operation is executed, the task finishes and is closed. Single-run tasks may start either immediately after creation (this is the majority of cases) or according to a defined schedule (this is not implemented yet); in the latter case we call them scheduled single-run tasks.

However, there are tasks that have to be repeated at defined time instants. We call such tasks recurring. Examples are live synchronization (scheduled to run e.g. every 5 seconds) or reconciliation (scheduled to run e.g. every day at 3:00am). MidPoint currently supports two styles of schedule description: interval-based and cron-like. The former says that a task should repeat every N seconds, while the latter provides the ability of specifying starting time intervals using cron expression. For more information on these expressions, please see the Quartz documentation.

By default, all persistent tasks are resilient. It means that after a node is stopped (either regularly, e.g. by shutting down the application server, or not regularly, e.g. caused by hardware malfunction), the task continues to execute on another node in a cluster, or (if no other nodes are available), after a node becoming ready.

However, there are situations in which such a resilience is not suitable. In these cases, a task can be declared non-resilient; which means that after a node shutdown or failure the task will not be started on another node, and will be simply suspended or closed. The use case for such a feature would be perhaps the "manual" synchronization of resources - something that will be started by the system administrator, with the expectation that it will execute only until the node is down.

More precisely, this task behavior is controlled by threadStopAction attribute, which can have the following values:

First two options are used to implement resilient task behavior, while the last two ones for non-resilient tasks.

Please note that for tasks, which have no threads allocated at the moment of node down (e.g. loosely-bound recurring tasks, but also scheduled single-run tasks), this setting has no effect. These tasks will be simply started when their start time arrives. For these cases it is advisable to use suspend/close option only when there is a strong reason to do it, e.g. when an administrator wants to manually review task state after such an interruption.

Handler URI indirectly specifies which class (called handler, implementing TaskHandler interface) is responsible to handle the task. The handler will execute reaction to a task lifecycle events such as executing the task, task heartbeat, etc.

Handler URI can be also understood as a specification of task subtype.

The task handlers will register themselves with appropriate URI at midPoint initialization. The URI is used instead of a direct class name to provide additional robustness during system upgrades.

A single-run task can have a list of handler URIs. After first handler finishes its execution, it is removed from the list of handlers and second handler starts. The process continues until the list of handlers is empty. At this moment the task is automatically closed.

Task category denotes a user-recognizable type of task. Some examples: LiveSynchronization, Reconciliation, ImportingAccounts, ImportFromFile, UserRecomputation, Workflow, Demo.

Tasks may be associated with a particular objects. For example a "import from resource" task is associated with the resource definition object that it imports from. Similarly for synchronization and reconciliation tasks. This is an optional property.

The object could be also specified using usual extension mechanism. But it would be difficult to search for all the tasks that work on a particular resource or other object.

Task owner is (usually) an IDM user that initiated the task. This attribute is used e.g. for auditing reasons.

As mentioned above, there can be more nodes working in a cluster. These nodes share the workload: when a task becomes ready to be executed, one of nodes takes and executes it. (This process is governed by Quartz.)

When a node becomes unavailable (either because of shutdown, or due to sudden crash), the task manager:

In this way, high availability of the solution with regards to task execution is ensured.

Generally speaking, midPoint repository contains general task information, including its execution and business state, while Quartz job store is responsible for maintaining information necessary for task scheduling (e.g. next planned start time). With minor limitations, the information in Quartz job store can be erased at any time, and recreated from midPoint repository (at node startup) - the only damage that could occur is that some tasks could be executed one more or one less time.

Because of this, the most simple installations (e.g. demonstration ones) can be run with in-memory Quartz job store - a store that will be re-created at node startup. The limitations of this approach are:

More advanced installations could use JDBC-based Quartz job store - a store that will remember task scheduling information.

This topic is discussed in detail in Administration Interface.