Job Features - Revision history

Craig: /* Full Execution History */

2023-05-17T20:11:36Z

Full Execution History

← Older revision		Revision as of 20:11, 17 May 2023
Line 21:		Line 21:
	* '''Conflict Missed''' - Was prevented from executing by a conflicting job until after its pickup buffer expired. This is a terminal state.		* '''Conflict Missed''' - Was prevented from executing by a conflicting job until after its pickup buffer expired. This is a terminal state.
	* '''Died''' - The job execution thread (or forked process) was terminated. This can happen when Obsidian is shut down before a job completes. This is a terminal state.		* '''Died''' - The job execution thread (or forked process) was terminated. This can happen when Obsidian is shut down before a job completes. This is a terminal state.
	* '''Abandoned''' - Was in Ready state but its pickup buffer expired without an active scheduler instance available to begin execution. This can also happen when there are active scheduler instances, but due to use of [[Admin_Jobs#~~Execution_.26_Pickup~~\|Fixed Hosts]], no running instances match the host designator(s) assigned to the job. This is a terminal state.		* '''Abandoned''' - Was in Ready state but its pickup buffer expired without an active scheduler instance available to begin execution. This can also happen when there are active scheduler instances, but due to use of [[Admin_Jobs#Advanced_Options\|Fixed Hosts]], no running instances match the host designator(s) assigned to the job. This is a terminal state.
	* '''Overlapped''' - Was due to be run at its scheduled time, but was overlapped by a prior executing instance of the job. This means the previous running job's completion time was after the job's pickup buffer expired. This is a terminal state.		* '''Overlapped''' - Was due to be run at its scheduled time, but was overlapped by a prior executing instance of the job. This means the previous running job's completion time was after the job's pickup buffer expired. This is a terminal state.
	* '''Chain Skipped''' - Configured as a chain target, but the chaining restrictions were not met, so the job is not executed. This occurs when conditional chain criteria are not met, or the job state does not match one of the trigger states. This is a terminal state.		* '''Chain Skipped''' - Configured as a chain target, but the chaining restrictions were not met, so the job is not executed. This occurs when conditional chain criteria are not met, or the job state does not match one of the trigger states. This is a terminal state.

Craig: /* Host Preference */

2023-05-17T20:10:28Z

Host Preference

← Older revision		Revision as of 20:10, 17 May 2023
Line 48:		Line 48:
	=Host Preference =		=Host Preference =

	In addition to strict host selections, Obsidian 3.0 introduces the concept of host preference. For each job, you can select this option to enable prioritizing specific hosts for job execution. When a job configured with this setting is ready for execution, Obsidian will select the most preferred host to execute the job on, and if no preferred host is available, execution will fall back to any available host. This is configurable on the [[Admin_Jobs#~~Job_Edit_Screen~~\|job configuration screen]].		In addition to strict host selections, Obsidian 3.0 introduces the concept of host preference. For each job, you can select this option to enable prioritizing specific hosts for job execution. When a job configured with this setting is ready for execution, Obsidian will select the most preferred host to execute the job on, and if no preferred host is available, execution will fall back to any available host. This is configurable on the [[Admin_Jobs#Adding_.26_Editing_Jobs\|job configuration screen]].

	=Recovery=		=Recovery=

Carfey: /* Execution Status Flow */

2019-01-16T23:50:33Z

Execution Status Flow

← Older revision		Revision as of 23:50, 16 January 2019
Line 28:		Line 28:
	== Execution Status Flow ==		== Execution Status Flow ==

	[[File:obsidian_execution_statuses.~~jpg~~]]		[[File:obsidian_execution_statuses.png]]

	= Date Bound Scheduling =		= Date Bound Scheduling =

Carfey: /* Execution Statuses */

2019-01-16T23:50:07Z

Execution Statuses

← Older revision		Revision as of 23:50, 16 January 2019
Line 25:		Line 25:
	* '''Chain Skipped''' - Configured as a chain target, but the chaining restrictions were not met, so the job is not executed. This occurs when conditional chain criteria are not met, or the job state does not match one of the trigger states. This is a terminal state.		* '''Chain Skipped''' - Configured as a chain target, but the chaining restrictions were not met, so the job is not executed. This occurs when conditional chain criteria are not met, or the job state does not match one of the trigger states. This is a terminal state.
	* '''Pending''' - The state given to an [[Implementing_Jobs#Async_Jobs \| Async Job]] that has completed in Obsidian but has not yet been updated via the API to indicate its result.		* '''Pending''' - The state given to an [[Implementing_Jobs#Async_Jobs \| Async Job]] that has completed in Obsidian but has not yet been updated via the API to indicate its result.

			== Execution Status Flow ==

			[[File:obsidian_execution_statuses.jpg]]

	= Date Bound Scheduling =		= Date Bound Scheduling =

Carfey: /* Recovery */

2019-01-15T00:58:45Z

Recovery

← Older revision		Revision as of 00:58, 15 January 2019
Line 52:		Line 52:
	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.		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'':		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.		* ''Last'' indicates that only the last missed job run will be recovered.
	* ''Conflicted'' indicates that only conflicted job runs will be recovered.		* ''Conflicted'' indicates that only conflicted job runs will be recovered.

Craig: /* Execution Statuses */

2018-03-10T02:21:34Z

Execution Statuses

← Older revision		Revision as of 02:21, 10 March 2018
Line 24:		Line 24:
	* '''Overlapped''' - Was due to be run at its scheduled time, but was overlapped by a prior executing instance of the job. This means the previous running job's completion time was after the job's pickup buffer expired. This is a terminal state.		* '''Overlapped''' - Was due to be run at its scheduled time, but was overlapped by a prior executing instance of the job. This means the previous running job's completion time was after the job's pickup buffer expired. This is a terminal state.
	* '''Chain Skipped''' - Configured as a chain target, but the chaining restrictions were not met, so the job is not executed. This occurs when conditional chain criteria are not met, or the job state does not match one of the trigger states. This is a terminal state.		* '''Chain Skipped''' - Configured as a chain target, but the chaining restrictions were not met, so the job is not executed. This occurs when conditional chain criteria are not met, or the job state does not match one of the trigger states. This is a terminal state.
			* '''Pending''' - The state given to an [[Implementing_Jobs#Async_Jobs \| Async Job]] that has completed in Obsidian but has not yet been updated via the API to indicate its result.

	= Date Bound Scheduling =		= Date Bound Scheduling =

Carfey at 17:53, 1 July 2016

2016-07-01T17:53:21Z

← Older revision		Revision as of 17:53, 1 July 2016
Line 64:		Line 64:

	= Resubmission & Ad Hoc Runs =		= 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\|REST API]], [[Embedded_API\|Embedded API]] or via the [[~~Admin_Job_History~~\|admin web application]].		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\|REST API]], [[Embedded_API\|Embedded API]] or via the [[Admin_Job_Activity\|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.		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.

Carfey: /* Full Execution History */

2016-07-01T17:51:47Z

Full Execution History

← Older revision		Revision as of 17:51, 1 July 2016
Line 5:		Line 5:
	= Full Execution History =		= Full Execution History =

	Obsidian offers full transparency into when jobs run, complete and if they fail. In addition, Obsidian stores [[~~Admin_Job_History~~\|history]] of any time jobs are skipped, overlapped, missed due to downtime, etc.		Obsidian offers full transparency into when jobs run, complete and if they fail. In addition, Obsidian stores [[Admin_Job_Activity\|history]] of any time jobs are skipped, overlapped, missed due to downtime, etc.

	Obsidian also stores saved job results, chaining evaluations and stack traces in the event of a job failure.		Obsidian also stores saved job results, chaining evaluations and stack traces in the event of a job failure.

Carfey: /* Host Restrictions */

2016-07-01T17:44:53Z

Host Restrictions

← Older revision		Revision as of 17:44, 1 July 2016
Line 39:		Line 39:
	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.		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 '''[[~~Admin_System~~\|~~System~~]] / Job / adHocJobsRespectFixedHostsRestrictions'''.		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 '''[[Admin Scheduler Settings\|Scheduler Settings]] / Job / adHocJobsRespectFixedHostsRestrictions'''.

	=Host Preference =		=Host Preference =

Craig: /* Resubmission & Ad Hoc Runs */

2016-06-06T13:01:25Z

Resubmission & Ad Hoc Runs

← Older revision		Revision as of 13:01, 6 June 2016
Line 63:		Line 63:
	Use ''Exponential'' if you want the auto retries interval to exponentially increase as retries are attempted. For example, if you set the interval minutes to 5 and check Exponential, the first retry will be 5 minutes after failure, the second retry after a subsequent failure will be 10 minutes later, then 20 minutes, and so on.		Use ''Exponential'' if you want the auto retries interval to exponentially increase as retries are attempted. For example, if you set the interval minutes to 5 and check Exponential, the first retry will be 5 minutes after failure, the second retry after a subsequent failure will be 10 minutes later, then 20 minutes, and so on.

	=Resubmission & Ad Hoc Runs =		= 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\|REST API]] or via the [[Admin_Job_History\|admin web application]].		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\|REST API]], [[Embedded_API\|Embedded API]] or via the [[Admin_Job_History\|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.		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.

			As of ''Obsidian 3.8.0'', multiple Ad Hoc Runs may be submitted per minute for both immediate (next minute) execution and future execution.

	= Forced Termination (interruptable jobs) =		= Forced Termination (interruptable jobs) =