Page History

...

• Use Case
  • Run parts of a job chain in parallel, where the i.e.
    
  • split jobs for parallel processing,
  join up jobs after parallel processingparallel 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

...

• The job chain and jobs job1 to job5 provided by the sample are not specific to this solution, they 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 states to which split orders are added. 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 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.

...