JP2008108163A - Server device, request processing control method, and program thereof - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To prevent a function of processing requests from continuously stopping in a plurality of server devices which process requests accepted from client devices. <P>SOLUTION: A server devices 10 stores information which associates URIs designated by requests from client devices 20, conditions for execution of control of processing for the requests, actions being processing contents of control, and information relating to an acceptance state of the requests with each other, in a memory 200, and a CPU 100 acquires URIs and actions from the memory 200 to inform other server device 10 of them, in response to detection of the stop of the function processing requests when information relating to the acceptance state meets a corresponding condition. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to a technique for controlling a function of a server device that processes a request received from a client device.

2. Description of the Related Art Conventionally, in a system in which a plurality of server devices are connected via a network, there is a technique for distributing the load of requests received by a server device from a client device to other server devices. For example, when the server device stores the processing time or data transfer time when request processing is entrusted to another server device as history information and receives a request from a client device, Based on this, a technology for selecting a server device that takes a short time to execute the request processing as a load balancing destination server device is disclosed (for example, see Patent Document 1). The server device entrusts execution of the process to the selected server device. According to such a technique, request processing can be distributed to a plurality of server apparatuses.
JP 2003-208414 A

  However, in the technique disclosed in Patent Document 1, for example, when a problem that consumes a large amount of memory in one request exists in the program of the server device, or the server device accepts a malicious request. In some cases, in the process of processing one request, the function of processing a request by the server apparatus may be stopped. When such a request is continuously transmitted from the client device to the server device, the server device continuously entrusts the processing of the request to other server devices by the function of load balancing the processing of the request. There is a possibility that the function of processing the request by the server device is continuously stopped.

  Therefore, an object of the present invention is to prevent a function for processing a request from being continuously stopped in a plurality of server devices that process a request received from a client device.

  In order to achieve the above object, according to the present invention, a plurality of server devices that process requests received from a client device via a network are configured to be able to communicate with each other, and are designated by requests from the client device. A storage unit that stores information that associates resource identifiers, conditions for executing control of processing for a request, actions that are control processing contents, and information about the reception status of a request, and processing information And a processing unit. When the processing unit detects the stop of the function for processing the request, when the information about the reception status of the request satisfies a condition corresponding to this information, the processing unit acquires the resource identifier and the action from the storage unit, and acquires the acquired resource. Is notified to other server devices.

  ADVANTAGE OF THE INVENTION According to this invention, it is possible to prevent that the function which processes a request stops in the some server apparatus which processes the request received from the client apparatus continuously.

  Hereinafter, the best mode for carrying out the present invention (hereinafter referred to as “embodiment”) will be described with reference to the drawings.

  FIG. 1 is a diagram showing a configuration of a request processing system in which a plurality of server devices are connected in the present embodiment. As shown in FIG. 1, the request processing system 1 according to the present embodiment includes a client device 20, a server device 10A, and a server device 10B. The client device 20, the server device 10A, and the server device 10B are configured to be able to communicate with each other via the network 30. The server device 10A and the server device 10B have a redundant configuration (similar configuration). Here, two server devices 10 are shown, but the number is not particularly limited as long as there are a plurality of server devices 10. Also, although three client devices 20 are shown, the number is not particularly limited as long as there are a plurality of client devices 20.

  The client device 20 has a function of transmitting a request to the server device 10 via the network 30 and a function of receiving a response to the request from the server device 10.

  The server device 10 includes a CPU (Central Processing Unit) 100 and a memory 200. The memory 200 as a storage unit includes an application server processing program 210, a monitoring server processing program 220, a module program (request sending / output module program) 230, a Web server processing program 240, a monitoring server definition file 250, and a module counter. The table 260 and the Web server request reception statistical information 270 are stored and stored. The CPU 100 as the processing unit has a function of executing a program stored in the memory 200.

  When a request is input from the module program 230, the application server processing program 210 is a program in which a code for executing the processing of the request and outputting a response as the execution result to the module program 230 is described.

  The monitoring server processing program 220 monitors a function for processing a request (a function realized when the application server processing program 210 is executed by the CPU 100). When the monitoring server processing program 220 detects the stop, the monitoring server processing program 220 detects the resource acquired from the monitoring server definition file 250. This is a program in which codes for notifying the identifiers and actions to other server devices 10 and module programs 230 are described. The other server apparatus 10 can control the processing when receiving the request designating the notified resource identifier by notifying the resource identifier and the action. That is, the monitoring server processing program 220 is a program as a request processing control program that controls request processing of other server devices 10. Here, the resource is information that can be acquired by the client apparatus 20 via the server apparatus 10, and is information such as an electronic document or an image, for example. The resource identifier is specified by a request from the client device. For example, a URI (Uniform Resource Identifier) is used as the resource identifier. Further, the monitoring server processing program 220 is a program in which a code that outputs the received resource identifier and action to the module program 230 when receiving the resource identifier and action from another device is described. The monitoring server definition file 250 will be described later. Further, a method for acquiring resource identifiers and actions from the monitoring server definition file 250 will be described later.

  The module program 230 is a program in which a code for registering data in the module counter table 260 when a resource identifier and an action are input from the monitoring server processing program 220 is described. The module counter table 260 will be described later. The module program 230 is a program in which a code for controlling a request to be processed by the application server processing program 210 in accordance with the module counter table 260 when a request is input from the Web server processing program 240 is described. Furthermore, when a response is input from the application server processing program 210, the program describes a code for outputting a response to the Web server processing program 240.

  The Web server processing program 240 is a program in which a code that outputs a request to the module program 230 when a request is received from the client device 20 is described. The Web server processing program 240 is a program in which a code to be transmitted to the client device 20 when a response is input from the module program 230 is described. Further, the Web server processing program 240 is a program in which a code for updating information on the request reception status included in the Web server request reception statistical information 270 is described at predetermined time intervals (for example, every second). The Web server request reception statistical information 270 and information regarding the reception status of requests included therein will be described later.

  FIG. 2 is a diagram illustrating a processing flow when the request processing system according to the present embodiment includes two server apparatuses. As shown in FIG. 2, here, as an example, the request processing system 1 includes a client device 20 and two server devices 10 (server device 10A and server device 10B). A process in which the server apparatus 10 (the server apparatus 10A and the server apparatus 10B) rejects reception of the request when the function of the request process by the server apparatus 10A is stopped will be described (see FIG. 1 as appropriate). In addition, the application server processing unit 310, the monitoring server processing unit 320, the module unit 330, and the web server processing unit 340 are respectively connected to the application server processing program 210, the monitoring server processing program 220, the module program 230, and the web server processing program 240 by the CPU 100. It is realized by being executed. The module unit 330 operates on the process of the Web server processing unit 340.

  The application server processing unit 310A accepts the request (http: //... /Hoge.jsp) transmitted from the client device 20 and tries to process it, but a problem occurs (a large amount of memory is required for one request). When there is a malfunction that may be consumed in the application server processing program 210 of the server apparatus 10A, or when the server apparatus 10A receives a malicious request, the application server processing unit 310A is down (processes the request). Suppose that the function stops. The monitoring server processing unit 320A monitors whether or not the process of the application server processing unit 310A exists every predetermined time (for example, every second), and detects that the application server processing unit 310A is down. (Step S1001), data is acquired from the Web server request reception statistical information 270 held by the Web server processing unit 340A, and analysis is performed (Step S1002). In the analysis, the data acquired from the Web server request reception statistical information 270 is compared with the data of the monitoring server definition file 250 held by itself.

  If the monitoring server processing unit 320A determines that the request (http: //.../hoge.jsp) is rejected after analysis, the monitoring server processing unit 320A rejects the request (http: //.../hoge.jsp). Is sent to the monitoring server processing unit 320B and the module unit 330A (step S1003). The monitoring server processing unit 320B notifies the module unit 330B that the request reception has been rejected (step S1004). When the request (http: //... /Hoge.jsp) received from the client device 20 via the Web server processing unit 340A is input from the Web server processing unit 340A, the module unit 330A In the process, the request is not output to the application server processing unit 310A, and an error is output to the client device 20 via the Web server processing unit 340A to reject the reception of the request (step S1005). Similarly, when the request (http: //... /Hoge.jsp) received from the client device 20 is input from the Web server processing unit 340B, the module unit 330B sends the request to the application server in the subsequent processing. The request reception is rejected by not outputting to the processing unit 310B and outputting an error to the client device 20 via the Web server processing unit 340B (step S1006).

  FIG. 3 is a diagram showing a configuration of Web server request reception statistical information in the present embodiment. As shown in FIG. 3, the Web server request reception statistical information 270 includes a URI (resource identifier) 271 and information 276 regarding the request reception status. Here, the counter 273, the number of requests 274 per second, and the average response time 275 are shown as the information 276 regarding the request acceptance status, and the value of each item is set for each time 272.

  The URI 271 is an identifier of a resource specified by a request from the client device 20 (see FIG. 1).

  The counter 273 indicates “success” that is the cumulative number of request processes that succeeded per hour 272 (seconds / minutes / hours / days), and the number of request processes that failed per hour 272 (seconds / minutes / hours / days). Includes “failure”, which is the cumulative total. As “success”, for example, an HTTP (HyperText Transfer Protocol) status code: the number of responses in the 200s to 300s can be used, and as “failure”, for example, the HTTP status code: the number of responses in the 500s can be used. . Further, the number of responses of HTTP status code: 100s may be added to “success”, or the number of responses of HTTP status code: 400s may be added to “failure”.

  The number of requests 274 per second is a value obtained by calculating the number of requests received from the client device 20 (see FIG. 1) per second as an average value in units of time 272 (seconds / minutes / hours / days). For example, when the number of requests 274 per second (average value in "day" units) is 9.1 requests / second and the number of requests 274 per second (average value in "minutes") is 12.7 requests / second Therefore, it can be determined that there is a possibility that the load due to the reception of the request is high (peak state) for 1 minute from the present. Further, instead of the number of requests 274 per second, the number of requests per other unit time may be used. For example, the number of requests per minute, the number of requests per hour, or the like may be used.

  The average response time 275 is the processing time from when the Web server processing unit 340 (see FIG. 2) receives a request from the client device 20 (see FIG. 2) until the response is returned to the client device 20 (see FIG. 2). It is a value calculated as an average value in units of 272 (seconds / minutes / hours / days). For example, if the average response time 275 (average value in “day” unit) is 18.5 milliseconds and the average response time 275 (average value in “minute” unit) is 25.6 milliseconds, one minute retroactively Since it takes a lot of time until a response is returned after receiving a request, it can be determined that there is a possibility that the load due to receiving a request is in a high time state (peak state).

  The Web server request reception statistical information 270 may be used to confirm the status of request processing in operation. The Web server request reception statistical information 270 can also clear the Web server request reception statistical information 270.

  FIG. 4 is a diagram showing the configuration of the monitoring server definition file in this embodiment. As shown in FIG. 4, the monitoring server definition file 250 includes a URI 251, a condition 252, and an action 253. The data in the monitoring server definition file 250 is defined by an administrator (not shown), for example. In addition, the memory 200 (see FIG. 1) stores at least information that associates the URI 251, the condition 252, the action 253, and the information 276 (see FIG. 3) regarding the request reception status.

  The URI 251 is an identifier of a resource specified by a request from the client device 20 (see FIG. 1). Here, a URI starting from a context root of “/” is defined as the URI 251. Further, as in the data on the third line, “*” may be used as a wild card in the URI 251. In this way, by defining the monitoring server definition file 250 for each URI 251, for example, if the request for displaying the login screen is not rejected (not set in the monitoring server definition file 250), the client device 20 This prevents you from being unable to log in.

  The condition 252 is a condition for executing processing control for the request. As the condition 252, any of the items of the counter 273, the number of requests 274, and the average response time 275 of the Web server request reception statistical information 270 (see FIG. 3) may be used. You may make it comprise. Further, a threshold value (for example, a threshold value of the average response time 275) is set in the condition 252, and the server device 10 (see FIG. 1) performs processing for the request based on the actually measured value and the threshold value. You may make it perform (control of the process with respect to a request is performed, etc., when it determines with the measured value of average response time being larger than a threshold value).

  The action 253 is the processing content when executing processing control for the request. Here, “flow rate control” and “reception refusal” of the request are defined in the action 253. “Number of simultaneous processing” of “flow rate control” is the upper limit of the number of requests that can be processed simultaneously by the application server processing unit 310, and “queue” of “flow rate control” is the number of requests that can be stored in the queue while waiting for request processing The upper limit is shown. In addition, “reception refusal” has the same meaning as “flow rate control (simultaneous processing number: 0)”. Therefore, “flow rate control (simultaneous processing number: 0)” is used instead of “reception refusal” in action 253. It may be set. As the action 253, either “the number of simultaneous processes” or “queue” may be used, or both may be set.

  FIG. 5 is a diagram showing the configuration of the module counter table in the present embodiment. The module counter table 260 includes a URI 261. When the “simultaneous processing number” is defined in the monitoring server definition file 250 (see FIG. 4), the module counter table 260 includes at least an upper limit value 262 and a request counter 263. In the case where “queue” is defined in the monitoring server definition file 250 (see FIG. 4), at least the queue size 264 and the queue counter 265 are included.

  The URI 261 is an identifier of a resource specified by a request from the client device 20 (see FIG. 1).

  The upper limit value 262 is the maximum number of requests that can be executed simultaneously by the application server processing unit 310 (see FIG. 2).

  The request counter 263 is the number of requests being executed by the application server processing unit 310 (see FIG. 2).

  The queue size 264 is the maximum number of requests that can be stored in the queue held by the module unit 330 (see FIG. 2).

  The queue counter 265 is the number of requests stored in the queue held by the module unit 330 (see FIG. 2).

  FIG. 6 is a flowchart showing the flow of processing when the function of request processing by the server device in the present embodiment is stopped. With reference to FIG. 6 (refer to FIG. 1 to FIG. 5 as appropriate), a description will be given of a process for detecting the stop of the function of processing its own request by the server device 10A and a flow of a process executed when it is detected.

  The monitoring server processing unit 320A monitors the process of the application server processing unit 310A (step S101). That is, the monitoring server processing unit 320A transmits a health check request to the application server processing unit 310A every predetermined time, and the application server processing unit 310A determines whether or not the application server processing unit 310A returns a normal response. It is confirmed whether or not it is down (whether or not the function of processing the request of the server device 10A is stopped). When the monitoring server processing unit 320A determines that the application server processing unit 310A is not down (the function of processing the request of the server device 10A is not stopped) (“No” in step S102), the process returns to step S101. . When the monitoring server processing unit 320A determines that the application server processing unit 310A is down (the function of processing the request of the server device 10A has stopped) (“Yes” in step S102), the monitoring server processing unit 320A The server processing unit 310A is restarted (step S103).

  Next, the monitoring server processing unit 320A compares the monitoring server definition file 250 with the Web server request reception statistical information 270 (step S104). That is, the monitoring server processing unit 320A receives information used in the condition 252 of the monitoring server definition file 250 (if the first line of the monitoring server definition file 250, the average response time 275 of the web server request reception statistical information 270 (seconds · Min / hour / day)) from the data of the Web server request reception statistical information 270 having the same URI 261 as the URI 251 of the monitoring server definition file 250, and whether there is a URI 251 that satisfies the condition 252 of the monitoring server definition file 250 Analyze whether or not.

  If the monitoring server processing unit 320A determines that there is no information that meets the conditions ("No" in step S105), the monitoring server processing unit 320A returns to step S101. When it is determined that there is information that meets the conditions (“Yes” in step S105), the URI 251 and the action 253 of the data determined to satisfy the condition 252 in step S105 are notified to the other monitoring server processing unit 320B (step S105). S106). Here, it is assumed that there is one other monitoring server processing unit 320B, but there may be a plurality.

  The processing of the following steps S107 to S109 controls the request processing by executing the action 253 when the server device 10A receives a request specifying the URI 251 of the data determined to satisfy the condition 252 in step S105. To do. That is, the monitoring server processing unit 320A outputs the URI 251 and the action 253 of the data determined to satisfy the condition 252 in step S105 to the module unit 330A (step S107). The module unit 330A registers information in the module counter table 260 (step S108). That is, the URI 251 input from the monitoring server processing unit 320A is set to the URI 261 of the module counter table 260, the “simultaneous processing number” of the action 253 input from the monitoring server processing unit 320A is set to the upper limit value 262, and “queue” is set to the module counter. It is registered in the queue size 264 of the table 260. For example, “0” is set in the request counter 263 and the queue counter 265.

  The module unit 330A restarts the Web server processing unit 340A (step S109). This step S109 is performed to reflect the change in the module counter table 260 held by the module unit 330 operating on the process of the Web server processing unit 340. As a method of restarting the Web server processing unit 340, restart is performed after the request being processed is completed, and a request received during the restart is stored in the queue of the Web server processing unit 340. There is a method to forcibly restart without waiting for the end. Then, it returns to step S101.

  FIG. 7 is a flowchart showing the flow of processing executed by the server device that has received the notification of the request processing function stop in this embodiment. Referring to FIG. 7 (refer to FIGS. 1 to 5 as appropriate), when the function of processing a request of server apparatus 10A is stopped, server apparatus 10B receives a notification to that effect from server apparatus 10A, and The flow of processing to be executed will be described.

  Whether the monitoring server processing unit 320B has received the URI 251 and the action 253 as a notification from the monitoring server processing unit 320A that the application server processing unit 310A is down (notification that the function of processing the request of the server device 10A has stopped) It is determined whether or not (step S201). If the URI 251 and the action 253 are not received (“No” in step S201), step S201 is repeated until it is received. When the URI 251 and the action 253 are received (“Yes” in step S201), the monitoring server processing unit 320B outputs the URI 251 and the action 253 received from the monitoring server processing unit 320A to the module unit 330B (step S202).

  The module unit 330B registers the URI 251 and the action 253 input from the monitoring server processing unit 320B in the module counter table 260 (step S203). The registration method is the same as step S108 (see FIG. 6). The module unit 330B restarts the web server processing unit 340B (step S204). The restart method is the same as in step S109. Thereafter, the process returns to step S201.

  FIG. 8 is a flowchart showing the flow of processing when a request is received by the module unit in the present embodiment. With reference to FIG. 8 (refer to FIG. 1 to FIG. 5 as appropriate), the module unit 330 of the server device 10 receives a request from the Web server processing unit 340 and the flow of processing executed when the request is received.

  The module unit 330 determines whether a request has been received from the web server processing unit 340 (step S301). If a request has not been received (“No” in step S301), step S301 is repeated until it is received. When the request is received (“Yes” in step S301), it is determined whether or not the application server processing unit 310 is down (step S302). If the application processing unit 310 is down (“Yes” in step S302), the request is transferred to another application server processing unit 310 (step S303), and the process returns to step S301. This transfer is performed via the Web server processing unit 340. Here, there is a possibility that the application server processing unit 310 is down, for example, when the restart processing of the application server processing unit 310 in step S103 (see FIG. 6) is not completed.

  When the application processing unit 310 is not down (“No” in step S302), the module unit 330 determines whether or not the URI specified by the received request is registered in the module counter table 260 (step). S304). If it is determined that it is not registered (“No” in step S304), a request is output to the application server processing unit 310 (step S305), and the process returns to step S301. If it is determined that it is registered (“Yes” in step S304), it is determined whether or not the upper limit value 262 of the module counter table 260 is “0” (step S306). The upper limit value 262 here corresponds to a result obtained by searching the module counter table 260 with the URI specified by the request received by the module unit 330.

  If the upper limit value 262 is “0” (“Yes” in step S306), an error is output to the web server processing unit 340 (step S307), and the process returns to step S301. When the upper limit value is not “0” (“No” in step S306), it is determined whether or not the upper limit value 262 is larger than the request counter 263 (step S308). The upper limit value 262 and the request counter 263 here correspond to those obtained by searching the module counter table 260 with the URI specified by the request received by the module unit 330. Note that the upper limit value 262 and the request counter 263 used in step S308 may be acquired when the determination in step S306 is performed.

  When the upper limit value 262 is equal to or smaller than the request counter 263 (when the upper limit value 262 is not larger than the request counter 263) (“No” in step S308), it is determined whether or not the queue size 264 is larger than the queue counter (step S309). ). The queue size 264 and the queue counter 265 here correspond to those obtained by searching the module counter table 260 with the URI specified by the request received by the module unit 330. Note that the queue size 264 and the queue counter 265 used in step S309 may be acquired when the determination in step S306 is performed.

  When the queue size 264 is equal to or smaller than the queue counter 265 (when the queue size 264 is not larger than the queue counter 265) (“No” in step S309), an error is output to the web server processing unit 340 (step S310), and the process proceeds to step S301. Return.

  If the queue size 264 is larger than the queue counter 265 (“Yes” in step S309), “1” is added to the queue counter 265 (step S311), a request processing waiting process is performed (step S312), and the process proceeds to step S301. Return. Here, the queue counter 265 to which “1” is added corresponds to the queue counter 265 searched by the URI specified by the request received by the module unit 330. The process waiting for request processing means storing the request in a queue and deferring the transfer of the request to the application server processing unit 310. Further, the request is stored in the queue, and the storage order is set to the value of the queue counter 265 after adding “1”.

  When the upper limit value 262 is larger than the request counter 263 (“Yes” in step S308), “1” is added to the request counter 263 (step S313), and the request is output to the application server processing unit 310 (step S314). The process returns to step S301. Here, the request counter 263 to which “1” is added corresponds to the request by searching the module counter table 260 with the URI specified by the request received by the module unit 330.

  FIG. 9 is a flowchart showing the flow of processing when a response is received by the module unit in the present embodiment. With reference to FIG. 9 (refer to FIGS. 1 to 5 as appropriate), the module unit 330 of the server device 10 receives a response from the application server processing unit 310 and the flow of processing executed when the response is received.

  The module unit 330 determines whether a response is received from the application server processing unit 310 (step S401). If no response has been received (“No” in step S401), step S401 is repeated until it is received. When a response is received (“Yes” in step S401), it is determined whether or not the URI specified by the request received from the Web server processing unit 340 is registered in the module counter table 260 (step S402). . If it is determined that it is not registered (“No” in step S402), a response is output to the web server processing unit 340 (step S403), and the process returns to step S401. If it is determined that it is registered (“Yes” in step S402), “1” is subtracted from the request counter 263 (step S404), and a response is output to the web server processing unit 340 (step S405). Here, the request counter 263 to which “1” is subtracted corresponds to the module counter table 260 searched by the URI specified by the request received by the module unit 330.

  Subsequently, the module unit 330 determines whether there is a queue waiting request (step S406). If there is no queue-waiting request (“No” in step S406), the process returns to step S401. If there is a queue-waiting request (“Yes” in step S406), the request with the storage order 1 (first) is output to the application server processing unit 310 (step S407), and each request stored in the queue "1" is subtracted from the storage order (step S408), "1" is added to the request counter 263 (step S409), "1" is subtracted from the queue counter 265 (step S410), and the process returns to step S401. . Here, the request counter 263 to which “1” is added and the queue counter 265 to which “1” is subtracted are searched by searching the module counter table 260 with the URI specified by the request received by the module unit 330. It is.

  As described above, the request processing system 1 according to the present embodiment is configured such that a plurality of server apparatuses 10 that process requests received from the client apparatus 20 via the network 30 can communicate with each other. The server device 10A includes an identifier (for example, URI 251) of a resource designated by a request from the client device 20, a condition 252 for executing control of processing for the request, an action 253 that is control processing content, Information that associates information 276 (for example, time 272, counter 273, number of requests 274 per second, and average response time 275) with respect to the request acceptance status is stored in the memory 200. Then, when the monitoring server processing unit 320A of the server apparatus 10A detects that the process of the application server processing unit 310A is down (stop of the function of processing its own request), the information 276 regarding the request reception status indicates the corresponding condition 252. If the condition is satisfied, the URI 251 and the action 253 are acquired from the memory 200 and notified to the monitoring server processing unit 320B of the other server apparatus 10B. As a result, even if the function of processing the request received from the client device 20 is stopped in the server device 10A, the server device 10B notified of the URI 251 and the action 253 notifies the processing for the request specifying the notified URI 251. Since the action can be controlled as indicated by the action 253, the function of processing the request can be prevented from stopping. That is, in a plurality of server devices, it is possible to prevent the function for processing requests from stopping continuously.

It is a figure which shows the structure of the request processing system with which the server apparatus in this embodiment was connected two or more. It is a figure which shows the flow of a process in case the request processing system in this embodiment contains two server apparatuses. It is a figure which shows the structure of the web server request reception statistical information in this embodiment. It is a figure which shows the structure of the monitoring server definition file in this embodiment. It is a figure which shows the structure of the module counter table in this embodiment. It is a flowchart which shows the flow of a process at the time of the function stop of the request process by the server apparatus in this embodiment. It is a flowchart which shows the flow of the process performed by the server apparatus which received the notification of the function stop of the request process in this embodiment. It is a flowchart which shows the flow of a process at the time of the request reception by the module part in this embodiment. It is a flowchart which shows the flow of a process at the time of the response reception by the module part in this embodiment.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Request processing system 10 (10A, 10B) Server apparatus 20 Client apparatus 30 Network 100 CPU
200 Memory 210 Application Server Processing Program 220 Monitoring Server Processing Program 230 Module Program 240 Web Server Processing Program 250 Monitoring Server Definition File 251 URI (Resource Identifier)
252 Condition 253 Action 260 Module counter table 261 URI
262 Upper limit value 263 Request counter 264 Queue size 265 Queue counter 270 Web server request reception statistical information 271 URI (resource identifier)
272 hours (information about the request acceptance status)
273 Counter (Information about the request acceptance status)
274 Number of requests per second (information about the request acceptance status)
275 Average response time (information about the request acceptance status)

Claims (5)

A plurality of server devices that accept requests from client devices via a network and process the requests are server devices in a system configured to be capable of mutual communication,
Corresponds to the identifier of the resource specified by the request from the client device, the condition for executing the control of the processing for the request, the action that is the processing content of the control, and the information about the reception status of the request A storage unit for storing the information,
When detecting the stop of the function of processing the request, when the information regarding the reception status of the request satisfies the condition corresponding to the information, the identifier of the resource and the action are acquired from the storage unit,
A server device comprising: a processing unit that notifies the acquired identifier of the resource and the action to another server device. A request processing control method by a server device in a system in which a plurality of server devices that accept a request from a client device via a network and process the request are configured to be capable of mutual communication,
Corresponds to the identifier of the resource specified by the request from the client device, the condition for executing the control of the processing for the request, the action that is the processing content of the control, and the information about the reception status of the request A storage unit for storing the processed information, and a processing unit for processing the information,
The processor is
When detecting the stop of the function of processing the request, when the information regarding the reception status of the request satisfies the condition corresponding to the information, the identifier of the resource and the action are acquired from the storage unit,
A request processing control method, comprising: notifying another server device of the acquired identifier of the resource and the action. The processor is
Update the information regarding the acceptance status of the request every predetermined time,
Information about the acceptance status of the request
The request processing control method according to claim 2, comprising at least one of the number of requests accepted per unit time, the number of requests failed in processing per unit time, and the average response time. The processor is
When the resource identifier and the action are received from another server device,
4. The request processing control method according to claim 2, wherein control of processing for a request designating an identifier of the resource is executed according to the action. 5.   A request processing control program for causing a computer to execute the request processing control method according to any one of claims 2 to 4.

Images