Page History

...

• Use Case
  • Run parts of a job chain in parallel, where parallel processing is already being carried out.
• Solution Outline
  • Two standard JITL Jobs are provided for this:
    • JobSchedulerJobChainSplitter
      
      • splits an incoming order into multiple orders that are run in parallel through a job chain within a range of predefined job chain nodes.
    • JobSchedulerJoinOrders
      
      • joins the orders that have previously been split in a job chain node, i.e. this job forces any split orders to complete to this job chain node before processing continues.
• References
  • How to Execute Jobs in a Job Chain in Parallel for an overview of the methods available for Parallel Execution within a Job Chain
  • Example showing how to set up a splitter job
• Availability

  • Display feature availability
    StartingFromRelease 1.11.4

  • See How to Execute Jobs in a Job Chain in Parallel for more information.

Solution

• Download nested_parallel_execution.zip
• Extract the archive to a folder ./config/live of your JobScheduler Master installation.
• The archive will extract the files to a folder nested_parallel_execution. 
• You can save the sample files in any folder as you like, the solution does not require the use of specific folder names. Job names can be freely chosen, with the exception of JITL jobs - which here are JobChainSplitter and join.

...

job_chain [label="Job Chain",fillcolor="orange"]
split [label="split",fillcolor="lightskyblue"]
split_100 [label="split:100",fillcolor="lightskyblue"]
split_200 [label="split:200",fillcolor="lightskyblue"]
split2 [label="splitsplit2",fillcolor="white"]
split2_100 [label="splitsplit2:100",fillcolor="white"]
split2_200 [label="splitsplit2:200",fillcolor="white"]
join2 [label="join2",fillcolor="white"]
split_300 [label="split:300",fillcolor="lightskyblue"]
split_400 [label="split:400",fillcolor="lightskyblue"]
join [label="join",fillcolor="lightskyblue"]
300 [label="300",fillcolor="lightskyblue"]
success [label="success ",fillcolor="orange"]

{rank=same split_100 split_200 split_300 split_400} -> {rank=same split2} -> {rank=same split2:100 split2:200} -> {rank=same join2} [style=invis]

job_chain -> split 
split -> split_100
split -> split_200
split_200 -> split2
split2 -> split2_100
split2 -> split2_200
split2_100 -> join2
split2_200 -> join2
split -> split_300
split -> split_400
split_100 -> join
join2 -> join 
split_300 -> join
split_400 -> join
join -> 300
300 -> success 

Implementation

Components

• The job chain and jobs job1 to job5 provided by the sample Neither the Job Chain and Jobs jobA to jobD provided in the current example are not specific to this solution, they . The jobs represent simple shell scripts.
• The two split_partitions jobs (split and split2) are instances of the Splitter JITL Job and use the Java class com.sos.jitl.splitter.JobChainSplitterJSAdapterClass.
  • The job is used with the following parameters:
    • state_names: a list of semicolon separated job node Job Node states to which split orders Orders are added . For to. An individual Order is created for each entry in this list an individual order is created.
      • The state names correspond to the states that the respective job nodes are associated with in the job chain definition.
      • State names for the first node of each of the job chain segments that are executed in parallel should be prefixed with the name of the state of the split_partitions job and a colon. This should be followed by a unique descriptor, usually name of the job associated with the state but this is not mandatory. This convention is necessary to ensure correct display of dependencies in JOE and the JOC Cockpit. For example, state of one of the nested job chain segments in the example used in this article is:
        • split2:200 for jobD.
      • Note that the naming convention for state names for the first node of each parallel job chain segment does not have to be followed for subsequent nodes in the job chain segment (See the example in the How to split and join jobs in a job chain article.)
      • The state names corresponding to the first nodes in each parallel job chain segment are specified in the state_names parameter. For example, the split2 instance of the JobChainSplitter job has the value:
        
        • split_partitions:job3;split_partitions:job4
    • join_state_name: this parameter is required exclusively for improved graphical output from JOE and the JOC Cockpit. It requires specifies the name of the state that is specified for the join node corresponding to the splitter node. For example the value specified for the split2 instance of the JobChainSplitter job is:
      • join2
  • Any number of jobs can follow the jobs that are referenced by the state_names parameter.
• The job job_chain1.join_partitions is used to join up split orders and is provided by the Join Orders JITL Job with the Java class com.sos.jitl.join.JobSchedulerJoinOrdersJSAdapterClass.
  • The recommended naming convention for this job uses the job chain name as a prefix: due to the nature of this job to join up across all job chains that are running in the system and that make use of the same join job name you should prefix the job name with the job chain name if you want this job to be limited to work for the current job chain.
  • This job is used without parameters.

...

• Start the main Order (named start in this example) for the Job Chain using JOC. In the current example this will immediately start processing the split Job.
• Each split job generates a new Order for each split part of the Job Chain. The main Order will then jump to the join node corresponding to the split node and wait (in the suspended state) for the processing of all the parallel chain segments to be completed. The name of this node is specified in the join_state_name: parameter described above. In the current example, the start Order will wait at the join node until the split:100, join, split:300 and split:400 jobs have successfully completed being processed.    

...