JP5884595B2 - Message communication method, message communication program, and computer - Google Patents

Description

  The present invention relates to a message communication method, a message communication program, and a computer node that perform message communication asynchronously between computer nodes.

  As a technology for performing asynchronous communication between a plurality of computer nodes, there is a message communication technology using a queue area such as a message queue.

  In this technique, a computer node on which an application process that transmits a processing request message operates registers a message to be transmitted in a queue area. Here, for convenience, an application process that transmits a processing request message is referred to as a transmission application, and a computer node on which the transmission application operates is referred to as a transmission node. A computer node on which an application process that executes processing according to a message processing request operates extracts a message from the queue area and executes processing according to the message processing request. Here, for convenience, an application process that executes processing according to a message processing request is called a receiving application, and a computer node on which the receiving application operates is called a receiving node.

  The sending node can issue a processing request message and register it in the queue area, regardless of whether or not the receiving node is ready to execute processing. The receiving node can acquire a message from the queue area and execute the process after the process is ready to be executed. This technology enables asynchronous message communication between computer nodes.

  A technique is known in which messages exchanged between a plurality of processes are propagated via a single message queue, and the storage history of messages stored in the message queue is recorded in a log. Further, a message queuing technique is known in which only a message for the current process is extracted from the message queue and transmitted, and no message is transmitted to the standby process.

JP 2005-4356 A JP 2010-86137 A

  Conventionally, the performance of a receiving node is determined at the time of system design, and a receiving application is implemented according to the performance of the receiving node. In this case, if the receiving application that executes the process is in a standby state, the receiving node can obtain the message from the queue area and execute the process smoothly.

  In recent years, with the development of cloud computing, virtualization technology has been introduced into many systems. In the virtual machine system, it is possible to dynamically change the amount of resources allocated to each virtual machine operating on the physical machine.

  For example, in a system that performs asynchronous message communication, it is assumed that the receiving node is realized by a virtual machine whose resources change dynamically. At this time, even if the receiving application that executes processing is in the standby state, the resource amount of the receiving node changes dynamically due to the influence of other virtual machines running on the same physical machine, and the receiving node responds to the message. There may also be cases where the amount of resources necessary to execute the processing smoothly cannot be obtained. If the receiving node acquires a message in this situation, the processing of the message is significantly delayed or the processing of the message becomes impossible.

  In a system that performs asynchronous message communication, it is assumed that a receiving node that has acquired a message performs processing promptly and reliably. For this reason, if there is a receiving node that cannot quickly process the received message, the entire system may not be operated smoothly.

  In one aspect, an object of the present invention is to provide a technique that enables smooth system operation even in a system in which asynchronous message communication is performed, even when the resource amount of a computer node on the message receiving side changes. And

In the message communication method disclosed as one aspect of the present invention , a computer node that is a virtual machine in which a receiving-side application process that executes processing according to the content of an accepted message operates automatically determines the free resource amount of the computer node. From the management information of the application process acquired from the guest OS of the virtual machine or the host OS that manages the virtual machine and stored in the storage unit, the processing is executed for the receiving application process whose execution status is standby. When the required resource amount is acquired and the free resource amount is equal to or greater than the required resource amount, it is determined that a message for the receiving application process that is in the standby state is acquired, and the message for the receiving application process that is in the standby state , Me It executes a process of acquiring from the storage unit for storing the message.

  In one aspect, in a system in which asynchronous message communication is performed, a smooth system operation is possible even when the resource amount of the computer node on the message receiving side changes.

It is a figure which shows the structural example of the system which performs message communication between the computer nodes by this Embodiment 1. FIG. It is a figure which shows the example of the application condition table by this Embodiment 1. FIG. It is a figure which shows the example of the property information by this Embodiment. It is a figure which shows the hardware structural example of the computer which implement | achieves the node by this Embodiment. 6 is a flowchart of processing by a transmission application of a transmission node in the first embodiment. 4 is a flowchart of processing by a queue manager of a transmission node in the first embodiment. 6 is a flowchart of processing by a reception application of a reception node in the first embodiment. 4 is a flowchart of processing by a reception control unit of a reception node in the first embodiment. 4 is a flowchart of processing by a queue manager of a receiving node in the first embodiment. It is a figure which shows the structural example of the system which performs message communication between the computer nodes by this Embodiment 2. FIG. It is a flowchart of the process by the reception application of the reception node in this Embodiment 2. It is a flowchart of the process by the application operation management part of the receiving node in this Embodiment 2. It is a figure which shows the structural example of the system which performs message communication between the computer nodes by this Embodiment 3. FIG. It is a flowchart of the process by the transmission application of the transmission node in this Embodiment 3. It is a figure which shows the system which performs the message communication by a present Example.

  Hereinafter, the present embodiment will be described with reference to the drawings.

[Embodiment 1]
FIG. 1 is a diagram illustrating a configuration example of a system that performs message communication between computer nodes according to the first embodiment.

  In the system shown in FIG. 1, the transmission node 100 and the reception node 200 are computer nodes. Hereinafter, a computer node is also simply referred to as a node. In the example of the system shown in FIG. 1, only two nodes are shown, but there may be a larger number of nodes in the system. Asynchronous message communication via the queue area 300 is performed between the transmission node 100 and the reception node 200 shown in FIG. Each node and the queue area 300 are connected to a network (not shown) such as an IP (Internet Protocol) network.

  The sending node 100 is a node that becomes a message sending side. The receiving node 200 is a node that becomes a message receiving side. In the example shown in the present embodiment, the transmission node 100 and the reception node 200 are shown for convenience, and there are a transmission node 100 that always transmits a message and a reception node 200 that always receives a message. It does not represent that. That is, each node included in the system becomes a transmission node 100 when it is a message transmission side, and becomes a reception node 200 when it is a message reception side.

  In the present embodiment, each of the transmission node 100 and the reception node 200 may be realized by a physical computer machine or a virtual computer machine. Hereinafter, a physical computer machine is called a physical machine, and a virtual computer machine is called a virtual machine. Note that the technique of the present embodiment can achieve a higher effect when the receiving node 200 is realized by a virtual machine whose resource amount dynamically changes. However, even when the receiving node 200 is a physical machine, there may be a case where the amount of resources decreases due to, for example, the occurrence of a failure. Therefore, the effect of the technique of the present embodiment can be obtained although it is limited.

  In the example illustrated in FIG. 1, the reception node 200 is realized by a virtual machine. The physical machine 10 is a physical computer machine that implements a virtual machine including the receiving node 200. In addition to the receiving node 200, a plurality of virtual machines 30 are operating on the physical machine 10 shown in FIG. Each virtual machine 30 including the receiving node 200 operates using the resources of the physical machine 10. The host OS (Operating System) / hypervisor 20 performs resource management of the physical machine 10 and management / control of each virtual machine 30 including the receiving node 200. The guest OS 201 is an OS of the receiving node 200 that is a virtual machine. Similarly, the guest OS 31 is an OS of the virtual machine 30.

  In the example shown in FIG. 1, the resource allocation to each virtual machine 30 including the receiving node 200 operating on the physical machine 10 by the host OS / hypervisor 20 is the operation status of each virtual machine 30 including the receiving node 200. It shall be changed dynamically according to That is, the amount of resources used by the receiving node 200 varies with time.

  In technology such as cloud computing, a multi-tenant environment in which one physical machine is used by a plurality of tenants may be introduced. In a multi-tenant environment, for example, the receiving node 200 operating on the physical machine 10 illustrated in FIG. 1 and another virtual machine 30 may be machines used by different tenants. In such an environment, there is a tradeoff with the virtual machine 30 of another tenant, and the receiving node 200 cannot always obtain a desired amount of resources.

  The queue area 300 is an example of a message storage unit that temporarily stores messages in order to realize asynchronous message communication between a transmission node and a reception node. In the example of the present embodiment, it is assumed that the queue area 300 is a message queue for sending and receiving messages by FIFO (First In First Out) in principle. The priority may be set for each message, and the system may be designed so that when there is a message with a low priority but a high priority in the queue area 300, the message is first taken out from the queue area 300. . Note that the message storage unit for realizing asynchronous message communication between the transmission node 100 and the reception node 200 is not necessarily a queue.

  In the design of the queue area 300, a queue for managing messages may be prepared for each destination application process, or a queue for managing messages for a plurality of different application processes may be prepared. In the queue area 300 in the example of the present embodiment, it is assumed that messages for different application processes are managed in an integrated manner.

  Various methods are conceivable as a method for realizing the queue area 300 of the present embodiment. For example, a method of realizing the queue area 300 with a dedicated node can be considered. Further, the queue area 300 can be realized by a storage that can be commonly accessed by each node of the system.

  The transmission node 100 includes a transmission application 110 and a queue manager 120. The reception node 200 includes a reception application 210, a queue manager 220, a reception control unit 230, and an application status table storage unit 240.

  The transmission application 110 of the transmission node 100 is an application process on the side of transmitting a processing request message to the reception application 210 of the reception node 200. The message transmitted by the transmission node 100 is a message issued by the transmission application 110.

  On the other hand, the reception application 210 of the reception node 200 is an application process on the side that receives a message from the transmission application 110 of the transmission node 100. The receiving application 210 executes processing according to the content of the received message. The message received by the receiving node 200 is a message accepted by the receiving application 210.

  In the receiving node 200, a plurality of receiving applications 210 can operate. In the example shown in FIG. 1, three receiving applications 210 a to 210 c are operating on the receiving node 200. Note that, in the receiving node 200, efficient use of resources is achieved by dynamically starting the necessary receiving application 210 and deleting the unnecessary receiving application 210.

  In this embodiment, it is assumed that distributed processing is performed by a plurality of receiving nodes 200. For example, the process of the same application as the reception application 210 a that operates on the reception node 200 illustrated in FIG. 1 is also operating on another reception node 200 that is not illustrated, and the reception node 200 that can execute the process is removed from the queue area 300. The message is acquired and the process is executed.

  The queue manager 120 (or 220) is a mechanism that controls transmission / reception of messages to / from the queue area 300, which is implemented in each node. When the node becomes the transmission node 100, the queue manager 120 becomes a message registration unit that transmits and registers a message to the queue area 300. When the node becomes the receiving node 200, the queue manager 220 serves as a message acquisition unit that acquires and receives messages from the queue area 300. The queue manager 120 (or 220) is implemented as a class library, for example.

  The reception control unit 230 controls the timing at which the reception node 200 receives a message from the queue area 300. More specifically, the reception control unit 230 acquires the free resource amount of the reception node 200. Also, the reception control unit 230 acquires, from the application status table storage unit 240 described later, a resource amount necessary for the reception application 210 to execute one process for the reception application 210 whose process execution state is a standby state. To do. The reception control unit 230 determines to acquire a message for the reception application 210 in the standby state when the free resource amount is equal to or greater than the necessary resource amount. Conversely, the reception control unit 230 determines not to acquire a message for the reception application 210 in the standby state when the free resource amount is less than the required resource amount. The reception control unit 230 requests the queue manager 220 to acquire a message for the reception application 210 that is determined to be acquired. At this time, the queue manager 220 operates as a message acquisition unit, and acquires a message for the reception application 210 requested from the reception control unit 230 from the queue area 300.

  The reception control unit 230 acquires the free resource amount of the reception node 200 from, for example, the OS of the reception node 200. As shown in FIG. 1, when the receiving node 200 is a virtual machine, from the guest OS 201 of the receiving node 200 that is a virtual machine or the host OS / hypervisor 20 that manages the receiving node 200 that is a virtual machine. get. Whether the reception control unit 230 acquires the free resource amount of the reception node 200 from the guest OS 201 or the host OS / hypervisor 20 can be arbitrarily designed according to the environment of the reception node 200.

  Since the guest OS 201 does not grasp the resource status of the physical machine 10, the amount of free resources allocated to the receiving node 200 cannot always be determined accurately. For example, in the above-described multi-tenant environment in cloud computing, there is a case where the amount of resources required by the guest OS 201 cannot be obtained because it competes with the virtual machines 30 of other tenants.

  On the other hand, since the host OS / hypervisor 20 that manages the resources of the physical machine 10 knows the resource status of the physical machine 10, it can accurately determine the amount of free resources allocated to the receiving node 200. Can do. When the information on the free resource amount of the receiving node 200 can be obtained from the host OS / hypervisor 20, the reception control unit 230 can acquire the correct free resource amount of the receiving node 200.

  However, in the above-described multi-tenant environment in cloud computing, the host OS / hypervisor 20 is not necessarily the own tenant. In such an environment, the reception control unit 230 may not be able to obtain information on the free resource amount of the reception node 200 from the host OS / hypervisor 20. Even in such a case, the reception control unit 230 can acquire information on the free resource amount of the reception node 200 from the guest OS 201.

  The application situation table storage unit 240 is a storage unit that stores an application situation table that manages the reception application 210 that operates on the reception node 200. The application status table storage unit 240 is an example of a management information storage unit that stores application process management information.

  FIG. 2 is a diagram illustrating an example of an application status table according to the first embodiment.

  The application status table 245 illustrated in FIG. 2 is an example of the application status table stored in the application status table storage unit 240 of the receiving node 200 illustrated in FIG. The application status table 245 illustrated in FIG. 2 has application ID, necessary resource, and application status information for each record corresponding to each of the reception applications 210 operating on the reception node 200.

  In the application status table 245 illustrated in FIG. 2, the application ID is identification information that identifies the application of the reception application 210 of the corresponding record. In the application status table 245 shown in FIG. 2, for example, “app # 01” is identification information of the application of the receiving application 210a, “app # 02” is identification information of the application of the receiving application 210b, and “app It is assumed that # 03 ″ is the identification information of the application of the receiving application 210c.

  In the present embodiment, the transmission application 110 of the transmission node 100 sends a message by designating the application ID of the other party that requests processing. In the receiving node 200, when there is a receiving application 210 that is determined to be able to execute processing, a message corresponding to the receiving application 210 is identified by the application ID and acquired from the queue area 300. For example, when distributed processing is performed by a plurality of receiving nodes 200, the same application ID is given to the receiving application 210 of the same application even if the receiving nodes 200 are different. That is, the message transmitted from the transmission node 100 and stored in the queue area 300 can be received by any reception node 200 as long as it is the reception node 200 in which the reception application 210 of the application ID that is the destination of the message operates. Good.

  In the application status table 245 illustrated in FIG. 2, the necessary resource is information of a resource necessary for the receiving application 210 of the corresponding record to perform one process. In the example of the application status table 245 shown in FIG. 2, information on the number of CPU (Central Processing Unit) cores, the amount of memory, the amount of network bandwidth, and the capacity of the hard disk is recorded as information on resources necessary for each receiving application 210.

  In the application status table 245 illustrated in FIG. 2, the application state indicates the execution state of processing by the reception application 210 of the corresponding record. In the example of the application status table 245 illustrated in FIG. 2, “standby” in the application state indicates a standby state in which the corresponding reception application 210 is waiting for a processing request message. In addition, “operation” in the application state indicates an operation state in which the corresponding reception application 210 receives a processing request message and executes processing according to the content of the message.

  In the first embodiment, it is assumed that each receiving application 210 records / updates its own information in the application status table 245. For example, at the time of activation, the receiving application 210 generates a record for recording its own information in the application status table 245, and registers its own application ID and necessary resources in the record. At this time, the receiving application 210 sets its own application status to “standby” in the application status table 245. When executing the process according to the content of the received message, the receiving application 210 updates its application state to “active” in the application state table 245. When the process corresponding to the content of the received message is terminated, the receiving application 210 updates its own application state to “standby” in the application status table 245.

  Information such as an application ID and necessary resources registered in the application status table 245 when the reception application 210 is activated may be incorporated in, for example, an application program of the reception application 210, or may be property information prepared separately from the application program. It may be set.

  FIG. 3 is a diagram illustrating an example of property information according to the present embodiment.

  The property information 205 illustrated in FIG. 3 is an example of property information in which information such as an application ID of the receiving application 210 and necessary resources is set. For example, FIG. 3A shows property information 205a for the receiving application 210a shown in FIG. FIG. 3B shows property information 205b for the receiving application 210b shown in FIG. FIG. 3C shows property information 205c for the receiving application 210c shown in FIG.

  The property information 205 shown in FIG. 3 is stored as a single file, for example, in a storage unit not shown in FIG. In the first embodiment, each receiving application 210 accesses a file of its own property information 205 at the time of activation, for example, and acquires information such as its own application ID and necessary resources.

  FIG. 4 is a diagram illustrating a hardware configuration example of a computer that implements a node according to the present embodiment.

  A physical computer 1 that implements the transmission node 100 and the reception node 200 according to the present embodiment shown in FIG. 1 includes, for example, a CPU 2, a memory 3 serving as a main memory, a storage device 4, a communication device 5, and a medium reading / writing. A device 6, an input device 7, an output device 8 and the like are provided. The storage device 4 is an external storage device such as an HDD (Hard Disk Drive) or an auxiliary storage device. The medium reading / writing device 6 is, for example, a CD-R (Compact Disc Recordable) drive or a DVD-R (Digital Versatile Disc Recordable) drive. The input device 7 is, for example, a keyboard / mouse. The output device 8 is a display device such as a display, for example.

  The transmission node 100 and the reception node 200 shown in FIG. 1 and each functional unit included in these nodes can be realized by hardware such as the CPU 2 and the memory 3 included in the computer 1 and a software program. A program that can be executed by the computer 1 is stored in the storage device 4, read into the memory 3 at the time of execution, and executed by the CPU 2.

  The computer 1 can also read a program directly from a portable recording medium and execute processing according to the program. The computer 1 can also sequentially execute processing according to the received program every time the program is transferred from the server computer. Further, this program can be recorded on a recording medium readable by the computer 1.

  Hereinafter, an example of a flow of processing related to message communication performed by the transmission node 100 and the reception node 200 according to the first embodiment will be described with reference to flowcharts illustrated in FIGS.

  FIG. 5 is a flowchart of processing by the transmission application of the transmission node in the first embodiment.

  In the transmission node 100, the transmission application 110 adds meta information to a message for requesting processing to the reception application 210 (step S10). Here, examples of the meta information added to the message include an application ID of the destination receiving application 210, a priority, and an ID of the self-sending application 110. In the example of the first embodiment, a destination application ID is given to a message. For example, when the destination is the reception application 210a illustrated in FIG. 1, the transmission application 110 assigns “app # 01” as the destination application ID. The transmission application 110 requests the queue manager 120 to transmit a message (step S11).

  FIG. 6 is a flowchart of processing by the queue manager of the transmission node in the first embodiment.

  In the sending node 100, when the queue manager 120 receives a request to send a message with meta information from the sending application 110 (step S20), the queue manager 120 further adds a time stamp to the message with the meta information received from the sending application 110. Is given (step S21). The queue manager 120 registers the message with the time stamp and meta information in the queue area 300 (step S22). In the example of the first embodiment, a message with a time stamp and a destination application ID is stored in the queue area 300. Note that the registration of a message in the queue area 300 is also called an enqueue.

  FIG. 7 is a flowchart of processing by the receiving application of the receiving node in the first embodiment.

  In receiving node 200, receiving application 210 adds its own record to application status table 245 at the time of activation (step S30). The receiving application 210 registers its own application ID and the amount of resources necessary for itself to execute one process in its own record in the application status table 245 (step S31). For example, when the receiving application 210a shown in FIG. 1 is activated, the receiving application 210a acquires its own application ID and necessary resource information from the property information 205a file shown in FIG. Recorded in its own record in the status table 245. The receiving application 210 sets the application state of its own record in the application status table 245 to “standby” indicating the standby state (step S32).

  When receiving the message from the transmission application 110 (YES in step S33), the reception application 210 updates the application state of its own record in the application status table 245 to “operation” indicating the operation state (step S34). The receiving application 210 executes processing according to the content of the received message (step S35).

  When the process corresponding to the message ends, the receiving application 210 updates the application status of its own record in the application status table 245 to “standby” indicating the standby status (step S34). The receiving application 210 returns to the process of step S33 and waits for the next message.

  Although not shown in the flowchart of FIG. 7, the reception application 210 deletes its own record in the application status table 245 when it is deleted from the reception node 200.

  FIG. 8 is a flowchart of processing by the reception control unit of the reception node in the first embodiment.

  In the reception node 200, the reception control unit 230 periodically refers to the application status table 245 to check the presence of the reception application 210 whose application state is “standby” (step S40).

  When there is a reception application 210 in the “standby” state (YES in step S40), the reception control unit 230 sequentially selects one reception application 210 in the “standby” state (step S41). When there are a plurality of receiving applications 210 in the “standby” state, the reception control unit 230 sequentially receives the receiving applications to be processed by specific priority control using priority, control using round robin, or the like. 210 is selected. When there is only one receiving application 210 in the “standby” state, the reception control unit 230 selects the receiving application 210.

  The reception control unit 230 acquires information on necessary resources of the corresponding reception application 210 from the application status table 245 (step S42). In addition, the reception control unit 230 acquires information on free resources of the own reception node 200 from the guest OS 201 or the host OS / hypervisor 20 (step S43). Note that whether the information on the free resources of the receiving node 200 is acquired from the guest OS 201 or the host OS / hypervisor 20 depends on the design.

  The reception control unit 230 determines whether there are free resources of the reception node 200 that are more than the necessary resources of the reception application 210 (step S44). If there is no free resource more than the necessary resource (NO in step S44), the reception control unit 230 determines that a message for the corresponding reception application 210 is not acquired, and the process proceeds to step S48. For example, when the reception control unit 230 compares each item of the number of CPU cores, the amount of memory, the amount of network bandwidth, and the capacity of the hard disk, if there is even one item whose free resource is smaller than the necessary resource, , It is determined that there are no more free resources than necessary.

  If there is a free resource more than the necessary resource (YES in step S44), the reception control unit 230 determines to acquire a message for the corresponding reception application 210. For example, the reception control unit 230 is necessary if the free resources are larger than the required resources in all items when comparing the number of CPU cores, the amount of memory, the amount of network bandwidth, and the hard disk capacity. It is determined that there are free resources more than resources.

  At this time, the reception control unit 230 designates the application ID of the corresponding reception application 210 and requests the queue manager 220 to receive a message for the reception application 210 (step S45). When the reception control unit 230 acquires a message for the reception application 210 from the queue manager 220 (step S46), the reception control unit 230 passes the acquired message to the reception application 210 (step S47). In the corresponding reception application 210, processing according to the content of the message passed from the reception control unit 230 is executed.

  The reception control unit 230 determines whether the processing has been completed for all reception applications 210 in the “standby” state (step S48). If the processing has not been completed for all the reception applications 210 in the “standby” state (NO in step S48), the reception control unit 230 returns to the process in step S41, and receives the next reception application 210 in the “standby” state. Move on to processing. If the processing has been completed for all reception applications 210 in the “standby” state (YES in step S48), the reception control unit 230 returns to the processing in step S40 and waits for the next application status table 245 check timing. .

  FIG. 9 is a flowchart of processing by the queue manager of the receiving node in the first embodiment.

  In the receiving node 200, when the queue manager 220 receives a message reception request from the reception control unit 230 (step S50), the queue manager 220 searches for a message in the queue area 300 using the designated application ID as a search key (step S51). For example, the queue manager 220 searches the queue area 300 for messages in which the assigned application ID matches the application ID of the search key in order from the oldest time stamp so that the message can be taken out by FIFO. In addition, when priority information is attached to a message, a design such as preferentially searching for a message having a high priority is arbitrary. If there is no message addressed to the designated application ID in the queue area 300 (NO in step S52), the queue manager 220 returns to the process in step S51 and waits for the next search timing.

  If there is a message addressed to the specified application ID in the queue area 300 (YES in step S52), the queue manager 220 records the target message so that the message extraction processing is not congested with other receiving nodes 200. Lock (step S53) and perform exclusive control. The queue manager 220 takes out the target message from the queue area 300 (step S54). Note that the retrieval of a message from the queue area 300 is also called dequeue. The queue manager 220 responds to the reception control unit 230 with the extracted message (step S55). The queue manager 220 deletes the retrieved message from the queue area 300 (step S56).

  As described so far, the reception control unit 230 in the reception node 200 according to the first embodiment receives the corresponding reception if there is not enough free resources in the reception node 200 even if there is a reception application 210 in the standby state. Control is performed so that a message for the application 210 is not acquired. The reception control unit 230 performs control to acquire a message only when it can be determined that there is a free resource necessary for the reception application 210 in the standby state to execute one process at that time.

  That is, even when the amount of resources changes dynamically, the receiving node 200 according to the first embodiment acquires only a message that can be sufficiently processed at that time from the queue area 300 and performs processing. Therefore, it is possible to avoid a situation where the receiving node 200 obtains a message from the queue area because of the receiving application 210 in the standby state, and the processing amount cannot be appropriately executed due to a shortage of resources because the resource amount has changed. .

  As a result, for example, in a system in which distributed processing is performed by a plurality of receiving nodes 200 whose resource amount dynamically changes, only the receiving node 200 that can truly execute processing at that time sends a message from the queue area 300. Since it is acquired and processed, the system can be operated smoothly.

[Embodiment 2]
FIG. 10 is a diagram illustrating a configuration example of a system that performs message communication between computer nodes according to the second embodiment.

  In the system configuration according to the second embodiment shown in FIG. 10, the configuration of the reception node 200 'is the same as the configuration of the reception node 200 shown in FIG. Other configurations are the same as those of the system according to the first embodiment shown in FIG. In the following, the second embodiment will be described with a focus on the differences from the first embodiment, and the description of the same parts as the first embodiment will be omitted.

  In the first embodiment described above, each receiving application 210 records its property information and the execution state of its own process in the application status table 245 of the application status table storage unit 240. In the second embodiment, the application operation management unit 250 records the property information of each received application 210 and the execution state of the process in the application status table 245 of the application status table storage unit 240.

  In the second embodiment, each receiving application 210 operating on the receiving node 200 ′ does not perform processing for recording its own property information and the execution status of its own processing in the application status table 245.

  FIG. 11 is a flowchart of processing by the receiving application of the receiving node in the second embodiment.

  In the reception node 200 ′, the reception application 210 waits for reception of a message from the transmission application 110 after activation (step S 60). When receiving application 210 receives a message from transmitting application 110 (YES in step S60), receiving application 210 executes processing according to the content of the received message (step S61). When the process corresponding to the message is completed, the receiving application 210 returns to the process of step S60 and waits for reception of the next message.

  As described above, each reception application 210 operating in the reception node 200 ′ of the second embodiment performs the same processing as the existing reception application regardless of the introduction of the message communication technique according to the present embodiment.

  The application operation management unit 250 included in the reception node 200 ′ is a functional unit that monitors the operation of each reception application 210 that operates on the reception node 200 ′. When the reception node 200 ′ is activated, the application operation management unit 250 is activated before each reception application 210.

  FIG. 12 is a flowchart of processing by the application operation management unit of the receiving node in the second embodiment.

  In the reception node 200 ′, when the application operation management unit 250 detects activation of the reception application 210 (YES in step S70), the application operation management unit 250 generates a record that records information on the reception application 210 in the application status table 245 (step S71). ). For example, the application operation management unit 250 reads the application ID and necessary resources of the activated reception application 210 from the property information 205 file illustrated in FIG. 3 (step S72). The application operation management unit 250 registers the read application ID and necessary resources in the corresponding record of the application status table 245 (step S73). In the application status table 245, the application operation management unit 250 sets the application state of the activated reception application 210 to “standby” (step S74).

  When detecting the deletion of the reception application 210 (YES in step S75), the application operation management unit 250 deletes the deleted record of the reception application 210 from the application status table 245 (step S76).

  When the application operation management unit 250 detects that the reception application 210 has received a message (YES in step S77), the application state of the reception application 210 is updated to “operation” in the application status table 245 (step S78). .

  When the application operation management unit 250 detects that the reception application 210 has finished the process according to the message (YES in step S79), the application state of the reception application 210 is updated to “standby” in the application status table 245. (Step S80).

  As described so far, the application operation management unit 250 in the reception node 200 ′ according to the second embodiment collectively manages the execution state of processing of each reception application 210 operating on the reception node 200 ′. As a result, when the message communication technology according to the present embodiment is introduced, the existing receiving application program can be used without rewriting.

[Embodiment 3]
FIG. 13 is a diagram illustrating a configuration example of a system that performs message communication between computer nodes according to the third embodiment.

  In the configuration of the system according to the third embodiment shown in FIG. 13, the configuration of the receiving node 200 ″ is obtained by deleting the application status table storage unit 240 from the configuration of the receiving node 200 shown in FIG. Instead, the application status table storage unit 400 is provided outside the receiving node 200 ″. Other configurations are the same as those of the system according to the first embodiment shown in FIG. In the following, the third embodiment will be described with a focus on the differences from the first embodiment described above, and the description of the same parts as the first embodiment will be omitted.

  The application situation table storage unit 400 is a storage unit that stores an application situation table that collectively manages reception applications 210 that operate on a plurality of reception nodes 200 ″. The application situation table storage unit 400 according to the third embodiment is realized. Various methods are conceivable as in the case of the queue area 300. For example, a method of realizing the application status table storage unit 400 in any node provided in the system is conceivable. The application status table storage unit 400 can also be realized by a storage that can be commonly accessed by nodes.

  As a configuration of the application status table stored in the application status table storage unit 400, for example, a node ID for identifying the receiving node 200 ″ is added to the application status table 245 illustrated in FIG. In the unit 400, for example, an application status table is managed for each receiving node 200 ″.

  In the receiving node 200 ″, the receiving application 210 accesses the application status table storage unit 400 with the node ID of the own receiving node 200 ″ when recording its own property information and processing execution state in the application status table. Record / update. In addition, when acquiring the information of the reception application 210 of the own reception node 200 ″, the reception control unit 230 accesses the application status table storage unit 400 using the node ID of the own reception node 200 ″ and acquires the information.

  Note that the application status table information may be managed separately in the receiving node 200 ″ and in the external application status table storage unit 400. For example, of the application status table information, each receiving application 210 may be managed. Information of necessary resources may be managed inside the receiving node 200 ″, and only the execution state of the processing of each receiving application 210 may be managed by the external application status table storage unit 400.

  In the third embodiment, the transmission application 110 of the transmission node 100 refers to the application status table of the application status table storage unit 400 and confirms whether or not the standby reception application 210 exists in the system. The transmission application 110 requests the queue manager 120 to transmit a message when there is a reception application 210 in a standby state in the system.

  FIG. 14 is a flowchart of processing by the transmission application of the transmission node in the third embodiment.

  In the transmission node 100, when the transmission application 110 sends a processing request message to the reception application 210, the transmission application 110 refers to the application situation table in the application situation table storage unit 400 using the application ID of the reception application 210 (step S90). .

  The transmitting application 110 determines whether the corresponding receiving application 210 exists in any receiving node 200 ″ in the system (step S91). The corresponding receiving application 210 exists in any receiving node 200 ″ in the system. If not (NO in step S91), the transmission application 110 returns to the process in step S90 and waits for the next timing. For example, if there is no record of the application ID of the corresponding receiving application 210 in the application status table of the application status table storage unit 400, it is determined that the corresponding receiving application 210 does not exist. In an environment in which the receiving application 210 is dynamically activated / deleted in the receiving node 200 ″, the target receiving application 210 may not exist in any receiving node 200 ″ in the system.

  If the corresponding reception application 210 exists in any reception node 200 ″ in the system (YES in step S91), the transmission application 110 determines whether the corresponding reception application 210 in the standby state exists (step S92). If there is no corresponding reception application 210 in the standby state (NO in step S91), the transmission application 110 returns to the process in step S90 and waits for the next timing.

  If there is a corresponding reception application 210 in the standby state (YES in step S92), the transmission application 110 adds meta information to a message for requesting processing to the reception application 210 (step S93). The transmission application 110 requests the queue manager 120 to transmit a message (step S94).

  As described so far, the transmission application 110 in the transmission node 100 according to the third embodiment confirms whether there is a target reception application 210 in the application state table storage unit 400 in the target standby state. The transmission application 110 requests the queue manager 120 to transmit a message only when there is a target reception application 210 in a standby state.

  That is, the transmission node 100 does not transmit a message that cannot be received immediately by the reception node 200 ″ to the queue area 300. As a result, a message that is not immediately processed stays in the queue area 300, so Can be prevented from being depleted.

〔Example〕
FIG. 15 is a diagram illustrating a system for performing message communication according to the present embodiment.

  In the system shown in FIG. 15, the transmission node 500 corresponds to, for example, the transmission node 100 shown in FIG. The reception node 600 and the reception node 700 correspond to, for example, the reception node 200 illustrated in FIG. The receiving node 600 and the receiving node 700 are assumed to be virtual machines whose resource amount dynamically changes. The queue area 800 corresponds to, for example, the queue area 300 shown in FIG.

  The reception application 610a that operates on the reception node 600 and the reception application 710a that operates on the reception node 700 are processes of the same application (application ID: “app # a”) that operate on different reception nodes. . In addition, the reception application 610b that operates on the reception node 600 and the reception application 710b that operates on the reception node 700 are processes of the same application (application ID: “app # b”) that operate on different reception nodes. And

Here, the transmission node 500 issues messages in the order of the message Ma ₁ , the message Ma ₂ , and the message Mb. It is assumed that the destination application ID of the message Ma ₁ and the message Ma ₂ is “app # a”, and the destination application ID of the message Mb is “app # b”. As shown in FIG. 15, messages are stored in the queue area 800 in the order of message Ma ₁ , message Ma ₂ , and message Mb.

At this time, it is assumed that the reception applications 610a and 610b of the reception node 600 and the reception applications 710a and 710b of the reception node 700 are all in a standby state. At this timing, the receiving node 600 performs a periodic reception check, confirms that the receiving application 610a is in a standby state, and confirms that there is a sufficient free resource amount for the receiving application 610a to execute processing. Check. The receiving node 600 searches the queue area 800 in the application ID "app # a" of receiving application 610a, obtains the message Ma _1. Receiving application 610a begins executing the process in accordance with the contents of the message Ma _1.

At the next timing, the receiving node 700 performs a periodic reception check, confirms that the receiving application 710a is in a standby state, and that the receiving application 710a has a sufficient amount of free resources to execute processing. Confirm. The receiving node 700 searches the queue area 800 in the application ID "app # a" of receiving application 710a, obtains the message Ma _2. Receiving application 710a begins executing the process in accordance with the contents of the message Ma _2.

  At the next timing, the receiving node 600 performs a periodic reception check to confirm that the receiving application 610b is in a standby state. Here, assuming that the node resource amount does not change over time, application processes are usually implemented according to the node resource amount. If the application process wait state can be confirmed, a message can be received. No problem. Conventionally, the message Mb corresponding to the reception application 610b is acquired from the queue area 800 at this time.

  However, since the amount of resources allocated to the receiving node 600 changes with time, even if it is confirmed that the amount of free resources is sufficient at a certain time and the receiving application 610b is activated, the receiving application 610b is processed at another time. There may be a case where there is not enough free resources to execute. At this timing, it is assumed that the amount of resources allocated to the receiving node 600 has decreased, and there is not enough free resources for the receiving application 610b to execute processing. At this time, the receiving node 600 determines not to receive a message for the receiving application 610b. That is, the receiving node 600 does not extract the message Mb with the application ID “app # b” in the queue area 800.

  At the next timing, the reception node 700 performs a periodic reception check to confirm that the reception application 710b is in a standby state. Also, the receiving node 700 confirms that the amount of free resources at this time is sufficient for the receiving application 710b to execute processing. The receiving node 700 searches the queue area 800 with the application ID “app # b” of the receiving application 710b, and acquires the message Mb. The receiving application 710b starts executing processing according to the content of the message Mb.

  As shown in the present embodiment, there is a problem that at a certain point in time, there is a receiving node 700 with sufficient resources, but the receiving node 600 with insufficient resources acquires the message Mb and processing is delayed. Can be prevented. As described above, when the message communication technique according to the present embodiment described above is used, even if the amount of resources allocated to the receiving nodes 600 and 700 varies with time, the receiving nodes 600 and 700 that can execute processing at that time. Since only the message is acquired, the system can be operated smoothly.

  Although the present embodiment has been described above, the present invention can naturally be modified in various ways within the scope of the gist thereof.

10 Physical Machine 20 Host OS / Hypervisor 30 Virtual Machine 31 Guest OS
100 Sending node 110 Sending application 120 Queue manager 200 Receiving node 201 Guest OS
210 reception application 220 queue manager 230 reception control unit 240 application status table storage unit 250 application operation management unit 300 queue area 400 application status table storage unit

Claims (6)

A computer node that is a virtual machine on which the receiving application process that executes processing according to the content of the received message is running
The amount of free resources of the computer node is acquired from the guest OS of the own virtual machine or the host OS that manages the own virtual machine ,
From the application process management information stored in the storage unit, obtain the amount of resources required to execute processing for the receiving application process whose processing execution status is standby,
If the free resource amount is greater than or equal to the required resource amount, determine to obtain a message for the receiving application process in the standby state;
A message communication method comprising: executing a process of acquiring a message for the receiving application process in the standby state from a storage unit that stores the message. The computer node further includes:
Receiving application processes running said computer node, the execution state of its own processing, message communication method according to claim 1, characterized in that performing the process of recording the management information. The computer node further includes:
A function unit that monitors the operation of a reception-side application process that operates on the computer node executes a process of recording an execution state of processing of a reception-side application process that operates on the computer node in the management information; The message communication method according to claim 1 . A computer node on which a sending application process that sends a message requesting processing to the receiving application process operates,
Refer to the management information, and when there is a receiving application process whose processing execution state is in a standby state, register a message for the receiving application process in the standby state in a storage unit that stores the message The message communication method according to any one of claims 1 to 3, wherein: On the computer node that is the virtual machine on which the receiving-side application process that executes processing according to the content of the received message runs,
The amount of free resources of the computer node is acquired from the guest OS of the own virtual machine or the host OS of the computer that manages the own virtual machine ,
From the application process management information stored in the storage unit, obtain the amount of resources required to execute processing for the receiving application process whose processing execution status is standby,
If the free resource amount is greater than or equal to the required resource amount, determine to obtain a message for the receiving application process in the standby state;
A message communication program for executing processing for acquiring a message for the receiving-side application process in the standby state from a storage unit that stores the message. A computer that starts a computer node , which is a virtual machine on which a receiving-side application process that executes processing according to the content of a received message runs,
A management information storage unit for storing application process management information;
A reception-side application process in which the free resource amount of the computer node is acquired from the guest OS of the computer node or the host OS of the local computer that manages the computer node, and the execution state of the process is a standby state from the management information Receives the amount of resources required to execute the process, and determines that a message for the receiving application process in the standby state is to be acquired when the acquired free resource amount is greater than or equal to the acquired required resource amount A control unit;
When the reception control unit determines to retrieve messages, computer, characterized in that it comprises a message for the receiving application process which is the standby state, a message acquisition unit that acquires from the message memory.

Images