Conflicts - Revision history

Carfey at 16:33, 1 July 2016

2016-07-01T16:33:45Z

← Older revision		Revision as of 16:33, 1 July 2016
Line 11:		Line 11:
	When using ''Recovery Types'' other than ''Conflicted'', in the event of a conflict, if the waiting lower-priority job cannot be picked up and started within the configured number of ''Pickup Buffer Minutes'' past the original scheduled time, the scheduled job will be marked as ''Conflict Missed'' and will not be run.		When using ''Recovery Types'' other than ''Conflicted'', in the event of a conflict, if the waiting lower-priority job cannot be picked up and started within the configured number of ''Pickup Buffer Minutes'' past the original scheduled time, the scheduled job will be marked as ''Conflict Missed'' and will not be run.

	== Jobs in Multiple Conflict ~~Sets~~ ==		== Jobs in Multiple Conflict Groups ==
	As of Obsidian 2.9.0, a job can be put into multiple conflict ~~sets~~, each having their own separate priority ordering.		As of Obsidian 2.9.0, a job can be put into multiple conflict groups, each having their own separate priority ordering.

	When selecting available non-conflicted jobs to run, Obsidian inspects the conflict ~~sets~~ in the order provided when they are saved (from left to right in the user interface), and selects the highest priority available job before moving onto the next conflict ~~set~~. When priority is significant and varies across different ~~sets~~, ensure your conflict ~~sets~~ are in the desired order.		When selecting available non-conflicted jobs to run, Obsidian inspects the conflict groups in the order provided when they are saved (from left to right in the user interface), and selects the highest priority available job before moving onto the next conflict group. When priority is significant and varies across different groups, ensure your conflict groups are in the desired order.

	=== Example ===		=== Example ===
	To demonstrate, in the example below, if Jobs 2 and 3 are ready for execution, the configuration below will cause Job 3 to be executed first since it is found in the first conflict ~~set~~. If the conflict ~~sets~~ were saved in the reverse order, Job 2 would be executed first. In addition, if Job 1 were also available for execution in the example below, it would prevent Job 3 from executing, which would result in Job 2 running simultaneously with Job 1.		To demonstrate, in the example below, if Jobs 2 and 3 are ready for execution, the configuration below will cause Job 3 to be executed first since it is found in the first conflict group. If the conflict groups were saved in the reverse order, Job 2 would be executed first. In addition, if Job 1 were also available for execution in the example below, it would prevent Job 3 from executing, which would result in Job 2 running simultaneously with Job 1.


	[[Image:MultiConflictExample.png]]		[[Image:MultiConflictExample.png]]

Carfey: /* Example */

2016-07-01T16:32:43Z

Example

← Older revision		Revision as of 16:32, 1 July 2016
Line 20:		Line 20:


	[[Image:~~MultipleConflictExample~~.png]]		[[Image:MultiConflictExample.png]]

Carfey: /* Example */

2014-11-04T00:49:53Z

Example

← Older revision		Revision as of 00:49, 4 November 2014
Line 17:		Line 17:

	=== Example ===		=== Example ===
	To demonstrate, in the example below, if Jobs 2 and 3 are ready for execution, the ~~ordering~~ below will cause Job 3 to be executed first since it is found in the first conflict set. If the conflict sets were saved in the reverse order, Job 2 would be executed first. In addition, if Job 1 were also available for execution in the example below, it would prevent Job 3 from executing, which would result in Job 2 running simultaneously with Job 1.		To demonstrate, in the example below, if Jobs 2 and 3 are ready for execution, the configuration below will cause Job 3 to be executed first since it is found in the first conflict set. If the conflict sets were saved in the reverse order, Job 2 would be executed first. In addition, if Job 1 were also available for execution in the example below, it would prevent Job 3 from executing, which would result in Job 2 running simultaneously with Job 1.


	[[Image:MultipleConflictExample.png]]		[[Image:MultipleConflictExample.png]]

Carfey: /* Example */

2014-11-04T00:49:34Z

Example

← Older revision		Revision as of 00:49, 4 November 2014
Line 17:		Line 17:

	=== Example ===		=== Example ===
			To demonstrate, in the example below, if Jobs 2 and 3 are ready for execution, the ordering below will cause Job 3 to be executed first since it is found in the first conflict set. If the conflict sets were saved in the reverse order, Job 2 would be executed first. In addition, if Job 1 were also available for execution in the example below, it would prevent Job 3 from executing, which would result in Job 2 running simultaneously with Job 1.

	To demonstrate, in the example below, if Jobs 2 and 3 are ready for execution, the ordering below will cause Job 3 to be executed first since it is found in the first conflict set. If the conflict sets were saved in the reverse order, Job 2 would be executed first. In addition, if Job 1 were also available for execution in the example below, it would prevent Job 3 from executing, which would result in Job 2 running simultaneously with Job 1.

	[[Image:MultipleConflictExample.png]]		[[Image:MultipleConflictExample.png]]

Carfey: /* Example */

2014-11-04T00:49:25Z

Example

← Older revision		Revision as of 00:49, 4 November 2014
Line 17:		Line 17:

	=== Example ===		=== Example ===

	To demonstrate, in the example below, if Jobs 2 and 3 are ready for execution, the ordering below will cause Job 3 to be executed first since it is found in the first conflict set. If the conflict sets were saved in the reverse order, Job 2 would be executed first. In addition, if Job 1 were also available for execution in the example below, it would prevent Job 3 from executing, which would result in Job 2 running simultaneously with Job 1.		To demonstrate, in the example below, if Jobs 2 and 3 are ready for execution, the ordering below will cause Job 3 to be executed first since it is found in the first conflict set. If the conflict sets were saved in the reverse order, Job 2 would be executed first. In addition, if Job 1 were also available for execution in the example below, it would prevent Job 3 from executing, which would result in Job 2 running simultaneously with Job 1.

	[[Image:MultipleConflictExample.png]]		[[Image:MultipleConflictExample.png]]

Carfey: /* Example */

2014-11-04T00:48:42Z

Example

← Older revision		Revision as of 00:48, 4 November 2014
Line 18:		Line 18:
	=== Example ===		=== Example ===
	To demonstrate, in the example below, if Jobs 2 and 3 are ready for execution, the ordering below will cause Job 3 to be executed first since it is found in the first conflict set. If the conflict sets were saved in the reverse order, Job 2 would be executed first. In addition, if Job 1 were also available for execution in the example below, it would prevent Job 3 from executing, which would result in Job 2 running simultaneously with Job 1.		To demonstrate, in the example below, if Jobs 2 and 3 are ready for execution, the ordering below will cause Job 3 to be executed first since it is found in the first conflict set. If the conflict sets were saved in the reverse order, Job 2 would be executed first. In addition, if Job 1 were also available for execution in the example below, it would prevent Job 3 from executing, which would result in Job 2 running simultaneously with Job 1.

			[[Image:MultipleConflictExample.png]]

Carfey: /* Jobs in Multiple Conflict Sets */

2014-11-04T00:47:53Z

Jobs in Multiple Conflict Sets

← Older revision		Revision as of 00:47, 4 November 2014
Line 16:		Line 16:
	When selecting available non-conflicted jobs to run, Obsidian inspects the conflict sets in the order provided when they are saved (from left to right in the user interface), and selects the highest priority available job before moving onto the next conflict set. When priority is significant and varies across different sets, ensure your conflict sets are in the desired order.		When selecting available non-conflicted jobs to run, Obsidian inspects the conflict sets in the order provided when they are saved (from left to right in the user interface), and selects the highest priority available job before moving onto the next conflict set. When priority is significant and varies across different sets, ensure your conflict sets are in the desired order.

	To demonstrate, in the example below, if Jobs 2 and 3 are ready for execution, the ordering below will cause Job 3 to be executed first since it is found in the first conflict set. If the conflict sets were saved in the reverse order, Job 2 would be executed first.		=== Example ===
			To demonstrate, in the example below, if Jobs 2 and 3 are ready for execution, the ordering below will cause Job 3 to be executed first since it is found in the first conflict set. If the conflict sets were saved in the reverse order, Job 2 would be executed first. In addition, if Job 1 were also available for execution in the example below, it would prevent Job 3 from executing, which would result in Job 2 running simultaneously with Job 1.

Carfey: /* Jobs in Multiple Conflict Sets */

2014-11-04T00:45:18Z

Jobs in Multiple Conflict Sets

← Older revision		Revision as of 00:45, 4 November 2014
Line 16:		Line 16:
	When selecting available non-conflicted jobs to run, Obsidian inspects the conflict sets in the order provided when they are saved (from left to right in the user interface), and selects the highest priority available job before moving onto the next conflict set. When priority is significant and varies across different sets, ensure your conflict sets are in the desired order.		When selecting available non-conflicted jobs to run, Obsidian inspects the conflict sets in the order provided when they are saved (from left to right in the user interface), and selects the highest priority available job before moving onto the next conflict set. When priority is significant and varies across different sets, ensure your conflict sets are in the desired order.

	In the example below, if Jobs 2 and 3 are ready for execution, the ordering below will cause Job 3 to be executed first since it is found in the first conflict set. If the conflict sets were saved in the reverse order, Job 2 would be executed first.		To demonstrate, in the example below, if Jobs 2 and 3 are ready for execution, the ordering below will cause Job 3 to be executed first since it is found in the first conflict set. If the conflict sets were saved in the reverse order, Job 2 would be executed first.

Carfey: /* Jobs in Multiple Conflict Sets */

2014-11-04T00:44:37Z

Jobs in Multiple Conflict Sets

← Older revision		Revision as of 00:44, 4 November 2014
Line 12:		Line 12:

	== Jobs in Multiple Conflict Sets ==		== Jobs in Multiple Conflict Sets ==
	As of Obsidian 2.9.0, a job can be put into multiple conflict sets, each having their own separate ~~priorities~~.		As of Obsidian 2.9.0, a job can be put into multiple conflict sets, each having their own separate priority ordering.

	When selecting available non-conflicted jobs to run, Obsidian inspects the conflict sets in the order provided when they are saved (from left to right in the user interface), and selects the highest priority available job before moving onto the next conflict set. When priority is significant and varies across different sets, ensure your conflict sets are in the desired order.		When selecting available non-conflicted jobs to run, Obsidian inspects the conflict sets in the order provided when they are saved (from left to right in the user interface), and selects the highest priority available job before moving onto the next conflict set. When priority is significant and varies across different sets, ensure your conflict sets are in the desired order.

	In the example below, if Jobs 2 and 3 are ready for execution, the ordering below will cause Job 3 to be executed first since it is found in the first conflict set. If the conflict sets were saved in the reverse order, Job 2 would be executed first.		In the example below, if Jobs 2 and 3 are ready for execution, the ordering below will cause Job 3 to be executed first since it is found in the first conflict set. If the conflict sets were saved in the reverse order, Job 2 would be executed first.

Carfey at 00:43, 4 November 2014

2014-11-04T00:43:54Z

← Older revision		Revision as of 00:43, 4 November 2014
Line 10:		Line 10:
	== Using Non-Conflicted Recovery Types ==		== Using Non-Conflicted Recovery Types ==
	When using ''Recovery Types'' other than ''Conflicted'', in the event of a conflict, if the waiting lower-priority job cannot be picked up and started within the configured number of ''Pickup Buffer Minutes'' past the original scheduled time, the scheduled job will be marked as ''Conflict Missed'' and will not be run.		When using ''Recovery Types'' other than ''Conflicted'', in the event of a conflict, if the waiting lower-priority job cannot be picked up and started within the configured number of ''Pickup Buffer Minutes'' past the original scheduled time, the scheduled job will be marked as ''Conflict Missed'' and will not be run.

			== Jobs in Multiple Conflict Sets ==
			As of Obsidian 2.9.0, a job can be put into multiple conflict sets, each having their own separate priorities.

			When selecting available non-conflicted jobs to run, Obsidian inspects the conflict sets in the order provided when they are saved (from left to right in the user interface), and selects the highest priority available job before moving onto the next conflict set. When priority is significant and varies across different sets, ensure your conflict sets are in the desired order.

			In the example below, if Jobs 2 and 3 are ready for execution, the ordering below will cause Job 3 to be executed first since it is found in the first conflict set. If the conflict sets were saved in the reverse order, Job 2 would be executed first.