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.

Custom Calendars can also be configured with schedule changes to prevent execution on certain dates.

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 Restrictions or 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.

As of Obsidian 2.2.1, a configuration item allows you to specify whether you wish host restrictions to apply on AdHoc jobs or not. On new installations of 2.2.1, it defaults to TRUE while it defaults FALSE (to maintain behaviour from versions before 2.2.1) on upgrades from prior releases. It can by found under System / Job / adHocJobsRespectFixedHostsRestrictions.

As of Obsidian 2.3.0, a similar purposed configuration item was introduced for Chained jobs. On new installations of 2.3.0, it defaults to TRUE while it defaults FALSE (to maintain behaviour from versions before 2.3.0) on upgrades from prior releases. It can by found under System / Job / chainJobsRespectFixedHostsRestrictions.

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.

Custom Calendars

Custom calendars allow you to create named sets of dates that are used to prevent job executions. When setting a schedule for a job, you can select a custom calendar so that job execution is suppressed on any date defined in the custom calendar, regardless of the cron pattern used.

Common uses would be to define corporate holidays or those of your partners. Custom calendars are optional applications to the aforementiond date bound scheduling.