Job Features

In Obsidian, everything starts with jobs. They can be scheduled, constrained by parameters, and even restricted to running on specific hosts.

In addition to job implementation features, Obsidian supports the following features that apply to the execution and scheduling environment.

Date Bound Scheduling

Obsidian supports setting the job's runtime schedule and state by date/time windows. This allows you to configure future changes to a schedule or job state. Obsidian also allows these changes to be scheduled in windows, so that a configuration will revert back to previous state at the completion of the window. This useful feature allows you to prepare for known outages, schedule holiday schedules in advance, and more, all without having to remember to make changes exactly when they need to go live.

Scheduling is done using standard Cron patterns.

Parameterization

Jobs can also be parameterized, so that jobs can be reused in multiple configurations. Parameters allow for many varying instances of the same job class that differ by the specified parameters. See Parameterization.

Host Affinity

Jobs can be restricted to run only on specified hosts. This allows you to use Obsidian in a multi-host environment, even when certain jobs can only run on one of the hosts in the cluster.

Recovery

Obsidian has extensive recovery support to ensure reliable execution in the event of outages.

First, each job is configured with a Pickup Buffer which indicates how many minutes after the scheduled time a job is considered valid for regular pickup and execution.

Every configured job also specifies a Recovery Type, which indicates how to handle a job that is not run within the Pickup Buffer. This might happen because of a configured [[Admin_Job_Conflicts|conflict] or because the scheduler was not running. Obsidian gives you fine control over how to handle these situations by exposing the following Recovery Types:

• Last indicates that only the last missed job run will be recovered.
• Conflicted indicates that only conflicted job runs will be recovered.
• All indicates that all job runs will be recovered.
• None indicates that no job runs will be recovered.

Resubmission & Ad Hoc Runs

Did a job fail unexpectedly? Or do you just need to run a job one time? Obsidian gives you the flexibility to resubmit failed jobs or submit them for a single execution regardless of their execution schedule. This can be done via our REST API or via the admin web application.

In addition, when you submit an ad hoc job run, you can supply job parameters which apply only to that execution. This can be useful for executing jobs for a particular one-time need. For example, if you run out of disk space on a host, you may have a log archival job which can be run against a specific directory for a single execution.

Forced Termination (interruptable jobs)

Jobs that appear to be hung or need to be interrupted for any other reason can be terminated by having the job implement a simple interface. See interruptable jobs.

Expected Length Handling (job execution duration)

Jobs can have an expected runtime length set, which causes a Warning level event to be triggered if a job falls outside of the expected range. This is used primarily for notifications. Users can be alerted in the event of a long-running (or unexpectedly short) job by configuring the appropriate Notifications.