Job Features: Difference between revisions
No edit summary |
No edit summary |
||
| Line 27: | Line 27: | ||
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 [[Implementing_Jobs#Interruptable_Jobs|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 [[Implementing_Jobs#Interruptable_Jobs|interruptable jobs]]. | ||
=Expected Length (job execution duration) = | =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 [[Admin Notifications|Notifications]]. | 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 [[Admin Notifications|Notifications]]. | ||
Revision as of 01:09, 18 February 2013
In Obsidian, everything starts with jobs. They can be scheduled, constrained by parameters, and even restricted to running on specific hosts. See the sections below for details.
Date bound schedule/states
Obsidian supports setting the job's runtime schedule and state by date/time windows. Changes in either or both can be scheduled for the future and set indefinitely or reverting back to previous state at the completion of the window. This great functionality allows you to ensure that changes take place in advance without needing to babysit your running Obsidian instances.
Scheduling is done using 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 allowing you to use Obsidian in a multi-host environment with jobs that can't be run on just any host.
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.
