JP2015141535A - System, controlling method therefor, and computer program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a system which prevents memory leaks and allows continuous use of processes associated with high rates of cache data usage.SOLUTION: A system 80 for executing a plurality of processes, each having a defined execution period; extends an execution period of a first process based on a cache data usage rate; reduces an execution period of a second process, other than the first process, based on the extended execution period of the first process; and terminates a process whose execution period is over.

Description

  The present invention relates to a program that operates as a Web service on a network, and more particularly to a data conversion service that converts data into a format that can be output to a printing apparatus.

  In general, Web services are required to have high availability. Therefore, if there is a memory leak in the program that configures the Web service, it will affect the entire server that provides the Web service over a long period of operation. As one countermeasure against the memory leak, a method of dividing a Web service into a plurality of functional components and operating each component as an independent process is applied. It is empirically known that functional components have a difference in the amount of memory leaks depending on the complexity of the functions, the amount of program code, and the frequency of exception processing in the processing content.

  For example, in the system disclosed in Patent Document 1, a counter that determines the restart timing is associated with each of a plurality of processes that provide services, and the value of the counter is managed by a single management unit. . The management unit updates each counter value according to the risk of processing, and determines the restart of the process by comparison with a threshold value. According to this system, process restarts are executed in order, so that memory leaks are released in order even during service provision.

JP 2011-54114 A

  In the system of the present application, a method for realizing high throughput will be examined while paying attention to the above-described memory leak problem. Consider using a data cache to ensure high throughput in data conversion processing. In order to prepare and hold a cache, a cache data creation time as an initial investment and a certain memory area are required.

  For example, in a web service that provides the same function as that of a printer driver, a font data font for printing is an example. Fonts in a printed document rarely differ from page to page, and it is conceivable that the same font is designated at least in a certain document. Further, it is assumed that print documents created from the same user have a high tendency to use the same font. Therefore, if the Web service receives a plurality of documents from the same user as described above and the font data cache is reused, the cache can be reused continuously for different print jobs. Can be expected to be high.

  However, if a cache is prepared as described above, a memory area is required. If a memory area is required, the possibility of a memory leak increases. On the other hand, if the process is restarted as in Patent Document 1, a process that is likely to reuse the cache may be restarted as described above. If the process is restarted, the prepared cache is released, leading to a reduction in system throughput.

  An object of the present invention is to provide a system that realizes continuation of use of a process having a high cache data usage rate while suppressing occurrence of a memory leak.

  A system for executing a plurality of processes with a predetermined execution period according to an embodiment of the present invention includes: an extension unit that extends the execution period of the first process based on a usage rate of cache data; A shortening unit that shortens an execution period of a second process other than the first process based on an execution period of one process; and an ending unit that ends a process whose execution period has ended.

  According to the system of the present invention, it is possible to realize continuation of use of a process having a high cache data usage rate while suppressing occurrence of a memory leak. Therefore, it is possible to provide a system with high performance that provides stability and high throughput to the operation of the system.

1 is a diagram illustrating an example of the overall configuration of a printing system according to an embodiment. It is a block diagram explaining the hardware structural example of server PC. It is a block diagram explaining the software structural example of server PC. It is a figure explaining the component group relevant to operation | movement of a print data conversion part. It is a figure explaining the production | generation, extinction, and utilization of a component. It is a schematic diagram which shows the structure of a service catalog. It is a schematic diagram which shows the structure of a service inventory. It is a figure which shows the function structure of server PC which performs the lifetime process of a component. 6 is a processing flow of an event loop of a PDLFilter according to the first embodiment. It is a processing flow of the initialization process of PDLFilter. It is a processing flow of the lifetime extension confirmation process of PDLFilter. It is a processing flow of the life extension process of PDLFilter. It is a processing flow of the event loop of a locator. It is a processing flow of the message processing of a locator. It is a processing flow of the lifetime extension process of a locator. It is the graph which showed the relationship between the increase amount of memory leak amount, and the reduction amount. 10 is a processing flow of an event loop of the PDLFilter in the second embodiment. It is a processing flow of a PDLFilter life extension request processing. It is a processing flow of the message processing of a locator. It is a processing flow of the lifetime extension process of a locator.

Example 1
FIG. 1 is a diagram showing a configuration example of a distributed processing system according to an embodiment of the present invention. The distributed processing system includes requester-side devices 20 to 40 that request a print conversion service, a printer 60, and service-providing devices 70 to 90. A client 50 who requests print data conversion uses a device such as a personal computer 20, a tablet PC 30, or a portable terminal 40 as a device that transmits a print data conversion request. The client 50 uses an application (not shown) running inside these devices to send print data to a print data conversion unit 330 (described later with reference to FIG. 3) existing on the network 10. Request conversion.

  The print data conversion unit 330 is a program operating as a so-called Web service that publishes a well-known URL on the server PC 80. On the server PC 80, a Web communication unit 310 is also operating to transfer a request from an external device such as the personal computer 20 that has arrived for the URL to the print data conversion unit 330. Since there are usually a large number of requests that arrive at the URL, a single server PC 80 is not processed, but a plurality of server PCs 80 are processed. Accordingly, the load balancer 70 is installed in front of the plurality of server PCs 80, and requests transferred to the server PCs 80 are evenly distributed.

  A service provided by the print data conversion unit 330 is to convert data designated by the client 50 into a format that can be printed by the printer 60. The data designated by the client has formats created by various application programs such as documents and image files. On the other hand, the data received by the printer 60 as print data is different from the above-described format, and is data described in PDL or data described in PJL having instructions and parameters for controlling printing such as the number of copies. ing. PJL is an abbreviation for Print Job Language.

  As described above, since there is a difference in the data format to be handled between the client 50 and the printer 60, a program for filling in the difference is required. A program called a printer driver usually performs this conversion process. The printer driver is usually operated on a PC on which the above-described application program operated by the client 50 is operating. However, since the printer driver process is a heavy process that requires relatively resources such as CPU and memory, the print process becomes impractical when the resources held by the PC operated by the client 50 are small. It will be such a process. As the demand for printing from terminals with relatively few resources, such as terminals operated by the client 50 (for example, personal computers 20, tablet PCs 30 and portable terminals 40), printer driver processing can be performed by services on the Internet. The importance is increasing.

  The requester 50 requests the above-described various terminals to convert the print data into a format that can be printed by the printer 60 with respect to the above-described URL. The converted data generated by the print data conversion unit 330 operating on the server PC 80 in response to the request is returned to the requesting terminal. Depending on the instruction of the client 50, the converted data may be stored in the file server PC 90 accessible by the print data conversion unit 330.

  FIG. 2 is a diagram illustrating a hardware configuration example included in each device illustrated in FIG. 1. Hereinafter, the server PC 80 will be described as an example. The server PC 80 includes an HDD 102, a ROM 103, a RAM 104, a CPU 105, an output device 106, an input device 107, and a communication device 108. The CPU 105 controls the entire function of the server PC 80 in an integrated manner. The CPU 105 implements a print service function by reading an OS (operating system) and application programs from the HDD 102 or the ROM 103, loading them into the RAM 104, and executing them. The processing result by the CPU 105 is stored in the HDD 102 as a file or stored in the RAM 104 as data. CPU, HDD, ROM, and RAM are abbreviations for Central Processing Unit, Hard Disk Drive, Read Only Memory, and Random Access Memory, respectively.

  The HDD 102 or ROM stores software groups shown in FIG. 3 that operate on the OS. The input device 107 acquires user input and reading values of various sensors. The output device 106 outputs various information and displays the processing result. The communication device 108 communicates with other computers and devices connected to the network. These hardware components are connected to each other via a control bus 1001 and can be operated from an application program.

  FIG. 3 is a diagram showing a software configuration example of the server PC 80 functioning as the system of the present invention. The server PC 80 includes a Web communication unit 310, an application unit 320, a print data conversion unit 330, a locator 340, and a logger 350. The web communication unit 310 receives a request transmitted by the HTTP protocol from an application on the personal computer 20 operated by the client 50. The load balancer 70 is positioned in front of the Web communication unit 310 and distributes the received request to the Web communication units 310 operating on the plurality of server PCs 80. Various methods of distributing are known, but the details thereof are not related to the present invention, so that the description thereof is omitted.

  Here, the server PC 80 does not necessarily mean one physical server PC. In recent years, virtualization technology that allows multiple virtual PCs to appear on a single PC has become commonplace, and from the viewpoint of software, an operating system on which it operates is virtually created. It is not possible to determine whether or not, or it is not necessary to determine. Therefore, the server PC 80 in the present invention may mean “in some cases a virtualized PC”. Hereinafter, the expression “PC” is treated as meaning both a physical PC and a virtualized PC.

  The application unit 320 is software that analyzes a URL designated as a request destination and determines an associated print data conversion unit 330. Normally, the Web communication unit 310 and the application unit 320 can handle a plurality of types of services, and can identify requests corresponding to URLs and distribute requests. In the present embodiment, it is assumed that one of the multiple types of services is the print data conversion unit 330. In addition to this service, services are operating, but in the description of the invention, services other than the print data conversion unit 330 are omitted.

  The print data conversion unit 330 takes a form in which a service is provided by a plurality of processes operating together instead of a single process. In the following, it should be noted that these processes are collectively referred to as “print data conversion service”. The locator 340 and the logger 350 are processes that exist independently of the print data conversion unit 330. The application unit 320 activates a plurality of print data conversion units 330 in order to execute a plurality of requests in parallel, and distributes the requests to each. Even in this case, each of the locator 340 and the logger 350 exists as one process. The application unit 320 further manages a session for specifying a series of requests from the client 50 when the print data conversion unit 330 operates. Specifically, session affinity is realized in which requests from the same client 50 are transferred to the same print data conversion unit 330.

(Print data conversion service)
FIG. 4 is a diagram for explaining the relationship between software component groups related to the operation of the print data conversion unit 330. As described above, the print data conversion unit 330 operates as a community of a plurality of processes. The components are a print service gateway 211, a proxy module 220, a filter host 240, and various filter groups (270, 280, 290). Here, three types of various filters are shown for explanation, but there are actually many filters, and the combinations are not fixed, and are different for each print data conversion unit 330 to be generated. Filters may be used.

(Print service gateway)
A service request to the print data conversion unit 330 is received by the print service gateway 211 that exists as a process, and the application unit 320 starts it. The print service gateway 211 loads the proxy module 220, requests execution of conversion processing by calling a function group provided by the Application Programming Interface (API), and receives a result. When an API provided by the proxy module 220 is called to request the print data conversion unit 330 to provide a service, a data structure called “job” is generated. A detailed description of the job will be described later.

(locator)
A locator 340 used by a component group constituting the print data conversion unit 330 has a special role. The locator 340 is a special process that is already activated when the application unit 320 is activated. There are various methods for starting the locator 340 depending on the operating system (OS) operating on the server PC 80. For example, if it is Windows (registered trademark), it can be implemented as a special process that is automatically started when the system is started, such as “Windows (registered trademark) Service”. Linux (registered trademark) or Unix (registered trademark) can be operated as a daemon process.

  The locator 340 has a function of generating a component. Further, the locator 340 provides a function of returning an access point of another component in response to a request from another component. An access point refers to a TCP / IP listen port. A component acquires an access point disclosed by another component and uses the function provided by that component by accessing the access point. An operation in which a certain component inquires the access point of another component to the locator 340 is referred to as “location query” or simply “query”.

  Among the components constituting the print data conversion unit 330, the proxy module 220, the job controller 230, and the filter host 240 use a service that records the logging data provided by the logger 350 as a log file. Therefore, a query is performed for the purpose of obtaining an access point of the logger 350 with respect to the locator 340. Similarly, the proxy module 220 queries the job controller 230, and the job controller 230 queries the filter A270, the filter B280, and the filter C290. The detailed flow of the query will be described later.

(Job controller)
The job controller 230 requested to execute the job via the proxy module 220 analyzes the job and the print data included in the job and selects a filter necessary for the conversion. In the analysis, a predetermined size is read from the top of the print data, and the type of the print data is determined from the characteristic contents included in the size. For example, data in JPEG format or PDF format is given as input data. Next, the job controller 230 acquires the conversion-destination print data format included in the job, and is necessary for this conversion when both the conversion-source print data format and the conversion-destination print data format are determined. Select a filter group. Necessary combinations of filters and their conversion orders are implemented in the job controller 230 as fixed knowledge.

  After selecting a plurality of necessary filters, the job controller 230 acquires the filter host 240 that has loaded these filters. In this example, filters A 270, B 280, and C 290 are necessary as filters necessary for conversion, and these are loaded in the filter host 240.

  The job controller 230 creates a data transfer channel called a pipeline 300 between the filter A 270, the filter B 280, and the filter C 290. The pipeline 300 basically transfers data only in one direction. The pipeline 300 is configured to go around the job controller 230 → filter A 270 → filter B 280 → filter C 290 → job controller 230. The job controller 230 also creates a pipeline 300 with the proxy module 220. By creating the pipeline 300 in this way, the print data returns from the proxy module 220 to a plurality of components, and finally returns to the proxy module 220 in a form where the conversion is completed.

(Filter, filter host)
The filter is prepared in the form of a library module that implements only data conversion processing. The filter host 240 exists as a process and loads a filter specified at the time of execution. The filter host 240 is in charge of processing such as connection to the control bus 502 and message transmission / reception, generation and connection of the pipeline 300, communication with the job controller 230, and transfer of the log output of the filter to the logger 350.

(Logger)
One logger 350 exists on the same control bus 502 as a process. A component on the control bus 502 outputs a log during job execution. As a log output target, a file is generally used. However, if all components output log files independently, the number of file I / O occurrences on the server PC 80 increases, and the overall performance of the print data conversion unit 330 is increased. Will fall. Therefore, each component sends log data to the logger 350 via the network, and the logger 350 outputs to a log file when a certain amount of log data is accumulated. Settings such as the output path of the log file are specified by a configuration file delivered when the logger 350 is started. Here, data for returning the pipeline 300 will be described. This data is called a “job”.

(job)
The data conversion process is delivered in the form of a job when requested through the API of the proxy module 220. A job is conceptually composed of a data structure called “ticket” in which target data to be converted and setting values for conversion processing are bundled in a coherent format. The job is given unique identification information so that it can be identified (job ID). The generated job is stored as a file in a storage device such as the HDD 102. Further, when taking out from the storage device, it is possible to specify the job ID, acquire the file, and refer to the contents. The act of discarding a job is realized as deleting a file. The job includes the contents of the print data directly in the file, or includes reference information such as a file path of the print data filed. Further, the job includes information about a print file format that can be processed by the printer 60 that performs printing. In addition, print settings for specifying a print processing method such as the number of copies to be printed and a print imposition instruction are included. Hereinafter, an action for processing a job may be referred to as “execute a job”.

(Print data)
Data in a binary format that is created in a format that can be understood by the printer and that can be given to the hardware logic via the memory of the printer is called print data. Alternatively, data described in some description language (PDL) that can be converted into a format that can be processed by the print engine by being given to conversion logic implemented as firmware is called print data. The print data is acquired from a file held in a device such as the personal computer 20, the tablet PC 30 or the portable terminal 40 in FIG. 1 or embedded in a conversion request from the memory. Alternatively, the print data is acquired by extracting a reference (URL or file path) to a file stored in advance in the file server PC 90 of FIG. 1 from the conversion request and acquiring the file contents.

Returning to FIG. 4, the significance and procedure of the component group constituting the print data conversion unit 330 querying other components will be described.
(Significance of query)
Services provided by components are disclosed to other components as endpoints accessible from the network. Specifically, a set of TCP / IP address and port number is disclosed. A component acquires and uses a service I / F provided by another component. There are a plurality of types of components as processes, and a plurality of the same components exist on the same PC. Accordingly, the port number of the service I / F disclosed by each component cannot be fixed, and must be dynamically generated. Dynamically generated endpoints cannot be referenced from others without some sort of management mechanism. The locator 340 manages this end point. Furthermore, there is a need for a means for a component to obtain dynamically generated endpoints of other components. This means is a query. The locator 340 answers this query.

(Component generation)
Components are basically generated dynamically. FIG. 5 is a diagram illustrating a component generation sequence. In FIG. 5A, only the locator 340 exists. This situation corresponds to immediately after the server PC 80 is activated in FIG. At this point, it is assumed that the print data conversion unit 330 has not been activated yet. The locator 340 is connected to the control bus 502 alone.

  The locator 340 holds a service catalog 501 shown in FIG. The service catalog 501 is composed of a list of components installed on the server 80. For each component, the name, version, executable file path, configuration file path at startup, component life, startup mode, and leak amount (leak ratio) are described. The start mode is a mode indicating whether to start on demand or to make a hot standby. The leak amount is a memory leak amount per unit time that occurs with the operation. The component name is expressed in a hierarchical structure as a general name indicating its function. For example, since the function name “FilterHost” is defined under the hierarchy “system”, it has a hierarchical format of “/ system / FilterHost”. Although this name notation is not particularly characteristic of the present invention, it is used to systematically and uniquely name components. Even components having the same name are treated as different entries on the service catalog 501 in order to provide different functions if their versions are different.

  FIG. 5B shows an example in which the startup mode of a certain component A 503 is designated as hot standby (startup). When the locator 340 is activated, the locator 340 refers to the service catalog 501 and finds the component A 503 whose activation mode is designated as hot standby. The locator 340 acquires the path and lifetime of the configuration file 505 from the service catalog 501 and gives them as arguments to start the executable file path program of the component A 503. When the component A 503 is activated, it is given a unique ID when it is connected to the control bus 502. This ID is a GUID in this embodiment, but it may be in other formats. In addition, on-demand is defined in the activation mode. A component having an on-demand activation mode is not automatically activated when the system is activated, and is literally activated only after a query that literally specifies the component is made.

  FIG. 5C shows an example in which the activated component A 503 refers to the contents of the configuration file 505 given at the time of activation, extracts necessary initial values and the like, and initializes itself using the initial values. Show. When the initialization is completed, in order to provide a service, a TCP / IP port is acquired and waiting for the service I / F 504 is started. Since the component A 503 is now ready to provide services to other components, the component A 503 creates its own advertisement message 506 and transmits it to the control bus 502.

  The advertisement message 506 describes the name, ID, version, URL of the service I / F 504, port number, and life of the component A 503. This message is transmitted to locator 340. The advertisement message 506 is an action in which a component declares its own start completion and service provision start. The locator 340 that has received this message can confirm the activation of the component A 503 and can acquire the service I / F.

  FIG. 5D shows an example in which the locator 340 confirms the activation of the component A 503 immediately after receiving the advertisement message 506 from the component A 503 and registers it in the service inventory 507 that is a management table for subsequent management. Show.

  FIG. 8 is a diagram schematically showing the contents of the service inventory 507. In this example, the service inventory 507 includes an ID, a name, a version, a URL, a Port, a life (time), a life (number of jobs), a life time, a state, a start time, and a last contact time. When locator 340 receives advertisement message 506, it creates an entry for each component that is the source of the message. Then, the locator 340 transcribes the content of the advertisement message 506 and registers it in the service inventory. As the contents of the entry, the “survival time” column records the surviving time (in seconds) since the component was created. This survival time is created from the contents of a heartbeat message 508 described later. In the “status” column, a value indicating the status of the component is transferred from a state change message 512 described later. The “activation time” column records the time when the component was activated, and the “last contact time” column records the reception time of the last message received by the locator 340 from the component. In this embodiment, the time is stored as the system time acquired from the operating system. Normally, multiple processes of components with the same name and version are generated. These entries on the service inventory 507 can be identified because at least the ID and the Port number are different from each other.

  FIG. 5E shows an example of receiving a heartbeat message 508 from the component A 503. A heartbeat message is a signal or packet sent to notify the outside that the device is operating normally. Each component is required to periodically send a heartbeat message 508 to the locator 340. By receiving this message, the locator 340 confirms the existence of the transmission source component, and updates the “survival time” column and “last contact time” column of the service inventory 507.

  If the heartbeat message 508 from the component is delayed for a predetermined time, the locator 340 changes the “status” column of this component to “missing”. In this state, when the heartbeat message is further delayed for a predetermined time, the component is automatically deleted from the service inventory 507 for each entry. Components deleted from the service inventory 507 are no longer searched for queries from other components, and services cannot be provided. Since the deletion of the entry is performed based on the ID of the target component, the entry of another component with the same name is not affected.

  FIG. 5F illustrates an example in which the component A 503 transmits a query message 509 to the locator 340 in order to use the component B 514. The query message 509 describes the name of the component B 514 and the version to be used. Multiple versions of a component can be created. A plurality of components with the same name are created due to differences in functions and released to the market as different versions. Therefore, the component A 503 can perform a query by designating the version of the component B 514 that the user wants to use, such as the version “2.0.0.1”. If there is no need to use a specific version, the version field is empty. In the example shown in FIG. 5F, since the component B 514 has not yet been generated, the locator 340 newly generates the component B 514. A component B 514 is generated in the same manner as the component A 503 generation procedure shown in FIGS.

  FIG. 5G shows an example in which the locator 340 returns a response to the query as a query response message 510 to the component A 503. The query response message 510 stores the name and version of the component B 514, the URL indicating the service I / F, and the port number.

  FIG. 5H shows a state where the component A 503 that has received the query response message 510 uses the service I / F of the acquired component B 514. Some components can handle service requests from other services accessing the service I / F at the same time, and others can not. For example, the logger 350 has the ability to receive logging data from a plurality of services in parallel and record them in a log file. On the other hand, a filter that forms a pipeline and converts jobs does not have the capability of simultaneous parallel processing.

  Therefore, assuming that the component B 514 is a component that does not have the simultaneous parallel processing capability, the state transits to a state where a request from another component cannot be accepted, that is, a busy state when the component A 503 accesses. This state continues until the component A 503 declares an explicit access end to the component B 514 through the service I / F. When the component B 514 transitions to the busy state, it is desirable that the component B 514 is not detected by a query of another component other than the component A that wants to use the component B 514.

  Therefore, as shown in FIG. 5I, the component B 514 transmits a state change message 512 to the locator 340. The state change message 512 indicates that the component B 514 has transitioned to the busy state. Upon receiving this message, the locator 340 searches for the entry of the component B 514 registered in the service inventory 507, and transcribes the received state in the “state” column. In addition, the “last contact time” field is also updated. Since the “state” column of the component B 514 is changed to the busy state, the locator 340 does not select an instance of the component B 514 even if it receives a query specifying a name. However, there may be a plurality of other component B processes in the service inventory 507. If any of them is not busy, a response is returned to the component that issued the query as “available component B”.

  Which instance is selected as a query result from a plurality of component instance groups having the same name and version depends on the selection algorithm held by the locator 340. However, since the algorithm is not related to the present invention, the description is omitted.

  FIG. 5J illustrates an example in which a Goodbye message (513) is transmitted immediately before the component B 514 that has reached the end of its life ends itself. Upon receiving this message, the locator 340 deletes the entry for the component B 514 in the service inventory 507.

(Life extension process)
Next, the part related to the operation of the component life which is the main point of the present invention will be described. FIG. 8 shows a functional configuration example of the server PC 80 that performs processing related to component life management. The server PC 80 includes a filter 240 (PDL Filter 450, Layout Filter 460), a locator 340, and a job controller 230. These are extracted main components for executing the processing of the print data conversion unit 330. PDLFilter 450 and LayoutFilter 460 are the same filter components as filter A270, filter B280, and filter C290 in FIG. 4 and are responsible for the data conversion process.

  In the example illustrated in FIG. 8, the PDLFilter 450 includes a font cache unit 1, a cache statistics unit 2, a life extension determination unit 3, and a life management unit 4. The font cache unit 1 searches the font cache by character code conversion processing and uses it if a desired character image exists. The cache statistics unit 2 receives an instruction from the font cache unit 1 and counts and records the number of cache hits and the hit rate for each character type and character code for each job. The life extension determination unit 3 determines the extension of the process execution period and the length of the execution period to be extended. The life management unit 4 manages the life set in the PDLFilter 450, and generates a “life event” to be described later when the remaining life reaches a certain value. Also, the service life setting value is acquired from the locator, and the setting value is reset as its own new service life.

  The locator 340 includes a process management unit 5, a leak management unit 6, a service catalog 501, and a service inventory 507. The process management unit 5 receives a message from each process and executes various processes according to the content of the message. For example, the process management unit 5 acquires a life extension message to be described later from the filter 240 and executes a life extension process to be described later with reference to FIGS. When the lifetime of a certain process is extended, the leak management unit 6 selects a process whose lifetime should be shortened from among currently operating processes. And the lifetime change message which described the negative value with respect to the selected process is transmitted. Further, the job controller 230 and the LayoutFilter 460 include life management units 7 and 8 that manage their own lifespan. When receiving a life shortening instruction from the leak management unit 6, the life management units 7 and 8 reset the life value set in the life management unit 7 and 8 to a specified value.

  In the following description, it is assumed that the PDLFilter 450 is selected as a component whose life is to be extended, and the LayoutFilter 460 and the job controller 230 are selected as components whose life is shortened. In addition, the locator 340 selects a component that shortens the lifetime. The operation of the PDLFilter 450 will be described using a flowchart, and the process for declaring the extension of the lifetime will be clarified. After that, the processing for selecting a component whose lifetime is shortened by the locator 340 having received the declaration will be described, and finally, the processing of the component whose lifetime will be shortened will be described. The CPU 105 of the server PC 80 executes the functions shown in FIGS. 3 and 8 by loading the program stored in the HDD 102 or the ROM 103 into the RAM 104 and executing it.

(PDLFilter processing flow)
First, the processing flow of the PDLFilter 450 will be described. FIG. 9 shows an event loop process (S001) that starts when the PDLFilter 450 is loaded into the filter host 240 and started. The component has a message queue when it is started. The component creates an event corresponding to the message when it receives the message from the control bus 502 that is a means for communicating with the external component, and posts it to the message queue. In addition, the component also creates notifications from internal modules as events.

  Immediately after starting, the PDLFilter 450 executes the initialization process (S100) shown in FIG. The initialization process (S100) is a set of processes for performing various initial settings.

  FIG. 10 is a flowchart for explaining the initialization process of S100. In S101, the PDLFilter 450 analyzes the contents of the configuration file passed at the time of activation and acquires necessary operation parameters. One of the acquired operation parameters is “life”. In S <b> 102, the PDLFilter 450 sets the acquired lifetime in the lifetime management unit 4. The lifetime is a value expressed in seconds. As a function, the PDLFilter 450 takes charge of processing for extracting a character type and a character code from a job flowing through the pipeline 300 (not shown in FIG. 8), creating a corresponding character image, and storing it in print data. Save the created character image in the cache area without deleting it. In S103, the area is initialized.

  Returning to FIG. 9, after the initialization process is completed, the process proceeds to S002. In the processing after S002, the PDLFilter 450 loops indefinitely while waiting for two events. The waiting events are “job execution request” and “life”. First, in step S <b> 002, the PDLFilter 450 determines whether the event received from the job controller 230 is an “execution request”. This job execution request is an event created in response to the job execution request transmitted from the job controller 230 to the service I / F 504 created by the filter. When the “job execution request” is detected in S002, the PDLFilter 450 executes the job execution process in S200. Since the job execution is newly created and the process proceeds on the thread, the process proceeds in parallel with the event loop process (S001). Since job execution processing is state-managed, even if a new job execution request event arrives during job processing, the request is rejected. The job execution process is a process of examining the contents of the job that flows back through the pipeline 300, which is a path of print data created by the job controller 230, and converting the character type and character code included into a character image.

  In the job execution process, the PDL Filter 450 first searches the font cache unit 1 in FIG. 8 for character code conversion, and uses it if a desired character image exists. Also, the PDL Filter 450 aggregates the number of cache hits and the hit rate for each character type and character code in the cache statistics unit 2 for each job and records them as cache statistical information.

  If it is not a job execution request in S002, the process proceeds to S003. In S003, the PDLFilter 450 determines whether it is a “life event”. The life event is an event issued from the life management unit 4. In the life management unit 4, the life specified at the time of activation is subtracted every moment. The life management unit 4 generates and submits a “life event” so that the process stop process is started when the remaining life reaches a certain value.

  In S003, when the PDLFilter 450 determines that it is a life event, the process proceeds to S300. Details of S300 will be described later with reference to FIG. After the process of S300, the process proceeds to S004, and the PDL Filter 450 determines whether to extend the life. If the lifetime is not extended, the process proceeds to S500, and the PDLFilter 450 ends the process. When extending the life, the process proceeds to S400, and the PDLFilter 450 executes the life extension process. Details of the life extension process will be described later with reference to FIG.

  FIG. 11 is a flowchart for explaining the life extension confirmation process. When a life event is detected in S003, the life extension determination unit 3 executes a life extension confirmation process in S300. In S301, the life extension determination unit 3 determines whether or not job execution processing is in progress at the time when a life event is detected. When the job is being executed, only the reception of the life event is stored, and the processing is interrupted until the job execution is completed.

  In S <b> 302, the life extension determination unit 3 predicts the hit rate in the future job from the cache data hit rate (usage rate) in the most recent job held by the cache statistics unit 2. For this prediction, an evaluation method unique to the print data conversion unit 330 can be taken. For example, it is possible to employ an evaluation method such as calculating the average hit rate of the three most recent jobs and further adding a weight to the hit rate of the most recent job. In S303, when the expected value is equal to or greater than the predetermined value, the life extension determination unit 3 determines the life extension of the process and the length of the life to be extended.

  FIG. 12 is a flowchart for explaining the life extension process. In S400, the life extension result determined by the life extension determination unit 3 is inspected. If the life extension is not determined, the end process of S500 is executed and the process ends. In the termination process, resources and memory created during the process are released. When the life extension is determined, the life extension process of S400 is executed. In S401, the life extension determination unit 3 calculates and sets a set value to be set in the life management unit 4 from the determined life length (extension amount) and the current time. Subsequently, in S402, the life extension determination unit 3 creates a life extension message 515 including the length of the life to be extended, transmits it to the locator 340, and ends the process.

(Locator processing flow)
A processing flow performed by the locator 340 that has received the notification in S402 will be described. FIG. 13 shows an event loop process (S1001) that starts when the locator 340 is activated. Since the locator 340 is also a component, it holds a message queue. Unlike other components, the locator 340 does not provide a service I / F, and message exchange with the other components via the control bus 502 is a means of communication with the outside of the process. An event that occurs at that time and a notification from an internal module are created as an event and posted to the previous message queue.

  The locator 340 executes an initialization process (S1100) immediately after starting. The initialization process is a set of processes for performing various initial settings. In S1101, the locator 340 analyzes the contents of the configuration file passed at startup and obtains necessary operation parameters. As described above, the initialization process includes a process of generating a component in which the startup mode is designated as “hot standby” by referring to the service catalog 501. Since the logger 350 is also designated as hot standby, it is generated at this point. When the initialization process in S1100 ends, the process proceeds to message processing (S1002).

  FIG. 14 is a flowchart for explaining message processing (S1002). The messages to be processed are the advertisement message 506, the heartbeat message 508, the query message 509, the state change message 512, the Goodbye message 513, and the life extension message 515 already described. In S1003, locator 340 determines whether or not the received message is life extension message 515. In the case of the life extension message, the process proceeds to S1004, and the life extension process is executed. As many other messages as the number of messages are prepared in association with the determination shown in S1005 and the processing in the case where the determination is Yes. Since messages other than the life extension message 515 have already been described, description thereof is omitted here.

  FIG. 15 is a flowchart for explaining the life extension process. The process management unit 5 processes the life extension message 515. In S1100, the process management unit 5 refers to the service inventory 507 from the source node ID included in the message and identifies the source of the life extension message 515. Here, the PDL Filter 450 is specified.

  In step S1101, the process management unit 5 replaces the lifetime of the PDLFilter 450 in the service inventory 507 with a value obtained by adding the extension amount described in the lifetime extension message 515. Subsequently, in S1102, the process management unit 5 updates the current estimated leak amount and calculates a leak increment that increases with the life extension from the leak ratio of the service catalog 501 and the life extension. The calculated leak increment is input to the leak management unit 6.

  In step S <b> 1003, the leak management unit 6 selects a process other than this process according to the execution period of the extended PDLFilter 450. Specifically, the leak management unit 6 selects a process whose life should be shortened from among the active processes based on the input leak increment. Various methods such as a method of preferentially selecting from those having a high leak ratio and a method of preferentially selecting from the one having a long lifetime can be considered for selection. The leak management unit 6 calculates the amount of leak that increases with the extended lifetime of the PDLFilter 450. Then, the leak management unit 6 calculates a leak amount that decreases as the life of the selected process is shortened by the time when the PDLFilter 450 starts to extend (the calculation method will be described later).

  In S1104, the leak management unit 6 transmits a life change message 516 to the selected process. In S1005, the leak management unit 6 subtracts the leak reduction amount due to the shortening of the lifetime calculated in S1104 from the leak increase amount associated with the extension of the lifetime, and determines whether it has not yet become zero or a negative value (that is, whether the offset has been completed). to decide. Here, the leak increase amount and the leak decrease amount are mainly determined by the execution period of the process, as will be described later. If it is determined that there is no cancellation, the process returns to S1103, and the leak management unit 6 selects another one from other running processes. In S1105, the leak management unit 6 ends the process when there is no process to be selected.

  In FIG. 8, it is assumed that two components of the job controller 230 and the LayoutFilter 460 are selected as targets for shortening the lifetime. The leak management unit 6 transmits a life change message 516 in which negative values are written to both the job controller 230 and the LayoutFilter 460. This message describes the change from the currently set life. If the change is “20”, it means that the life is extended by 20 seconds, and if it is a negative value “−30”, it means that the life is shortened by 30 seconds.

(Processing of components whose life is shortened)
The lifetime reduction message 516 is transmitted to the job controller 230 and the LayoutFilter 460 selected by the locator 340 by calculating the shortening amount of each lifetime. The job controller 230 and the LayoutFilter 460 deliver the life change message 516 to the life management units 7 and 8. Each of the life management units 7 and 8 acquires a life set value from the message, and sets the set value as its own new life.

(Calculation of increase in leak)
The calculation of the leak amount will be specifically described with reference to FIG. FIG. 16 shows the relationship between the time and memory usage of the three components (1) PDLFilter 450, (2) Job Controller 230, and (3) LayoutFilter 460. In FIG. 16A, t1 means the time when the PDLFilter 450 is activated.

  At the time of t1, it is only activated, and the job is not processed, and only the memory required for the operation of the component is ensured. At time t2, PDLFilter 450 starts processing the job. Necessary memory is secured and used according to job processing, but memory used due to a problem in the program is not released and a memory leak occurs. Accordingly, since the leak accumulates as time elapses from t2, the memory usage amount is monotonously increased. In this case, the slope of the straight line differs depending on the value described in the leak ratio of the service catalog 501 shown in FIG.

Here, the lifetime (lifetime) initially set in the PDLFilter 450 is (t3-t1). That is, if the process is terminated at time t3, the memory usage returns to zero. As described above, when the PDL Filter 450 changes (extends) its own end time from t3 to t4, the total amount of memory leak that increases with the extension is represented by ΔS (B). This part means the total amount of wasted memory that could not be diverted elsewhere on the PC. Strictly speaking, t1 and t2 are different, but t2 can be regarded as t1 in the calculation of ΔS (B). Therefore, if the leak ratio is k, ΔS (B) is calculated by the following equation.
ΔS (B) = 1/2 · k · {(t3−t1) + (t4−t1)} · (t4−t3)
Here, k is obtained from the “leak ratio” of the service catalog 501, t 1 is obtained from “start time” of the service inventory 507, and t 3 is obtained from the value obtained by adding “life (time)” of the service inventory 507 to t 1. Further, (t4-t3) is obtained from the “change” of the life change message 516 transmitted by the PDL Filter 450.

Similarly, FIGS. 16 (2) and 16 (3) show changes in the memory usage of a process responsible for a certain job controller 230, and changes in the memory usage of a process responsible for LayoutFilter 460, respectively. It is assumed that the process of the job controller 230 (2) starts at time t5, starts job processing at time t6, and ends at time t7. Here, the end time of the job controller 230 is earlier than the end time of the PDLFilter 450. Therefore, assuming that the job controller 230 that was scheduled to end at time t7 is ended at time t3 (extension start time of the extended PDLFilter 450), the amount of memory in the ΔS (J) portion is reduced from 0 to 0. Will be. Again, ΔS (J) is calculated according to the following equation, where h is the leak ratio.
ΔS (J) = 1/2 · h · {(t3−t5) + (t7−t5)} · (t7−t3)

Further, the LayoutFilter 460 process is scheduled to end at time t10. Assuming that the lifetime of the period corresponding to the extended period from t3 to t4 is shortened, if the leak ratio is g, ΔS (L) is Calculated by the formula.
ΔS (L) = 1/2 · g · {(t3−t8) + (t4−t8)} · (t4−t3)
Therefore, a process that satisfies the following expression is selected from the components currently being executed.
ΔS (B) <= ΔS (J) + ΔS (L)
The leak management unit 6 controls the selected process so as to shorten the lifetime.

  As described above, according to the system of the present invention, it is possible to realize the continuation of the use of a process having a high cache data usage rate while suppressing the occurrence of a memory leak. Specifically, in the first embodiment, when it is determined that the extension of the lifetime of a component whose lifetime is approaching is effective, the extension is notified to the locator 340. The locator 340 can select an appropriate component for the purpose of offsetting the increase in leakage and shorten its lifetime.

(Example 2)
In the first embodiment, the component desiring to extend the lifetime determines the extension by itself, and transmits the determination to the locator 340 as the lifetime extension message 515, thereby determining the extension. The locator 340 that has received the life extension message 515 orders other components to shorten the life in order to offset the amount of leakage that increases with the life extension. In this system, the extension decision and the extension amount do not reflect the status of other components, so in some cases, there may be a shortage of components available for offsetting. In that case, the system will increase leakage.

  In the second embodiment, although the component that desires the extension of life calculates the necessity of extension and the extension period, the component is transmitted to the locator 340 as an extension request, and the extension of the lifetime is performed according to the pros and cons of the extension included in the response. Run. The locator 340 searches for a component that is being executed when a lifetime extension message is received, determines a component whose lifetime can be shortened, and responds to the lifetime extension. According to this embodiment, it is possible to meet a request for limiting the leak amount of the entire system rather than the processing efficiency.

  FIG. 17 shows an event loop process (S005) that starts when the PDLFilter 450 in the second embodiment is loaded into the filter host 240 and activated. Compared to the event loop process (S001) in the first embodiment, the determination in S006 and subsequent processes are added. Further, the life extension process in S400 is changed to the life extension request process in S410. Only the changes will be described below. The same description as that of the first embodiment can be applied to the description of the processing steps without change.

  After the initialization process of S100 is completed, the process loops waiting for the arrival of events in S002, S006, and S003. The life management unit 4 posts a “life event” to the PDLFilter 450 because the life is approaching. In S003, the PDLFilter 450 detects a “life event”. Thereafter, the life extension confirmation process of S300 is executed, and the necessity and extension amount of the life extension are calculated. In step S5300, the PDL Filter 450 executes a life extension confirmation process. If the result of S5300 is inspected and extension is necessary, the life extension request process of S410 in FIG. 18 is executed. As shown in FIG. 18, in S411, the life extension determination unit creates a life extension message 515 and transmits it to the locator 340.

  Thereafter, the PDLFilter 450 waits for arrival of a “life extension response message” from the locator 340. In S006, the PDLFilter 450 detects a life extension message. In S007, the PDL Filter 450 analyzes the content of the message. If the result in the message indicates that the life extension has been determined, the process proceeds to S420. In S420, the PDL Filter 450 acquires the life extension amount described in the response message and sets it in the life management unit 4. At this point, the new life is determined and the life of the PDLFilter 450 is extended. If it is described in S007 that the extension of life has been rejected in the message, the process proceeds to S500, and the PDL Filter 450 ends the process.

  FIG. 19 is a flowchart for explaining message processing of the locator 340. Compared to the first embodiment, the life extension process (S1006) is changed. In S1003, the locator 340 receives the life extension message 515, and the process proceeds to S1006.

  FIG. 20 is a flowchart for explaining the details of the life extension process (S1006). In step S1100, the process management unit 5 refers to the service inventory 507 from the transmission source node ID included in the message, and identifies the transmission source of the life extension message 515. Here, the process management unit 5 identifies the PDLFilter 450. Subsequently, a leak increment that increases with the life extension is calculated from the leak ratio of the service catalog 501 and the extension of the life (S1102). The calculated leak increment becomes an input to the leak management unit 6.

  In step S1003, the leak management unit 6 selects a process whose life should be shortened from among the currently operating processes. The leak management unit 6 calculates the leak amount that increases with the extended life of the PDLFilter 450. Then, the leak management unit 6 calculates the amount of leak that decreases as the life of the selected process is shortened by the time when the PDLFilter 450 starts to extend.

  In S1104, the leak management unit 6 transmits a life change message 516 to the selected process. In S1005, the leak management unit 6 subtracts the leak reduction amount due to the shortening of the lifetime calculated in S1104 from the leak increase amount associated with the extension of the lifetime, and determines whether it has not yet become zero or a negative value (that is, whether the offset has been completed). to decide. If it is determined that the offset has not been made, the process returns to S1103, and the leak management unit 6 selects another process from other running processes.

  In S1105, if the execution process subject to the life reduction is exhausted, the loop is exited and the process proceeds to S1101. At this point, the amount of leakage reduction of the process selected as the life shortening target is determined. The process management unit 5 calculates the life extension amount of the PDLFilter 450 based on the reduction amount.

  The process management unit 5 replaces the lifetime of the PDLFilter 450 in the service inventory 507 with a value obtained by adding the calculated extension amount (S1101). In step S1106, the process management unit 5 creates a response message describing the calculated life extension amount, transmits the response message to the PDLFilter 450, and ends the process. As can be understood from this processing flow, unlike the first embodiment, in this embodiment, the component for which the lifetime is to be shortened is selected first, and then the extension period of the component whose lifetime is desired to be extended according to the determined reduction amount. Will be confirmed. In this embodiment, a print data conversion service is provided in which suppression of an increase in system leakage is more important than efficiency.

(Other embodiments)
The present invention can also be realized by executing the following processing. That is, software (computer program) that implements the functions of the above-described embodiments is supplied to a system or apparatus via a network or various storage media. Then, the computer (or CPU, MPU, etc.) of the system or apparatus reads out and executes the program. In this case, the program and the storage medium storing the program constitute the present invention.

Claims (9)

A system for executing a plurality of processes with a predetermined execution period,
An extension means for extending the execution period of the first process based on the usage rate of the cache data;
Shortening means for shortening the execution period of the second process other than the first process based on the extended execution period of the first process;
And a termination unit that terminates the process whose execution period has ended. A calculation means for calculating a memory leak that increases as the execution period of each process elapses;
The said shortening means shortens the execution period of one or several said 2nd processes so that the amount of memory leaks in the execution period of the said extended 1st process may be offset. The described system. The shortening unit calculates a memory leak amount in the execution period of the shortened second process, and the memory leak amount in the execution period of the extended first process is not offset by the calculated memory leak amount The system according to claim 2, wherein another second process is selected and the execution period is shortened. The said shortening means shortens the execution period of the said 2nd process which is starting and the usage rate of the said cache data is low or has a long lifetime. The one of the Claims 1 thru | or 3 characterized by the above-mentioned. The system according to one item. The shortening means shortens a period corresponding to the extended execution period of the first process from the execution period of the second process, and the end time of the execution period of the second process is the first process. If the execution period is earlier than the end time of the second process, the period from the end time of the second process to the extended start time of the extended execution period of the first process is shortened from the execution period of the second process. The system according to any one of claims 1 to 4, characterized in that: If the amount of memory leak in the extended execution period of the first process is not offset even if the execution period of the second process is shortened, memory leaks in the execution periods of all the shortened second processes 6. The apparatus according to claim 1, further comprising a determination unit configured to calculate an amount and determine an extension period of the execution period of the first process based on the calculated memory leak. system. The system according to any one of claims 1 to 6, wherein data conversion processing requested by an external device is performed by the plurality of processes. A method of controlling a system that executes a plurality of processes with a predetermined execution period,
An extension step of extending the execution period of the first process based on the usage rate of the cache data;
A shortening step of shortening an execution period of a second process other than the first process based on the extended execution period of the first process;
And a termination process for terminating the process whose execution period has been terminated.   A computer program for causing a computer to execute the control method according to claim 8.

Images