Job Features: Difference between revisions
No edit summary |
No edit summary |
||
| Line 3: | Line 3: | ||
In addition to job [[Implementing_Jobs|implementation features]], Obsidian supports the following features that apply to the execution and scheduling environment. | In addition to job [[Implementing_Jobs|implementation features]], Obsidian supports the following features that apply to the execution and scheduling environment. | ||
= Date Bound | = 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. | |||
=Parameterization= | Scheduling is done using standard [http://en.wikipedia.org/wiki/Cron 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 [[Implementing_Jobs#Parameterization|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 [[Implementing_Jobs#Parameterization|Parameterization]]. | ||
=Host Affinity= | =Host Affinity= | ||
Jobs can be restricted to run only on specified hosts | 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= | =Recovery= | ||
Revision as of 03:15, 19 October 2013
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
Recovery Type allows you to specify how to handle a job that is not run within the pickup buffer because of a conflict or because the scheduler was not running.
- 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.
Pickup Buffer allows you to indicate how many minutes after the scheduled time a job is considered valid for regular pickup.
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.
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.