Page History

...

• See the How To Synchronize Job Execution Across Job Chains article for information about synchronizing Jobs in different Job Chains and for joining up parallel executing child Job Chain segments in JobScheduler versions 1.11.3 and older.
• The Join Orders Job provides a plug-in replacement for the Sync Job (JobSchedulerSynchronizeJobChains) for sync/join operations within a Job Chain. As the Join Orders Job is significantly faster than the Sync Job, users of JobScheduler 1.11.4 or newer wishing to improve performance of the Sync Job can simply replace their Sync Job with the Join Orders Jo Job.

Join Patterns

The example described in this article shows the use of a single instance of the Join Orders Job within a single Job Chain. Multiple instances of the Join Orders Job can also be used within a Job Chain. See the Configuration section of the JobSchedulerJoinOrders documentation for more information.  

...

The configuration of the Join Orders Job for use in the Split and Join pattern is described in the How to Execute Jobs in a Job Chain in Parallel article.

...

• a parameter - required_orders - which is forwarded to the Join Job. This parameter defines the number of orders that the Join Orders Job has to receive before processing the main Job Chain continues with processing of the Join Orders Job itself
• an Order for each of the child Job Chain segments that is to be processed in parallel. The end state of each of these Orders is the state of the Join Orders Job.

...

The following diagram shows the "Y"-pattern Job Chain used in the example download archive that is linked from this article. Note that some of the elements in this pattern (e.g. the generate and wait Jobs ) in this example have been given particular functions to provide a working example of the Join Orders Job included to make the example work and are not required for its operation in "normal" use.

main [label="Order:main_order",fillcolor="green"]
generate100 [label="generate orders",fillcolor="lightskyblue"]
add [label="Order:main_order_add-order",fillcolor="green"]
100150 [label="wait",fillcolor="lightskyblue"]
150200 [label="150200",fillcolor="lightskyblue"]
160300 [label="160300",fillcolor="lightskyblue"]
join [label="join orders",fillcolor="lightskyblue"]
200400 [label="200400",fillcolor="lightskyblue"]
success [label="success",fillcolor="orange"]

main -> generate100 
generate100 -> 100150 
100150  -> 150200 
150200 -> join 
add -> 160300 
160300 -> join 
join -> 200400 
200400 -> success 

• All Jobs in the "Y"-pattern are configured as a single Job Chain.
• The generate and wait Jobs in the example provide a convenient way of making the example work - they would not be required in a 'real' implementation.  

Download the Example

• Download the example y_join.zip.
• Extract the archive to a folder ./config/live of your JobScheduler Master installation.
• The archive will extract the files to a folder y_join. 
• The y_join folder can be renamed if required, the solution does not require the use of specific folder or Job names.

Example Description

...

To use the example, first start the Parent Order (in this example main_order). This Order has been configured with a number of parameters, one of which - required_orders - is required by the Join Orders JobOrders Job. The other two parameters - generate_orders and duration_wait_job are only used to provide a convenient way of making the example work.

• The required_orders parameter is read immediately by the Join Orders Job, which will then wait in the suspended state until the number of Orders specified in the parameter (here it is 1210) have been processed.
  Note that the Join Orders Job only counts orders that have the state of the Join Orders Job as their end state (here join).
• The main_order moves to the generate_orders Job, which generates a total of 10 8 Child Orders.
  
  • This number is specified in a second parameter for the main_order - generate_orders.
  • 5 4 of these child orders start processing at node 150 and 5 will start at node 160be processed in one arm of the "Y" - i.e. starting at node 200 - and 4 will be processed in the other arm - i.e. starting at node 300. All the Child Orders will end at the Join Job.
    • The branch of the Job Chain the Child Orders are have been executed on is not important for the Join Orders Job.
  • All these Child Orders will be counted towards the required_orders parameter.
  • Child Orders are identified by the Join Orders Job when they either:
    • They have Have an Id based on the Parent Order ID plus an underscore plus a string.
      • For example, the first generated Child Order in the example will be given the ID main_order_0.
      • This is the method used in the example.
    •  They carry a join_session_id parameter, specifying the ID of the Parent Order.
• The main_order itself then moves to the wait Job A where it waits for a time specified in the main_order's duration_wait_job_a parameter (here 35 30 seconds).
  
  • The sole purpose of this delay is to demonstrate that the main_order can reach the Join Orders Job after the other Child Orders.
  • This delay is not necessary for the functioning of the Join Orders Job and the example will work with the duration_wait_job_a parameter set to its minimum value of 1 (0 will cause an error).
• When the main_order reaches the Join Orders Job it will be counted towards the number of Orders specified in the required_orders parameter, making a total of 11 of  8 + 1 = 9 Orders after all the generated Child Orders have been completed.
  • Note that the main_order is the only Order that will be counted that does not have to have the state of the Join Orders Job as its end state.
• The main_order will now be suspended at the Join Orders Job (without the Job being processed) until:
  • a further Order that has the state of the Join Orders Job as its end state is completed. 

The main_order_add-order Order can now be used to increase the the total number of Orders counted by the Join Orders Job by 1.

• In the current example, running the main_order_add-order Order once will cause the number of Orders counted to reach the value set in the required_orders parameter (12).
  • The Join Orders Job will now process the main_order which will then proceed along the Job Chain - in this example to the Job C with the state 200.
• The ID of this Order has to follow the convention used for other Child Orders - that is, the ID of the parent Order plus an underscore plus a string.
  
  • Note that this string may not contain an underscore character ("_").

Note that Child Orders such as the generated Orders or the manually configured the started main_order_add-order Order in this example will only be recognized as such when they are started after the Parent Order has been started.

...

Code Block
language xml title The y_join Job Chain linenumbers true collapse true
<?xml version="1.0" encoding="ISO-8859-1"?> <job_chain title="Y Join"> <job_chain_node state="100" job="generate_orders" next_state="120150" error_state="error"/> <job_chain_node state="150" job="wait" next_state="150200" error_state="error"/> <job_chain_node state="200" job="job_a" next_state="join" error_state="error"/> <job_chain_node state="300" job="job_b" next_state="join" error_state="error" delay="10"/> <job_chain_node state="join" job="join" next_state="200400" error_state="error"/> <job_chain_node state="400" job="job_c" next_state="success" error_state="error"/> <job_chain_node state="success"/> <job_chain_node state="error"/> </job_chain>

The Jobs

The Join Orders Job

The Join

...

Orders Job basically counts incoming Jobs. This makes it significantly faster than the Sync Job mentioned above, which checks the incoming Jobs for completeness.

The configuration of the Join Orders Job can set using the JITL Job Wizard in JOE and is shown in following code block. Relevant for users in the following listing is the show_join order list parameter which may be optionally set (default is false). Setting this Parameter to true causes a list of all the orders counted by the Join Orders Job to be written to the Parent Order log file.

<?xml version="1.0" encoding="ISO-8859-1"?>

<job  order="yes" stop_on_error="no" idle_timeout="60" title="Join Job">
    <params >
        <param  name="show_join_order_list" value="true"/>
    </params>
    <script  language="java" java_class_path="" java_class="com.sos.jitl.join.JobSchedulerJoinOrdersJSAdapterClass"/>
    <run_time />
</job>

 Note that the Join Orders Job only counts orders that have the state of the Join Orders Job as their end state (here join).

The generate_orders Job

The configuration of the generate_orders Job is shown in the next code block along with the script responsible for the generation of the Child Orders.

Note that this Job is only used to create the current example and is not required for the Join Orders Job itself. In a working scheduling environment, the orders for the parallel parts of the "Y" would come from other sources such as Schedules or File Order Sources.

Note also that the Job Chain path (set in line 14 of the script) must be modified to suit the actual path used.

...