JP6542172B2 - Job execution control device and program - Google Patents

Description

  Embodiments of the present invention relate to a job execution control device and a program.

In computer processing, conventionally, there exist techniques for controlling job execution.
A job is a set of predefined data in which input data, processing, and output data are predefined. In addition, a definition may be made in advance to execute a plurality of jobs continuously, or a definition may be made in advance to execute different jobs according to conditions. A series of processes consisting of a plurality of jobs may be called, for example, "job net". Conversely, a plurality of processing units constituting one job may be called, for example, a “job step”. Note that individual jobs or job steps may be normally executed and ended, or may be abnormally ended due to some error.

  In the prior art, there is a technique for attempting to recover from a failure without human intervention, such as attempting to re-execute a job by referring to information on the job configuration or the like when a failure occurs in the job. However, in the prior art, it is determined that the job is actually still running because it has not confirmed whether the job has really failed or only the information indicating the status of the job can not be accessed. It might have been

  Further, in the prior art, there is a technique of executing a plurality of jobs in parallel by a plurality of nodes using a distributed execution environment of a program. However, in the prior art, it is not possible to automatically re-execute a job on another execution node, and there is a possibility that computer resources are not effectively used.

Unexamined-Japanese-Patent No. 2015-064723 JP, 2014-142741, A JP, 2013-257903, A Japanese Patent Application Laid-Open No. 2003-085021 Japanese Patent Laid-Open No. 6-103078

  The problem to be solved by the present invention is to provide a job execution control device and program that make it possible to automatically execute job reexecution even on another node.

  The job execution control apparatus according to the embodiment has an execution manager unit, a plurality of execution node units, and an execution state sharing unit. The execution manager sends out job execution requests and re-execution requests. Each of the plurality of execution node units executes the requested job based on the execution request or the re-execution request from the execution manager unit. The execution state sharing unit holds the execution state of the job in the execution node unit. The execution node unit writes the execution state of the job being executed to the execution state sharing unit. The execution manager unit sends out the re-execution request for the job when detecting that the execution of the job in the execution node unit has failed. Further, when the execution node unit receives the reexecution request for the job from the execution manager unit, the execution node unit refers to the execution state written in the execution state sharing unit, thereby executing the job execution state. It grasps and checks whether or not the job is still executed in another execution node unit, and checks whether or not the processing of the job is completed, and the job is already executed in the other execution node unit. If not, and if the processing of the job has not been completed, the job is re-executed.

FIG. 1 is a block diagram showing a schematic functional configuration of a job execution control device 1 according to a first embodiment. FIG. 2 is a block diagram showing a more detailed functional configuration of the execution manager unit 2 of the first embodiment. FIG. 2 is a block diagram showing a more detailed functional configuration of the message broker unit 3 of the first embodiment. FIG. 2 is a block diagram showing a more detailed functional configuration of an execution node unit 5 according to the first embodiment. 6 is a sequence chart showing an example of an operation procedure in the job execution control device 1 of the first embodiment. FIG. 5 is a schematic view showing an example of the configuration of data that defines a job flow in the first embodiment. FIG. 7 is a schematic view showing an example of the configuration of job execution state information held by the execution state sharing unit 6 according to the first embodiment. FIG. 5 is a schematic diagram for explaining a method of referring to and confirming a job execution state in the first embodiment. In the first embodiment, a schematic diagram showing text data defining the definition for re-execution of the job. FIG. 7 is a schematic view showing a method of controlling the number of re-executions in the job execution control device 1 according to the first embodiment. FIG. 7 is a schematic view showing a configuration example of reexecution count information when the reexecution control unit 22 according to the first embodiment controls the number of reexecutions. FIG. 10 is a schematic view showing an example of the configuration of text data of job flow definition in a modification of the first embodiment.

  Hereinafter, a job execution control apparatus and a program of the embodiment will be described with reference to the drawings.

First Embodiment
FIG. 1 is a block diagram showing a schematic functional configuration of the job execution control apparatus 1 according to the present embodiment. As illustrated, the job execution control device 1 includes an execution manager unit 2, a message broker unit 3, a plurality of execution node units 5, and an execution state sharing unit 6.
The job execution control device 1 may be realized as a device housed in one housing. Further, devices consisting of a plurality of housings may be interconnected by a communication network or the like to realize the whole as a single system. As a specific example, a plurality of server computers and the like may be mutually connected via a communication network, and a system configured as a whole may be used as the job execution control device 1. The functions of the units constituting the job execution control device 1 are as follows.

  The execution manager unit 2 has a function of controlling the job execution order based on job flow definition data. Also, the execution manager unit 2 sends out a job execution request message. Also, the execution manager unit 2 detects whether the job execution has succeeded or failed, and determines whether the job should be re-executed. If the job should be re-executed, the execution manager unit 2 sends out a message requesting re-execution of the job. That is, when the execution manager unit 2 detects that the execution of the job in the execution node unit 5 has failed, the execution manager unit 2 may send a re-execution request for the job.

  The execution manager unit 2 counts the number of times of re-execution of the job and refers to the upper limit value of the number of times of re-execution of the job specified in advance, and when the number of re-execution exceeds the upper limit, the re-execution request It does not send any more, and outputs an alert indicating that the execution of the job is unsuccessful.

The message broker unit 3 has a function of mediating communication messages between the execution manager unit 2 and the execution node unit 5. Messages sent from the execution manager unit 2 to the execution node unit 5 (execution request messages) are stored and managed in the execution request queue. Messages sent from the execution node unit 5 to the execution manager unit 2 (execution result messages) are stored in the execution result queue and managed.
That is, the message broker unit 3 temporarily stores at least the execution request and the re-execution request sent from the execution manager unit 2 in a queue, and at the same time, executes the execution request and the re-execution request extracted from the queue It is something to pass to one of five.

Each execution node unit 5 has a function for executing the requested job based on the message of the execution request or the re-execution request from the execution manager unit 2.
Each execution node unit 5 runs on a different node. That is, each execution node unit 5 operates in an environment physically or logically independent. Therefore, even if a failure occurs in each execution node unit 5, the system is configured such that the failure does not spread to the other execution node units 5. The respective execution node units 5 may all be housed in the same housing, or some or all of them may be housed in different housings.
Also, the execution node unit 5 records information on the execution state of the job in the execution state sharing unit 6. That is, the execution node unit 5 writes the execution state of the job being executed to the execution state sharing unit 6. Further, the execution node unit 5 refers to information on the execution state of the job recorded in the execution state sharing unit 6.

  The execution node unit 5 performs control related to re-execution of a job. That is, when receiving a job re-execution request from the execution manager unit 2, the execution node unit 5 grasps the execution state of the job by referring to the execution state written in the execution state sharing unit 6, It checks whether the job is still being executed by the other execution node unit 5 and also checks whether or not the processing of the job is completed, and the job is already executed by the other execution node unit 5. If the processing of the job has not been completed, the job is re-executed.

The execution node unit 5 refers to information indicating which step of the job has been completed from the execution state sharing unit 6 when confirming whether the processing of the job is completed, and By referring to the information of the definition of the step to configure, it may be confirmed whether or not the processing of all the steps of the job is completed.
The execution node unit 5 records in the execution state sharing unit 6 a plurality of times (at least twice) at predetermined time intervals when confirming whether the job is still executed by another execution node unit 5 or not. It is determined whether or not a job is still being executed by another execution node unit 5 by referring to the execution status of the job concerned and judging whether the execution status has changed between each time. It is also good.

  When the execution node unit 5 receives a job re-execution request from the execution manager unit 2, the execution node unit 5 grasps the execution state of the job by referring to the execution state written in the execution state sharing unit 6, If the job has not been executed by another execution node unit 5 and the processing of the job has not been completed yet, which step of the job has been completed from the execution status sharing unit 6 While referring to the information which shows and referring to the information of the definition of the step which constitutes the job, the unprocessed step among the steps which constitute the job is specified, and the specified unprocessed step is resumed point Control may be performed to re-execute the job.

The execution state sharing unit 6 holds information on the execution state of the job in the execution node unit 5. As a result, job execution states can be shared among a plurality of execution node units 5. The execution state sharing unit 6 holds information on the execution state of a job as data managed by a database management system or the like. The execution state sharing unit 6 holds information on the execution state of the job in association with the execution ID of the job.
The execution state sharing unit 6 writes the information on the execution state of the job in response to the recording request from the execution node unit 5. The execution state sharing unit 6 also provides information on the execution state of the job having the required execution ID in response to a reference request from the execution node unit 5.

  FIG. 2 is a block diagram showing a more detailed functional configuration of the execution manager unit 2. As shown in FIG. As illustrated, the execution manager unit 2 includes a jobnet execution control unit 21, a reexecution count control unit 22, and an alert notification unit 23.

  The jobnet execution control unit 21 controls execution of a jobnet in which the job execution order is defined.

  The re-execution number control unit 22 records the number of times the job has been re-executed, and can refer to the number.

  The alert notification unit 23 outputs an alert when the number of times of job re-execution exceeds a predetermined maximum value. By outputting this alert, it is possible to notify the user of an event in which the number of times of re-execution exceeds a predetermined value.

  FIG. 3 is a block diagram showing a more detailed functional configuration of the message broker unit 3. As illustrated, the message broker unit 3 includes an execution request queue management unit 31, an execution result queue management unit 32, and a transaction management unit 33.

  The execution request queue management unit 31 is a queue for holding a job execution request message (hereinafter may be simply referred to as a “job execution request”) passed from the execution manager unit 2 and other execution request messages (see FIG. Manage queue). This queue is a first in, first out memory, and exists in the execution request queue management unit 31. The job execution requests stored in the queue are sequentially read out and passed to the execution node unit 5.

  The execution result queue management unit 32 is a queue for holding job execution result messages (hereinafter may be simply referred to as “job execution results”) returned from the execution node unit 5 and other execution result messages. to manage. This queue is a first-in first-out memory and exists in the execution result queue management unit 32. The job execution results stored in the queue are sequentially read out and passed to the execution manager unit 2.

  The transaction management unit 33 has a function of managing the transaction in the process of passing a job execution request and a message of a job execution result.

  FIG. 4 is a block diagram showing a more detailed functional configuration of the execution node unit 5. As illustrated, each execution node unit 5 executes the job flow definition unit 51, the job execution control unit 52, the job reexecution control unit 53, the execution state recording unit 54, the execution state reference unit 55, and the execution. A state confirmation unit 56 is included.

The job flow definition unit 51 has a function of holding or referring to the definition of the processing flow of a job.
The job execution control unit 52 executes a job and controls the job execution status.
The job re-execution control unit 53 performs control relating to re-execution of a job. For control concerning re-execution of a job, check whether the job is still executed by another execution node unit 5, check whether the job is completed, determine the resume point of the job, etc. Processing to be included.

The execution state recording unit 54 has a function of recording the execution state of the job in the execution state sharing unit 6. Here, the job execution state is information indicating which part (step) in the job flow has been executed.
The execution state reference unit 55 refers to the information on the execution state of the job recorded in the execution state sharing unit 6.

The execution status confirmation unit 56 determines whether a specific job is being executed, based on the information on the execution status of the job referred to by the execution status reference unit 55. For example, the execution status confirmation unit 56 acquires, via the execution status reference unit 55, the execution status of other jobs executed before and after a specific job, and based on the information of the execution status, the specification To determine if the job is running.
Details of the process by the execution state check unit 56 will be described later with reference to another drawing.

FIG. 5 is a sequence chart showing an example of an operation procedure in the job execution control device 1. The figure shows the operation of each part in the job execution control apparatus 1 and the interaction (the exchange of data, etc.) among the parts. The operation procedure will be described below along the sequence chart.
First, in step S 1, the execution manager unit 2 sends a job execution request to the message broker unit 3. At this time, the job execution request contains the information of the execution ID. In response to this, the message broker unit 3 writes the received job execution request into the execution request queue. This job execution request is temporarily held in the execution request queue.
In step S1, the execution request queue management unit 31 of the message broker unit 3 writes the above-mentioned job execution request message in the execution request queue.

Next, in step S1.1, one execution node unit 5 (execution node unit A) receives a job execution request from the message broker unit 3. That is, the message broker unit 3 takes out the job execution request from the execution request queue, and transmits the job execution request to the execution node unit 5 (execution node unit A).
In step S1.1, the execution request queue management unit 31 of the message broker unit 3 transmits a job execution request to the execution node unit 5.

Next, in step S2, the execution node unit 5 (execution node unit A) that receives the job execution request in step S1.1 executes a job. The job executed here is a job specified by the execution ID of the passed job execution request.
In step S2, the job execution control unit 52 of the execution node unit 5 controls the execution of the above job.

Then, in step S3, the execution node unit 5 (execution node unit A) writes the execution state of the job in the execution state sharing unit 6. The information on the execution status of this job includes the execution ID. As a result, the information on the execution status of the job of the execution ID is recorded in the execution status sharing unit 6 in a shareable status.
In step S3, the execution state recording unit 54 of the execution node unit 5 writes the execution state of the job in the execution state sharing unit 6.

  Next, in step S4, in the flow of the sequence diagram, the execution node unit 5 (execution node unit A) fails in the execution of the job. That is, the job ends abnormally due to some error in the execution of processing on the computer.

Next, in step S5, the execution node unit 5 (execution node unit A) returns a rollback message to the message broker unit 3 in response to the failure of the job execution in step S4. This rollback message contains the execution ID of the failed job. The message broker unit 3 writes this rollback message to the execution result queue.
In step S5, the execution result queue management unit 32 of the message broker unit 3 writes the rollback message to the execution result queue.

Next, in step S5.1, the execution manager unit 2 receives the above rollback message from the message broker unit 3. That is, the message broker unit 3 takes out the above rollback message from the execution result queue, and transmits the rollback message to the above execution manager unit 2. Then, the execution manager unit 2 receives this rollback message and records the number of times of execution of the job specified by the execution ID. That is, the execution manager unit 2 increments the number of times of execution of the job of the execution ID by one.
At this time, the execution manager unit 2 determines whether the number of times of re-execution of the job of the execution ID has exceeded a predetermined designated value. If the number of re-executions has not yet exceeded the designated value, the process proceeds to step S6. If the number of times of re-execution exceeds the designated value, the process proceeds to step S8.
In step S5.1, the reexecution count control unit 22 of the execution manager unit 2 records the above reexecution count and branches the process based on whether the value of the reexecution count exceeds a specified value. Control. Also, the execution result queue management unit 32 of the message broker unit 3 transmits the rollback message to the execution manager unit 2.

Next, in step S6, the execution manager unit 2 sends a message of job re-execution to the message broker unit 3 in step S6. At this time, the re-execution message contains the information of the execution ID. In response to this, the message broker unit 3 writes the received re-execution message to the execution request queue. This re-execution message is temporarily held in the execution request queue.
In step S6, the execution request queue management unit 31 of the message broker unit 3 writes the above re-execution message to the execution request queue.

Next, in step S6.1, one execution node unit 5 (execution node unit B) receives a re-execution message from the message broker unit 3. That is, the message broker unit 3 takes out the above re-execution message from the execution request queue, and transmits the re-execution message to the above execution node unit 5 (execution node unit B). Here, the execution node unit B is a node different from the execution node unit A.
In step S6.1, the execution request queue management unit 31 of the message broker unit 3 transmits a re-execution message to the execution node unit 5.

Next, in step S6.1.1, the execution node unit 5 (execution node unit B) that has received the above re-execution message refers to the execution state of the job specified by the specified execution ID. Specifically, the execution node unit 5 (execution node unit B) refers to the execution state of the job recorded in the execution state sharing unit 6.
In step S6.1.1, the execution state reference unit 55 of the execution node unit 5 refers to the execution state of the job recorded in the execution state sharing unit 6.

Next, in step S6.1.2, the execution node unit 5 (execution node unit B) confirms the job execution state based on the result of referring to the execution state sharing unit 6 in step S6.1.1. Then, the execution node unit 5 (execution node unit B) determines whether or not the job specified by the specified execution ID is being executed. If the job is not executed, the process proceeds to step S6.1.3. If the job is being executed, the process proceeds to step S6.1.5.
In step S6.1.2, the execution status confirmation unit 56 of the execution node unit 5 confirms the above-mentioned job execution status.

Next, when the process proceeds to step S6.1.3, in step S6.1.3, the execution node unit 5 (execution node unit B) determines a restart point. Specifically, the execution node unit 5 (execution node unit B) determines the restart point based on the job execution state referred to above.
In step S6.1.3, the job reexecution control unit 53 of the execution node unit 5 determines the above-mentioned restart point.

Next, in step S6.1.3.1, the execution node unit 5 (execution node unit B) re-executes the job from the restart point determined in step S6.1.3.
In step S6.1.3.1, the job reexecution control unit 53 of the execution node unit 5 controls the above reexecution.

  Next, in step S6.1.4, after the end of the re-executed job, the job execution result is returned to the message broker unit 3. The job execution result includes the execution ID of the job.

  Next, in step S6.2, the execution manager unit 2 receives the above job execution result from the message broker unit 3. That is, the message broker unit 3 takes out the job execution result from the execution result queue, and transmits the job execution result to the execution manager unit 2.

  Next, in step S7, the execution manager unit 2 receives the above-described job execution result, and performs the process of completing the execution of the job specified by the execution ID. That is, the jobnet execution control unit 21 of the execution manager unit 2 grasps that the execution of the job is completed, and updates the status information internally managed for job control.

  This is the end of the processing in the case of branching to step S6.1.3 (processing in the case of not executing as a result of checking the job execution state).

Next, in step S6.1.5, in step S6.1.5, the execution node unit 5 (execution node unit B) determines not to re-execute the job. This process is performed by the job reexecution control unit 53 of the execution node unit 5.
This is the end of the processing in the case of branching to step S6.1.5 (processing in the case of having been executed as a result of checking the job execution state).

Next, when the process proceeds to step S8, in this step, the execution manager unit 2 relates to the job specified by the execution ID based on the event that the execution of the job failed even if reexecution exceeds the designated value. , Process execution failure. That is, the jobnet execution control unit 21 of the execution manager unit 2 recognizes that the execution of the job has finally failed, and updates internally managed status information for job control.
Thus, the process when the process branches to step S8 (the process when the number of times of re-execution exceeds the designated value) is completed.

  Above, the process of the whole sequence diagram is complete | finished.

FIG. 6 is a schematic view showing a configuration example of data that defines a job flow. The job flow definition data is managed by the jobnet execution control unit 21 of the execution manager unit 2. However, the job flow definition data is held in a form that can be referred to by other units in the job execution control device 1. The job flow definition data is created in advance by a user (for example, a system operation manager) and input to the job execution control apparatus 1.
The left side of the figure is a chart visually representing the processing order relationship of a plurality of steps constituting a job. Note that the processing order of the steps is expressed in partial order. The right side of the figure is text data of a job flow definition corresponding to the chart. This text data is held in the job execution control apparatus 1 in a computer processable format such as XML format or JSON format, for example. XML is an abbreviation of Extensible Markup Language (Extensible Markup Language). Also, JSON is an abbreviation of JavaScript Object Notation. JavaScript is a registered trademark.

  In the illustrated example of the job flow definition, there are five steps (job steps), which are “Step 1” to “Step 5”. The order relationship between steps is as follows. That is, the process of Step 2 follows the process of Step 1. The process of Step 3 follows the process of Step 1. The order relation between the process of Step 2 and the process of Step 3 does not matter. The process of Step 4 follows the process of Step 2 and follows the process of Step 3. Then, the process of Step 5 follows the process of Step 4.

  Further, in the illustrated text data, the entity job (job) has an attribute id. This attribute id is the "execution ID" described above. An entity job defines a job flow by including an entity sequence (sequence) or an entity parallel (parallel) under the entity job. The entity sequence can include the entity step and the entity parallel below it. The entity parallel can include the entity step and the entity sequence below it.

The entity sequence represents that a plurality of elements are in a relation of sequential processing. That is, the subordinate elements entity step and entity parallel are defined as preceding-following relationships in the order described.
The entity parallel represents that a plurality of elements are in a parallel processing relationship. In other words, with regard to the subordinate steps entity step and entity sequence, the precedence-subsequent relationship between the elements is not defined, and it is defined that they may be executed in parallel.
The entity step has an attribute id. This id is information for identifying a step. Each entity step corresponds to a processing step in the job. In the definition of a job flow, a step is the smallest unit of processing.

  In the illustrated text data, one element job (id = job1) has one element sequence (sequential processing). The sequential processing includes an element step (id = step 1), an element parallel, an element step (id = step 4), and an element step (id = step 5). That is, this description represents that step1, elements parallel, step4, and step5 should be executed in this order. The above element parallel has an element step (id = step 2) and an element step (id = step 3). That is, this description indicates that step 2 and step 3 can be processed in parallel. As described above, this text data representation is consistent with the processing order relationship chart shown on the left side of FIG.

  FIG. 7 is a schematic view showing a configuration example of information on job execution status held by the execution status sharing unit 6. As illustrated, the information on the job execution state is held in the execution state sharing unit 6 as tabular data. The job execution state data is managed using, for example, a database management system (DBMS), and is stored in permanent storage means such as a magnetic hard disk drive or semiconductor memory. The data of the job execution state includes items of an execution ID, a step ID (Step ID), an input, and an output. The execution ID is information for identifying a job. The step ID is information for identifying a step in a job. The input is information identifying input data to the step. The output is information identifying output data from the step.

  In the illustrated example, there are three rows of data in which the execution ID is 100 and the step ID is Step1, Step2, and Step3. And there is no data whose execution ID is 100 and whose step ID is other. This means that Step 1, Step 2 and Step 3 have already been completed for the job having an execution ID of 100, but other steps (for example, Step 4 and the like) are not completed. As described above, the execution state sharing unit 6 holds data representing the execution state including the progress of execution of the job.

FIG. 8 is a schematic diagram for explaining a method of referring to and checking a job execution state.
For example, even when the execution node unit 5 can not be accessed temporarily due to a network failure, there is a possibility that the job is still being executed on the execution node unit 5. Therefore, when the job is taken over and re-executed on the other execution node unit 5, first, the execution state on the execution node unit 5 in which the job was initially operated is confirmed.

  The figure (a) shows the aspect of sharing of the execution state between execution node parts. In the example shown here, an execution node unit 5 (referred to as an execution node unit A) executes a job and records the execution state in the execution state sharing unit 6. Then, when the execution node unit A becomes temporarily incapable of service due to some trouble or the like, or when it can be determined that the service can not be performed as information through the network, another execution node unit 5 (referred to as execution node unit B) Above, try to rerun the job. At that time, the execution node unit B refers to the information of the execution state recorded in the execution state sharing unit 6 using the job execution ID as a key, and confirms the execution state of the job.

  The figure (b) shows the method the execution node part B confirms an execution state in said condition. Specifically, the execution node unit B obtains a target job from a database held by the execution state sharing unit 6 at a plurality of times (for example, two times t1 and t2) having a predetermined time interval. Get the execution status information of. At this time, the length of the time interval (difference between t2 and t1) is appropriately determined based on, for example, the time required to execute one job step. Then, the execution node unit B compares the execution state at time t1 with the execution state at time t2. The following three patterns can be detected as a result of this comparison.

  As pattern 1, there are cases where the execution state referred to at time t1 is not equal to the execution state referred to at time t2. In this case, it means that the record of the execution state is updated by the execution node unit A while the time t1 passes to the time t2. That is, in this case, the execution node unit A is still executing a job. In this case, the execution node unit B waits until the execution of the job by the execution node unit A is completed. Then, if the execution node unit A can not transmit the job execution result, the execution node unit B transmits the job execution result to the message broker unit 3 instead.

  As pattern 2, there are cases where the execution state referred to at time t1 is equal to the execution state referred to at time t2 and the end of the job flow has already been reached. Whether or not the end of the job flow has been reached can be determined by comparing the definition data of the job flow with the data of the execution state held by the execution state sharing unit 6. In the case of this pattern 2, the job execution has already been completed, but the job execution result has not yet been sent from the execution node unit A. Therefore, in this case, the execution node unit B performs only the process of transmitting the job execution result to the message broker unit 3.

  As pattern 3, the execution state referred to at time t1 may be equal to the execution state referred to at time t2 and the end of the job flow may not yet be reached. In the case of this pattern 3, it means that the predetermined part in the middle of the job is completed, and the subsequent part of the job is not executed. Therefore, the execution node unit B appropriately determines the job restart point based on the information on the execution state, and re-executes the job.

A method of determining the restart point in the case of the above pattern 3 will be described.
Assuming that the job flow definition illustrated in FIG. 6 and the execution state data (recordings of input and output of each step) illustrated in FIG. 7 are premised, the execution state data does not have the input and output records of Step 4. Therefore, it can be determined that the process of Step 4 has failed. Therefore, the point to be resumed is the head portion of Step 4. Therefore, the job re-execution control unit 53 of the execution node unit B sets Step 4 as a restart point.
That is, the execution node unit 5 identifies the unexecuted part of the job based on the data of the execution state of the job executed by the other execution node unit 5, and sets the unexecuted process as the restart point. Then, the execution node unit 5 re-executes the job from the determined restart point.

  In the example shown above, the break of the step is taken as the restart point, but the process may be resumed from an unprocessed part in the middle of the step. In that case, in the step, information indicating how much has been executed is included in the data of the execution state.

  FIG. 9 is a schematic diagram showing text data defining a definition regarding job re-execution. In the data shown in the figure, when starting a job, it is possible to specify whether re-execution is possible and the upper limit number of re-executions (retry limit, maximum number of re-executions) when enabling re-execution for each job. it can.

  In the figure, the element job has an attribute id (id = job1). The element job has an element jobnet (jobnet) below. A jobnet is a processing unit including a plurality of jobs. And, the element jobnet has the element sequence below. The element sequence is to sequentially process subordinate elements in series. And, the element sequence has three elements invoke at the lower level. The three elements invoke each have jobA, jobB and jobC as attributes jobId (job identification information). In addition, each element invoke can specify re-execution permission or not by the attribute retriable. When the value of retriable is true, it is possible to re-execute, and when its value is false, it is not possible. Also, in the case where re-execution is possible, the upper limit number of times of re-execution can be defined by the attribute retryLimit.

  In the illustrated example, the re-execution is enabled for the job whose jobId is “jobA”, and the re-execution upper limit number is set to five. Further, with regard to a job whose jobId is “job B”, re-execution is possible, and the re-execution upper limit number is set to 3. For jobs whose jobId is "jobC", it is set that re-execution is impossible.

  The job execution control device 1 controls re-execution of the job according to the text data shown in FIG. 9 described above.

  FIG. 10 is a schematic diagram showing a method of controlling the number of re-executions in the job execution control device 1. In the figure, a plurality of execution node units 5 can successively take over and re-execute jobs whose execution ID is "job A". When the first execution node unit 5 fails in execution, the execution node unit 5 sends a rollback message to the reexecution number control unit 22 in the execution manager unit 2 via the message broker unit 3. The re-execution number control unit 22 counts how many times the job "job A" is re-executed, and determines whether or not the re-execution upper limit number is exceeded, and based on the determination, the re-execution message is Send out. The re-execution message is delivered to the other execution node unit 5 via the message broker unit 3. The execution node unit 5 having received the re-execution message re-executes the job “jobA”. The same is true for the second and subsequent job execution failures, and it is possible to repeat the rollback and re-execution processes until the re-execution upper limit number is exceeded. Then, if the number of re-executions exceeds the designated re-execution upper limit number for any reason such as a failure, the re-execution number control unit 22 on the execution manager unit 2 side performs re-execution more than that. Do not execute this job, and end the job as execution failure. At this time, the information indicating the execution failure and the execution ID of the job are notified from the reexecution count control unit 22 to the alert notification unit 23. The alert notification unit 23 outputs, together with the execution ID, alert information for notifying that the job execution has failed. Based on this alert information, the user (system administrator, system operation manager, etc.) knows that the job execution has failed.

  FIG. 11 is a schematic diagram showing a configuration example of reexecution count information when the reexecution control unit 22 controls the reexecution number. As illustrated, the re-execution count information may be realized as tabular data, and includes data items of an execution ID and a re-execution count (RetryCount). That is, the reexecution count can be held in association with the execution ID. The reexecution count information is managed by, for example, a database management system (DBMS) accessible from the execution manager unit 2.

In the illustrated data example, the re-execution count count at that time is 4 for the job whose execution ID is “100”. Further, with respect to the job whose execution ID is "111", the reexecution count count at that time is 2. Further, with regard to the job whose execution ID is "120", the reexecution count count at that time is five. The re-execution number control unit 22 counts the re-execution number by updating the re-execution number count information as appropriate.
Then, as described above, if the number of re-executions is equal to or less than the specified threshold (the number of upper limit of re-executions), the number-of-re-executions control unit 22 sends a re-execution request to execute again. Also, if the number of re-executions exceeds the specified threshold (the maximum number of re-executions), there is a high possibility that recovery can not be performed by more than one re-execution. Send alert notifications.

In the above embodiment, the function of the reexecution number control unit is provided in the execution manager unit 2. However, the following modification may be made.
In this modification, not the execution manager unit 2 but the execution node unit 5 has a function (a function of a reexecution control unit) for controlling the number of times of reexecution.
Further, in this modification, in the job flow definition of each job, it is possible to designate re-execution availability of the job and the re-execution upper limit number of times when re-execution is possible.

  FIG. 12 is a schematic view showing a configuration example of text data of job flow definition in this modification. The data of the job flow definition defines the processing order of each step from step 1 to step 5 as in the text data shown in FIG. Here, the feature in the modification is that the element job has an attribute retriable and an attribute retryLimit as described in the first line of data. In the illustrated example, “retriable = true” (represents re-permission) and “retryLimit = 5” (represents that the number of re-execution upper limit is 5) is described.

  Further, in this modification, the count value of the number of times of re-execution of each job (data equivalent to that shown in FIG. 11) is stored in a database accessible from each execution node unit 5 and shared among the nodes. . As an example, the execution state sharing unit 6 may hold the count value of the number of times of reexecution of each job. Then, the execution node unit 5 performs re-execution control similar to that described above based on the count value of the number of re-executions and the upper limit number of re-executions.

  According to at least one embodiment described above, when the execution manager unit 2 detects that the execution of the job in the execution node unit 5 has failed, by sending a re-execution request for the job, or When the execution node unit 5 receives a job reexecution request from the execution manager unit 2, the execution node unit 5 grasps the execution state of the job by referring to the execution state written in the execution state sharing unit 6, and Check whether the job is still being executed by the other execution node unit 5 and also check whether or not the processing of the job is completed, and the job is no longer executed by the other execution node unit 5 And, if the processing of the job is not completed, the job is re-executed to re-execute the job across different nodes. Rukoto can.

  Further, when confirming whether the processing of the job has been completed, the execution node unit 5 refers to information indicating which step in the job has been completed from the execution state sharing unit 6, and By referring to the information of the definition of the steps constituting the job, it is confirmed whether or not the processing of all the steps of the job has been completed. As a result, it is possible to determine whether the processing of the job has been completed with respect to the job that has been executed at the node that may be at fault.

  In addition, when the execution node unit 5 checks whether the job is still executed by another execution node unit 5, the execution state sharing unit executes the job at least twice at predetermined time intervals. By referring to the state and judging whether the execution state has changed between each time, it is determined whether the job is still being executed by another execution node unit 5 or not. This makes it possible to check whether a job that appears to have failed, for example, due to a network failure, is still being executed.

  In addition, the message broker unit 3 temporarily stores the execution request and the re-execution request sent from the execution manager unit 2 in a queue, and at the same time, the execution request and the re-execution request extracted from the queue Pass on one. This makes it possible to distribute execution requests and the like to a plurality of execution node units 5.

  When the execution node unit 5 receives a job reexecution request from the execution manager unit 2, the execution node unit 5 refers to the execution state written in the execution state sharing unit 6 to grasp the execution state of the job, and the job Is not executed by another execution node unit 5 and the processing of the job has not been completed yet, information indicating which step of the job has been completed from the execution state sharing unit 6 By referring to the information on the definition of the steps that constitute the job, identify the unprocessed steps among the steps that constitute the job, and use the identified unprocessed steps as the restart point. Rerun the job. This enables re-execution from an appropriate point. In addition, unnecessary consumption of computing resources can be suppressed.

  The execution manager unit 2 counts the number of times of re-execution of the job and refers to the upper limit value of the number of times of re-execution of the job specified in advance, and when the number of re-execution exceeds the upper limit, An alert indicating that the execution of the job has failed is output without sending any more. Thus, it is possible to control the number of times of job re-execution. That is, it is possible to prevent continuous re-execution.

  Note that the functions of the job execution control device 1 in the above-described embodiment or a part of the functions may be realized by a computer. In that case, a program for realizing this function may be recorded in a computer readable recording medium, and the program recorded in the recording medium may be read and executed by a computer system. Here, the “computer system” includes an OS and hardware such as peripheral devices. The term "computer-readable recording medium" means portable media such as flexible disks, magneto-optical disks, ROMs, CD-ROMs, DVD-ROMs, and USB memories, and storage devices such as hard disks incorporated in computer systems. It means that. Furthermore, "computer-readable recording medium" holds a program dynamically for a short time, like a communication line in the case of transmitting a program via a network such as the Internet or a communication line such as a telephone line. It may also include one that holds the program for a certain period of time, such as volatile memory in the computer system that becomes the server or client in that case. The program may be for realizing a part of the functions described above, or may be realized in combination with the program already recorded in the computer system.

  While certain embodiments of the present invention have been described, these embodiments have been presented by way of example only, and are not intended to limit the scope of the invention. These embodiments can be implemented in other various forms, and various omissions, replacements, and modifications can be made without departing from the scope of the invention. These embodiments and modifications thereof are included in the invention described in the claims and the equivalents thereof as well as included in the scope and the gist of the invention.

DESCRIPTION OF SYMBOLS 1 ... Job execution control apparatus, 2 ... Execution manager part, 3 ... Message broker part, 5 ... Execution node part, 6 ... Execution state share part, 2 ... Execution manager part, 21 ... Jobnet execution control part, 22 ... Re-execution Number control unit 23 Alert notification unit 31 Execution request queue management unit 32 Execution result queue management unit 33 Transaction management unit 51 Job flow definition unit 52 Job execution control unit 53 Job re-execution unit Execution control unit, 54 ... execution state recording unit, 55 ... execution state reference unit, 56 ... execution state confirmation unit

Claims (7)

An execution manager unit that sends job execution requests and re-execution requests;
A plurality of execution node units that execute requested jobs based on the execution request from the execution manager unit or the reexecution request;
An execution state sharing unit that holds an execution state of the job in the execution node unit;
A job execution control device comprising
The execution node unit state, and are not written to the execution state of the job running on the execution state sharing unit,
When the execution node unit abnormally detects that the execution of the job in the execution node unit abnormally ends or that the execution node unit can not be temporarily accessed due to a network failure, the execution state sharing is performed. Check the execution status of the job by referring to the execution status written in the unit, and check whether the job is still being executed by another execution node unit and at the same time the processing of the job is completed Whether the job has not been executed by the other execution node unit and the processing of the job has not been completed, the job is re-executed.
Job execution control device. The execution node unit refers to information indicating which step of the job has been completed from the execution state sharing unit when confirming whether the processing of the job is completed or not, and the job Check whether all the steps of the job have been processed or not by referring to the information on the definition of the steps that constitute the job.
The job execution control device according to claim 1. The execution node unit checks whether the job is still executed by the other execution node unit, at least two times at predetermined time intervals, from the execution state sharing unit to the job of the job. Determine whether the job is still being executed by the other execution node unit by referring to the execution status and judging whether the execution status has changed between each time.
The job execution control device according to claim 1. The execution request and the re-execution request sent from the execution manager unit are temporarily stored in a queue, and the execution request and the re-execution request taken out from the queue are delivered to any of the execution node units. Message Broker Department,
The job execution control device according to any one of claims 1 to 3, further comprising: When the execution node unit receives the reexecution request for the job from the execution manager unit, the execution node unit grasps the execution state of the job by referring to the execution state written in the execution state sharing unit. If the job has not been executed by another execution node unit and processing of the job has not been completed yet, which step in the job has been completed from the execution status sharing unit While referring to the information which shows and referring to the information of the definition of the step which constitutes the job, it specifies the unprocessed step among the steps which constitute the job, and resumes the specified unprocessed step. Rerun the job as a point,
The job execution control device according to any one of claims 1 to 4. The execution manager unit counts the number of times of re-execution of the job and refers to a predetermined upper limit value of the number of times of re-execution of the job, and when the number of times of re-execution exceeds the upper limit Do not send out any more execution requests, and output an alert indicating that the job has failed.
The job execution control device according to any one of claims 1 to 5. Computer,
An execution manager unit that sends job execution requests and re-execution requests;
A plurality of execution node units that execute requested jobs based on the execution request from the execution manager unit or the reexecution request;
An execution state sharing unit that holds an execution state of the job in the execution node unit;
A job execution control device comprising
The execution node unit state, and are not written to the execution state of the job running on the execution state sharing unit,
When the execution node unit abnormally detects that the execution of the job in the execution node unit abnormally ends or that the execution node unit can not be temporarily accessed due to a network failure, the execution state sharing is performed. Check the execution status of the job by referring to the execution status written in the unit, and check whether the job is still being executed by another execution node unit and at the same time the processing of the job is completed Whether the job has not been executed by the other execution node unit and the processing of the job has not been completed, the job is re-executed.
A program for functioning as a job execution control device.

Images