Conflicts

Obsidian supports completely customizable job conflict configuration combined with custom prioritization. The web application contains an easy-to-use interface to configure these conflicts.

Any number of jobs can be configured to not run concurrently, even if scheduled to run at the same time. When jobs are set as conflicting and are scheduled to run at the same time, the chosen prioritization will determine the order of execution of the scheduled jobs. Any termination state, either success or failure, will release the next lower priority job to complete. These conflicts work even across multiple hosts.

If a job which isn't using the Conflicted recovery type cannot be executed within its Pickup Buffer, it will be marked as Conflict Missed, though it can be resubmitted later if desired. When you configure job conflicts, you will want to choose Recovery settings carefully (Recovery Type and Pickup Buffer).

Using Conflicted Recovery Type

If you are using Conflicted recovery type, the Pickup Buffer minute setting is not used when determining whether to run a job that had been conflicted. When the higher priority conflict(s) clear, a job with Conflicted recovery will always run, though the Pickup Buffer is still used in other scenarios, such as outages.

Using Non-Conflicted Recovery Types

When using Recovery Types other than Conflicted, in the event of a conflict, if the waiting lower-priority job cannot be picked up and started within the configured number of Pickup Buffer Minutes past the original scheduled time, the scheduled job will be marked as Conflict Missed and will not be run.

Jobs in Multiple Conflict Sets

As of Obsidian 2.9.0, a job can be put into multiple conflict sets, each having their own separate priority ordering.

When selecting available non-conflicted jobs to run, Obsidian inspects the conflict sets in the order provided when they are saved (from left to right in the user interface), and selects the highest priority available job before moving onto the next conflict set. When priority is significant and varies across different sets, ensure your conflict sets are in the desired order.

Example

To demonstrate, in the example below, if Jobs 2 and 3 are ready for execution, the ordering below will cause Job 3 to be executed first since it is found in the first conflict set. If the conflict sets were saved in the reverse order, Job 2 would be executed first. In addition, if Job 1 were also available for execution in the example below, it would prevent Job 3 from executing, which would result in Job 2 running simultaneously with Job 1.