CN108139926A - Background job processing framework - Google Patents

Abstract

The described technology relates to scheduling jobs of multiple types in an enterprise network application. The processing system configures a job database having a plurality of job entries and concurrently executes a plurality of job schedulers independently of each other. Each job scheduler is configured to schedule for execution jobs in the job database having a type different from the types of jobs that other job schedulers of the plurality of job schedulers are configured to schedule. The processing system also causes execution of a job scheduled for execution by any of the plurality of schedulers. Method and computer-readable medium embodiments are also provided.

Description

Background job processing framework

Cross References to Related Applications

This application claims the benefit of priority from Indian Patent Application No. 2344/DEL/2015 filed on July 30, 2015, the entire content of which is incorporated herein by reference.

Background technique

Many enterprise software applications are designed as web-based applications ("web applications") so that they can be accessed from anywhere and/or using virtually any processing device that can run a web browser. A web application includes client-side and server-side components that communicate with each other using protocols, including the HTTP protocol. Client-side components of a web application are typically responsible for handling the user interface by presenting (eg, displaying) information to the user via the user interface on the user's access device, receiving user input, and the like. Server-side components are responsible for tasks that include generating information themselves or retrieving information from data sources for presentation to the user in accordance with received input.

Enterprise web applications typically run many different types of background jobs that are subject to various resource and time constraints. For example, an investor relations application ("IR application") designed primarily to serve an investment advisor to a business may be required to support concurrent jobs for handling user interface input from multiple users, receiving current investment information from external sources, downloading Investment research reports, receiving estimated information about financial products, processing investment alerts, e-mails, records, etc. Typical job mixes vary in application and/or in time in many ways, including duration of jobs, number of jobs of a particular type, frequency of occurrence of jobs, and so on. Several scheduling frameworks exist for scheduling jobs for execution. However, as applications evolve with different types of jobs and end-user needs, an improved scheduling framework for handling various job mixes is still desired.

Copyright Notice

Portions of the disclosure of this patent document contain material that is subject to copyright protection. The copyright owner has no objection to anyone's facsimile reproduction of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright whatsoever.

Contents of the invention

According to some example embodiments, there is provided a server system comprising at least one memory and a processing system having at least one processor. The processing system configures a job database with a plurality of job entries, and executes a plurality of job schedulers concurrently and independently of each other. Each job scheduler is configured to schedule, for execution, jobs in the job database of a different type than the types of jobs that other job schedulers of the plurality of job schedulers are configured to schedule. The processing system also causes execution of jobs scheduled for execution by any of the plurality of schedulers.

The plurality of schedulers may include an on-demand scheduler operative to schedule jobs of a first type on an on-demand basis, an on-demand scheduler operative to schedule jobs of a second type that recur at intervals less than a predetermined duration. A short interval scheduler for jobs, and a scheduled job scheduler operative to schedule jobs of a third type at predetermined specific times or at intervals greater than a predetermined duration. The on-demand scheduler and the short interval scheduler execute periodically based on respective timers and cause jobs of the first type and the second type, respectively, to be executed without additional scheduling steps. Jobs of the third type are executed according to a scheduling algorithm.

A job may be determined to correspond to one of the different types of jobs according to the urgency and/or frequency with which the job is to be performed.

The on-demand job scheduler may at least include a high-priority scheduler and a low-priority scheduler, wherein the high-priority scheduler is configured with greater job processing capability than the low-priority scheduler. The on-demand job scheduler may be configured to allocate a first number of threads to the high priority job scheduler and a second number of threads (fewer than the first number of threads) to the low priority job scheduler.

The high-priority job scheduler and the low-priority job scheduler may each be respectively configured to access a job entry in the job database, add a job corresponding to the retrieved job entry to a queue in memory, and cause Queue supply jobs.

The high priority job scheduler may be configured to determine its current processing capacity prior to retrieving and adding, and only perform the retrieving and adding if the processing capacity is determined to be above a specified threshold. The current processing capacity may be determined based on the current occupancy of a queue in memory associated with the high priority job scheduler.

The short-interval job scheduler may be invoked at intervals of a first duration, where the first duration is determined based on configured execution intervals of the plurality of job configurations. The execution interval may be specified in an XML file including the plurality of job configurations.

The scheduled task scheduler is configured such that jobs are executed at times determined according to a scheduling algorithm.

Each job may include an object implementing an execute method that is invoked by a corresponding scheduler of the plurality of schedulers in order to run the job.

The multiple schedulers can be spawned by the same Windows® service. Each of the schedulers may be configured to transmit a heartbeat, wherein the Windows service determines the health of each of the schedulers based on the heartbeat.

Each of the schedulers is implemented as a proxy with a correspondingly configured thread pool.

Another example embodiment provides a method that includes configuring a job database having a plurality of job entries in a memory communicatively coupled to a processing system having at least one processor. The method also includes executing a plurality of job schedulers concurrently and independently of each other on the processing system, each job scheduler configured to schedule jobs in the job database with A different type of job is configured to be scheduled for execution than the type of job. Still further, the method includes causing execution of jobs scheduled for execution by any of the plurality of schedulers.

Another example embodiment provides a non-transitory computer-readable storage medium having stored thereon instructions that, when executed by a processing system having at least one processor, cause the processing system to perform operations. The operations include configuring a job database having a plurality of job entries in memory communicatively coupled to the processing system. The operations also include concurrently and independently of each other executing a plurality of job schedulers, each job scheduler configured to schedule a job in the job database having a The types of jobs are different types of jobs to execute. Still further, the operations include causing execution of jobs scheduled for execution by any of the plurality of schedulers.

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter; rather, this Summary is intended to provide an overview of the subject matter described in this document. In summary. Accordingly, it will be appreciated that the features described above are examples only, and that other features, aspects and advantages of the subject matter described herein will become apparent from the following detailed description, drawings and claims.

Description of drawings

FIG. 1 illustrates an example computing environment in which an enterprise network application, such as an example IR application, may run in accordance with some embodiments;

Figure 2 schematically illustrates some aspects of the scheduling framework shown in Figure 1, according to some embodiments;

Figure 3 illustrates an example class model that may be used in the scheduling framework shown in Figure 2 in some example embodiments;

Figure 4 illustrates abstract classes and interface classes used to implement each background job in the system, according to some embodiments;

Figure 5 illustrates a class framework for a scheduler for on-demand jobs, according to some embodiments;

Figure 6 is a schematic illustration of an execution environment for an on-demand scheduler agent, according to some embodiments;

Figure 7 illustrates a process for an on-demand scheduler, according to some embodiments;

Figure 8 illustrates an example XML configuration file for use by a short interval job scheduler, according to some embodiments;

Figure 9 illustrates a flow diagram of a process performed by the short interval scheduler to configure its timer firing interval, according to some embodiments;

Figure 10 illustrates a flow diagram for a process for a short interval scheduler, according to some embodiments;

Figure 11 illustrates a portion of an example XML configuration file for a scheduled agent, according to some embodiments;

Figure 12 illustrates an example scheduler class that may be used by a scheduled agent for use and/or adapted to a third-party scheduler, according to some embodiments;

Figure 13 shows an example table of job type to machine mappings according to some embodiments; and

Figure 14 shows an example block diagram of a hardware architecture for the system shown in Figure 1, according to some embodiments.

Detailed ways

Embodiments described herein relate to scheduling multiple types of jobs in enterprise network applications. In some example embodiments, multiple schedulers are started, each scheduler programmed to schedule a different job type than the other schedulers. By having each concurrent scheduler operate independently of the others to improve (eg, optimally perform) the scheduling of background jobs with certain common timing requirements and/or other common characteristics, the entire job mix can be more efficiently scheduled to available for execution (for example, to be run by a processor) while satisfying the timing constraints of each type of job. This can achieve significant efficiency gains over conventional scheduling techniques where, in applications, many types of jobs are handled by a single type of scheduler.

Embodiments described herein may be used to improve the overall performance of enterprise network applications such as, but not limited to, the example IR applications mentioned above. As mentioned above, an IR application can have many types of jobs executing concurrently at any given time. For example, on a server system running a web application, numerous background jobs may be started to handle communications with many client-side user interfaces. Other operations may include acquiring, processing, and delivering financial information from external services, database queries, research reports, estimates, news, alerts, etc.; email sending and receiving; file sending and downloading; archiving; and system maintenance, etc.

FIG. 1 illustrates an example computing environment 100 in which enterprise network applications, such as the example IR application, may run in accordance with some embodiments. In computing environment 100, client system 102 and server system 104 communicate with each other over network 108 to enable use of network applications, such as, for example, IR applications. It should be appreciated that network 108 may include a network of interconnected computing devices, such as the Internet. Network 108 may also include a local area network (LAN) and/or include a point-to-point connection between client system 102 and server system 104 .

The web application includes a client-side web application component (“client-side application”) 110 executing on client system 102 and a server-side web application component (“server-side application”) 112 executing on server system 104 . The client-side application 110 may execute within a user interface application 114 such as, for example, a browser 114 . Dashboard 128 may be part of client-side web application 110 , operating as a user interface and/or landing page (eg, the first page that appears when a user accesses the IR application). Dashboard 128 may provide summarized information for various aspects of the web application, eg, in corresponding widgets. Server-side applications 112 may be executed by web server 116 and/or application server 118 of server system 104 . Web server 116 performs functionality such as implementing the HTTP protocol and communicating via HTTP with web browser 114 in client system 110 (described in further detail below). Data items related to web applications—such as, for example, configuration and/or execution data, user access, etc.—may be stored in database 120 of server system 104 . Application server 118 may, for example, execute server-side (or "back-end") application services. While executing a web application, web server 116 and/or application server 118 may access one or more external data sources 122 over network 108 for information. In some embodiments, web server 116 and application server 118 may operate as one process (or the same group of processes).

Client system 102 may include software components for performing processes involving applications defined according to a number of single page applications (SPAs) or other architectures. As a non-limiting example, the client system 102 may have a web browser application 114 including at least a rendering module, a networking module, and a JavaScript® module (not separately shown). The rendering module may implement functionality for graphic display and rendering of web pages. It may, for example, generate graphics data corresponding to the HTML and/or DOM defining the web page processed by the web browser 114 . This graphical data may be displayed on a display of the client system 102 , potentially after further modification/transformation by the operating system of the client system 102 . Alternatively or additionally, whenever a web page is rendered/displayed for client system 102 as described in this document, the rendering/display module may perform functionality related to the rendering/display of the web page. The networking module may implement the HTTP protocol and be used to handle various HTTP messages between the web server 116 in the server system 104 and the client system 102 . Alternatively or additionally, whenever it is described in this document that client systems 102 communicate using HTTP, the networking module may handle the HTTP aspects of such communications. The JavaScript module can be used to execute JavaScript scripts, manipulate JavaScript objects, modify the DOM of a web page loaded at the web browser application 114, and perform other functionality involving JavaScript. A JavaScript module may be, for example, a JavaScript engine, a JavaScript virtual machine, a JavaScript runtime, or any other type of software module capable of executing JavaScript instructions. Alternatively or additionally, whenever it is described in this document that client system 102 performs functionality involving JavaScript, such functionality may be handled by a JavaScript module.

The scheduling framework 124 may be used to schedule various jobs that handle aspects of network applications, as well as other jobs that handle system tasks involving the server system 104 . For example, various parts of the web application may write entries to a job queue and/or job database 126 from which scheduling framework 124 will serve those jobs, according to an embodiment.

Although one client system 102 is shown in FIG. 1, it will be appreciated that server system 104 may communicate with any number of client systems, such as client system 102, to provide users of those client systems with Applied services. Also, while shown as one system 104, those skilled in the art will appreciate that the server system may include any number of single-processor and/or multi-processor computers communicatively interconnected. In some embodiments, server system 104 may operate in a server farm and/or cloud service environment. Components of server system 104, such as web server 116, application server 118, database 120, server-side web application 112, scheduling framework 124, and job queue/job database 126 may accordingly be distributed across multiple processors and/or computers.

Figure 2 schematically illustrates some aspects of the scheduling framework 124 shown in Figure 1, according to some embodiments. The scheduling framework 200 includes at least three scheduling agents 204, 206, and 208 that run concurrently with each other. Each of scheduling agents 204, 206, and 208 is configured to handle a particular type or group of types of jobs that are different from the types of jobs handled by the other scheduling agents. In some embodiments, the scheduling agents 204, 206, and 208 are configured to handle the first, second, and third job type groups (each of one or more job types) such that no jobs exist between the scheduling agents. Overlap in terms of types. Handling the job includes causing the particular job to be executed by the processor based on the entry found in the job queue/job database (eg, 126 in FIG. 1 ) for the particular job. For example, one of the schedulers 204-208 may handle the job in the job queue 126 by retrieving an entry for the file download job from the job queue 126 and causing the corresponding file download job to execute on the processor. The schedulers 204-208 may cause the jobs to be executed by starting them themselves or causing a helper process to start executing the jobs on the selected processors.

The scheduling agent 204 is configured to handle on-demand jobs and will be referred to herein as an on-demand scheduling agent (or on-demand scheduler) 204 . The on-demand scheduler 204 is configured to handle on-demand jobs. That is, the on-demand scheduler 204 is configured to handle jobs that should be processed on a "as soon as possible" (eg, "run now or as soon as possible") basis. Typically, in environments such as IR applications, user interface interactions require processing on an on-demand basis. For example, a web application may be driven so as to minimize the response time perceived by the user when interacting with the user interface (e.g., dashboard 128), and thus will require frequent and immediate or near-immediate (e.g., with minimal delay) processing User interface input. Example jobs initiated by a user via the user interface may include generation of reports, and/or downloads of research reports, pdf binding jobs in response to user requests, and the like.

Scheduling agent 206 is referred to herein as a short interval scheduling agent (short interval scheduler), and is configured to handle jobs that require repeated execution in relatively short intervals. For example, sending and receiving emails, writing to log files (e.g., logging user interactions), frequently downloading updated information from subscribed services, updating information displayed on various widgets on the dashboard 128 from Information from external data sources, etc.

Scheduler agent 208 is referred to herein as a scheduled agent. A scheduled agent is configured to handle jobs that run relatively frequently. These can include one-time jobs that can be scheduled some time in the future as well as recurring jobs that run at relatively large repetition intervals (eg, hours). Example scheduled tasks may include system cleanup jobs, daily backups of web applications, searches (eg including building indexes at hourly or daily intervals, based on which textless searches can be performed).

Agents 204-208 are spawned by a single process during system and/or network application startup. In an example embodiment, a Windows Services ^™ job—host 202—that starts when web server 104 starts a server-side web application (eg, a server-side application processing the example IR application) spawns three schedulers 204-208. Host 202 may then operate to stop schedulers 204-208 upon receipt of a user command and/or upon network application shutdown. When multiple job servers exist, as is often the case in enterprise systems, spawning agents 204-208 by a single process makes deployment and configuration easier, and thus improves maintainability. Having a single process also facilitates enabling or disabling specific types of agents 204-208 on machines based on need via centralized configuration (rather than conditional deployment), and gives more flexibility for tuning based on requirements.

Each of the schedulers 204-208 may regularly communicate with or post entries to the database 210 at configurable intervals. The system (or host 102) can use these communications and/or entries as a heartbeat mechanism to monitor the status of each scheduler. For example, if any particular scheduler fails to update the corresponding heartbeat 216 at the database 210 within a configurable interval, the host computer 102 monitoring the database at regular intervals can determine that that particular scheduler is no longer valid, and can start the corresponding scheduler's instance.

Database 210 may also include job entries 218 . A job entry 218 represents a job to be executed. Entries for a particular job may be in database 210 as database entries and/or in one or more job queues. For example, each job operating in a web application (e.g., web server, application server, e-mail server, logging application) may make an entry into database 210 (or queue into a job queue in database 10), so The above entries represent jobs that are required to run. Each entry may e.g. identify the type of job (e.g. job type identifier) and the parameters required to execute the job (if any) (e.g. location and filename of file to download, send/receive from queue Email does not require parameters, etc).

At least some of the schedulers 204 - 208 are driven by a timer 212 . For example, both on-demand dispatch agent 204 and short interval dispatch agent 206 are triggered by configured timer firings. Each of 204 and 206 executes or causes the operation for which it is configured to be executed when its respective timer fires. The timer firing can be viewed as a checkpoint for agents 204 and 206 to see if more jobs can be processed.

However, the scheduler 208 is scheduled because it determines the execution time for each of its jobs according to a scheduling algorithm. In some example embodiments, the scheduled agent 208 relies on off-the-shelf scheduling components, such as, for example, Quartz.Net®. An adapter 214 may be used to interface with off-the-shelf scheduling components, and a separate database 215 may be used for scheduled jobs (eg, for maintaining job entries for scheduled jobs).

FIG. 3 illustrates an example class model that may be used for scheduling framework 200 in some example embodiments. Each of the schedulers 204-208 is derived from the abstract proxy class 302. Abstract class 302 provides for heartbeat timer 312 and methods 314 and 316 to start the heartbeat timer and check whether the heartbeat timer has expired, respectively. Agent type 318 is provided so that each of agents 204-208 can be identified as to whether it is an on-demand, short-interval, or scheduled agent. The abstract class 302 also provides a run method 320 implemented by each of the classes derived from the abstract class to run the corresponding scheduler.

On-demand dispatch proxy 204 may be created in accordance with on-demand proxy class 304 derived from abstract class 302 . The on-demand agent class 304 includes a timer 322 , a high priority job manager 324 and a low priority job manager 326 . The separation of high-priority and low-priority job managers helps avoid pre-emption or exclusive waiting for certain low-priority jobs, even when there are a large number of high-priority jobs to run. The operation of the high priority job manager and the low priority job manager is described further below.

The short interval scheduling agent 206 may be created in accordance with the short interval scheduling class 306 . The short interval agent class 306 includes a timer 332 , a list 334 of jobs to execute, and an execution summary 336 . The agent may maintain a list of jobs executed and the amount of work done by each job in an execution summary 336 . Execution summary 336 enables execution details of jobs to be buffered by the agent and then written to the database in batches in the background. Since short-interval jobs are typically very frequently run jobs, updating their status in the database in real time would add a significant amount of network traffic and would slow down the agent.

The timers in the short interval agent class can be pre-configured or can change dynamically over time. When determining it is time to run a particular job type (for example, an email send/receive job) based on the configured recurrence interval, the short interval scheduler can poll the job database and/or the email queue to determine if there are any jobs to send or receive any pending emails and spawn one or more tasks accordingly to handle emails to be sent or received.

A scheduled agent 208 may be created in accordance with a scheduled agent class 308 . The scheduled proxy class 308 includes a scheduler 342 for scheduling using a third-party scheduler, such as Quartz.net. Scheduling can include using complex algorithms to determine the optimal scheduled time for each job. The job type id 344 in the configuration helps the QuartzJobAdapter to instantiate the corresponding job class. A mapping can be maintained between job type ids and classes to instantiate in configuration. The scheduled agent may also include a method 346 to remove unauthorized jobs. For example, when the agent is initialized, such removal may be based on a list of jobs capable of running (eg, authorized to run on the machine) on the machine provisioned from the configuration.

FIG. 4 illustrates an interface class iJob 402 and an abstract class job 404 implementing the iJob 402 class. Every job to be run on server system 104 is required to implement interface iJob 402 and/or inherit from abstract class 404 . The scheduler can then run the job by calling the Run method it implements.

FIG. 5 illustrates a class framework for the on-demand scheduler agent 204 . An onDemandAgent class 502 may be used to create an onDemandAgent agent 204 . As noted above with respect to class 304 in FIG. 3 , on-demand broker class 502 may include two job managers—high priority job manager 504 and low priority job manager 506 .

High priority job manager 504 and low priority job manager 506 may each be created using job manager class 510 . The high-priority job manager and low-priority job manager perform all job processing on behalf of the on-demand scheduler agent. By having multiple priority levels within a class of on-demand jobs, embodiments enable improved response times for most time-critical jobs. For example, certain user interface requests, such as the display of real-time or near-real-time financial information on user demand, may be prioritized over other on-demand jobs, such as pdf binding of several files and downloading of large files.

Of course, in addition, or as an alternative, on-demand jobs may be prioritized according to criteria other than just job type. For example, a pdf binding job for a particular user or class of users may be designated as a low priority on-demand job, while a job of the same type for another class of users may be designated as a high priority. This provides a lot of scheduling flexibility that can be achieved through configuration.

Job manager class 510 field job priority 512 may be used to indicate whether the manager is a high priority job manager or a low priority job manager. Each manager may also be configured with a job queue 514 that it has access to and from which it retrieves jobs for execution. A maximum concurrency level 516 is specified for each type of manager. The concurrency level represents the number of concurrent threads the manager is authorized to (or configured to be) open. In fact, priority can be controlled by giving higher-priority job agents a higher level of concurrency than lower-priority job agents. Job manager 510 may maintain a shared task factory 518 that is passed to each job runner 512 instance. A job runner can internally use tasks from a shared task factory in order to execute jobs. This can help the job manager 510 monitor the number of created tasks and their status, and thereby control concurrency. Task scheduler 520 may be a configuration class where a maximum degree of parallelism may be configured, which is then supplied to task factory 518 .

The job manager class 510 is also provided with a method 522 for filling a queue and a method 524 for processing a job from which the manager then obtains the job for execution.

The job manager can run each job using a separate job runner, represented by job runner class 512 . Each job manager can have several job runners that process jobs concurrently. The number of job runners started by a job manager may be limited to the maximum concurrency level configured for that job manager. The job runner class 512 provides methods 532 for synchronous execution of jobs, where a particular job runner running a job will wait until the job is completed, and methods 534 for asynchronous execution of jobs, where a particular job runner will wait until the job is completed Returned before the current job was completed. For long-running jobs, such as file downloads, asynchronous execution may be desirable. The update job queue with job status (updateJobQueueWithJobStatus) 536 in each job runner uses the execution status—success/failure, completion time, agent, machine name, etc.—to update the corresponding job queue entry. This can be used by the requester of the job to check if the job is complete. For example, updateJobQueueWithJobStatus 536 in the corresponding job runner 512 may be used to notify the user interface component requesting the report creation of the completion of the report creation.

FIG. 6 is a schematic illustration of an execution environment 600 for an on-demand scheduler agent. Execution environment 600, which may be part of server system 104, may include one or more processing units 602 (eg, processing units 602a and 602b) communicatively coupled. The processing units may be separate cores of the same processor, or separate processors on the same computer or on physically separate computers. Each processing unit may have access to a separate memory and/or a common memory. Each processing unit 602 may have access to one or more in-memory queues 610 (eg, in-memory queues 610a and 610b) for on-demand jobs.

Each processing unit 602 may have an on-demand scheduler agent 608 (e.g., agents 608a and 608b) running on it and/or may have a high-priority job manager for on-demand jobs running on it and a or one or more of multiple low-priority job managers.

Configuration database 604 may provide one or more job tables/queues in which jobs to be executed are written by various applications. The scheduler can pick up jobs to run from these job tables/queues.

XML configuration 606 may provide configuration for job scheduling and the like. For example, an XML configuration can specify that a job to be written to the log be executed every 5000 milliseconds. When the appropriate scheduler determines that it is time to run the job to be written to the log, it determines from the database 604 the actual log entry to be written.

In some embodiments, database 640 is shared by all processing units 602 in the scheduling framework. On the other hand, an in-memory queue for on-demand jobs may be in local memory of each processing unit.

FIG. 7 illustrates a process 700 that may be used by an on-demand scheduler agent to schedule on-demand jobs, according to some embodiments. For example, each of the high priority job manager and the low priority job manager may perform process 700 .

Process 700 may be continuously executed by a running high-priority job manager or a running low-priority job manager based on timer firing. For example, process 700 is entered by each high or low priority job manager when that job manager starts up. After entering process 700, the job manager may wait for a timer to fire (eg, a signal indicating expiration of the timer). In an example embodiment, the on-demand job timer is configured at 5 seconds. That is, the on-demand job timer will fire (eg, expire) every 5 seconds until terminated.

At operation 702, a timer firing signal is received and an iteration of processing an on-demand job begins. As noted above, the timer may be a timer shared by all on-demand job scheduling agents and/or on-demand job managers on a particular processing unit, or in some embodiments each on-demand scheduling agent may have its own timer.

At operation 704, an amount of free capacity in a queue in memory used by the on-demand job manager is determined. Each job manager maintains one or more in-memory queues from which it (the job manager) retrieves jobs to be run by the job runner. The size of the queue in memory may be configurable. There may also be a configurable refill threshold associated with each in-memory queue, representing the memory occupied (i.e., filled with jobs) before the corresponding job manager refills the in-memory queue with jobs from the job database The smallest part of the queue in .

At operation 706, the determined free capacity of the queue in memory is compared to the concurrency threshold for the job manager. As described above, separate concurrency levels may be set for high-priority on-demand job managers and low-priority on-demand job managers. At operation 706, the amount of capacity of the queue in memory that is free is compared to the concurrency level for the job manager.

At operation 708, a determination is made as to whether a new job can be added to the queue in memory based on a comparison of the amount of queue capacity in free memory compared to the concurrency level.

If the determination at 708 is yes, then at operation 710 a new job is retrieved (eg, removed) from the database and added (eg, written or queued) to a queue in memory. The number of jobs added may be based at least in part on the capacity of the queue in memory and/or a configured maximum fraction of the capacity of the queue to use.

For example, consider the case where the concurrency level for the high priority job manager is set at 100, which indicates that the high priority on-demand job scheduler can have up to 100 concurrently running jobs. The queue in corresponding memory may have a maximum capacity of 200, indicating that the queue may hold up to 200 jobs at a time. Also assume that at operation 704, it is determined that the free capacity corresponds to 120 jobs.

Now, after operation 706, a comparison of free capacity and concurrency level is made, it can be determined at operation 708 that up to 120 new jobs can be added to the queue in memory. The full capacity of the queue of 200 jobs in memory can be filled with that many jobs. Alternatively, a configuration setting may specify that no more than 120 jobs be populated at any one time by adding jobs from the database. When this configuration of reduced thresholds from the maximum capacity is provided, only up to the configured threshold will be filled with jobs retrieved from the database. Thus, at any time, the on-demand scheduler can have some excess capacity that can be used to run jobs that the system can allow to run without going through the job database, such as for example additional jobs created by already running jobs. Jobs that require fast response times.

The above process (process 700 ) enables scheduler agents to cooperate across separate processing units to optimally schedule jobs.

FIG. 8 illustrates an example XML configuration file 800 for use by a short-interval job scheduler, such as short-interval job scheduler 206 , according to some embodiments. For example, at startup and/or at regular intervals, short interval job agent 206 may read configuration file 800 from memory.

Configuration file 800 specifies the types of jobs to be run by the short interval scheduling agent and when such jobs should be run. Each job to run can be specified in a line entry. For example, a line entry may include a job name 802, a job type 804, and an interval 806 at which to run the job.

FIG. 9 illustrates a flow diagram of a process 900 that may be performed by a short interval scheduler (such as, for example, short interval scheduler 206 ) to dynamically configure its firing interval.

Process 900 may be performed by short interval scheduling agent 206 at startup and/or at predetermined regular intervals. It may also be called when changes are made to the configuration, such as, for example, by adding a job to the XML configuration 800 .

After entering process 900, at operation 902, a minimum repeat interval can be determined from the jobs listed in the configuration. For example, considering the jobs listed in file 800 in FIG. 8 as an example, 1000 milliseconds for the dashboard queue processing job and 1000 milliseconds for the alert dispatcher job may be determined to provide a minimum repeat interval.

After determining the minimum repeat time at operation 902 , a short interval job timer may be configured at operation 904 to the determined time.

By causing the process 900 to run when, for example, any new job is added or an existing job is changed, in the configuration file, the short-interval job scheduler can dynamically configure its timers for changing the job mix.

FIG. 10 illustrates a flow diagram for a process 1000 that a short interval scheduler, such as short interval scheduler 206 , may perform to schedule jobs.

After entering process 1000, the short interval scheduler may wait for the timer to fire. The timers may be preconfigured and/or dynamically configured as described with respect to FIG. 9 .

At operation 1002, a signal indicative of firing of a timer is received. Upon detecting firing of the timer (eg, by receiving a corresponding signal), process 1000 proceeds with the remainder of the process.

At operation 1004, the next execution time is updated. For example, the short interval scheduler agent may maintain a list of jobs in memory. The list may include an entry for each valid short interval job type and its next execution time. At operation 1004, the next execution time for each entry may be incremented by the duration of the current short interval job timer. For example, if the short interval job timer is currently set to fire every 20 seconds, the next execution time for each entry is incremented by 20 seconds each time it fires.

At operation 1006, it is determined whether any job has an execution time less than or equal to zero. In some embodiments, the determination may be whether any job has an execution time less than or equal to some predetermined non-zero threshold.

If the determination at operation 1006 for any job is positive (ie, the next execution time is less than or equal to 0 or a threshold), then at operation 1008 the short interval scheduler processes each such job. As noted above, handling a job may include causing the job to run. In some example embodiments, for each job to be performed, a helper program may be launched to run the job.

After operation 1008, for each of the jobs whose next execution time is less than or equal to 0 or a threshold, the next execution time is updated based on its repetition interval. For example, if a job is listed as having a repeat interval of 5000 milliseconds, after its current start, its next execution time is set to 5000 (or if the current next execution time has decremented below 0, then The new next execution time can be set to compensate for decrements below 0).

After operation 1010, the iteration of processing has completed, and process 1000 may wait for the next timer to fire.

Figure 11 illustrates a portion of an example XML configuration file 1100 for a scheduled agent, such as scheduled agent 208, according to some embodiments. For example, at startup, scheduled agent 208 may read XML configuration file 1100 to determine the jobs to be scheduled and their scheduling parameters.

Configuration file 1100 may include a job description section 1102 and a trigger information section 1104 for each job to be scheduled. The job description section 1102 may identify a job name, a job group, a job type that may be used to identify a scheduler and/or an interface to a scheduler (e.g., an adapter for the Quartz.Net scheduler), and include a job type identifier and whether this is job data for a batch job.

Trigger section 1104 specifies how the job identified in the corresponding job description section 1102 is to be triggered.

FIG. 12 illustrates an example adapter class 1200 that may be used by a scheduled agent for use and/or adapted to a third-party scheduler, such as a Quartz.Net adapter. Providing adapters enhances the configurability of the system. For example, by providing an adapter, new and/or additional schedulers can be used by only modifying the adapter without changing jobs, etc.

With many scheduling modules (eg, Quartz.Net), more efficient and consistent performance in scheduling can be achieved by providing the scheduling component with a more even mix of jobs as in these embodiments. This is possible in some embodiments because even though the web application may have jobs of various job types available, other schedulers running concurrently (for example, on-demand and short-interval schedulers) do not have the same Jobs of those distinct characteristics provide scheduling. Embodiments also provide the advantage that scheduling for a job does not require handling by the developer, and can be handled collectively by the framework in an embodiment, while requiring the developer to provide only the job type.

Furthermore, because a separate scheduler is provided for each type or group of types, embodiments may configurably change (pre-configured or dynamically configured) the number of threads allocated on each processing unit, and thus control provided to The service level for each job type.

The on-demand agent used in an embodiment to run user-initiated (typically, while the user is online using a web application) jobs (e.g., create a report based on user-selected criteria) typically requires a high thread allocation such that the user, Make the time to get the result to the user reasonably short or optimal. On-demand proxies can also be used to distribute the processing load from scheduled jobs. For example, suppose there is a job scheduled to run every day at 4:00 PM that processes records in a feed file that are to arrive at approximately the same time every day. If the number of records to be processed is large and unknown, it is very inefficient to process all records through a single job. Therefore, based on the number of records to be processed, a certain number of jobs processing these records are added to the on-demand job queue. Because the on-demand queue is distributed in some example embodiments, these jobs will be picked up by any server that is free to process jobs. Therefore, a fair and reasonable distribution of load can be realized.

Short-interval brokering enables running jobs that need to be run very frequently without the overhead of a scheduler or queue. These typically include jobs that listen to the queue and are processed on a first-come, first-served basis. These jobs typically always run with very short idle times.

In some embodiments, another advantageous feature of a scheduled job agent is batching. The tag "IsBatch" in the XML configuration file for short interval jobs can be used to control how each job is executed. The default value of this flag can be set to false, in which case the QuartzJobAdapter will queue the job with the configured job type id key parameter into the on-demand queue (instead of executing the job). If the IsBatch flag value is true, it indicates a batch job and there is some batching of the individual jobs involved. In this case, the job with the job type id key is run immediately. The job is typically a batch job that adds several jobs to the on-demand queue based on the number of items to be processed.

The described embodiment is particularly advantageous in network applications. Most web applications require some kind of background processing to offload CPU intensive tasks from the web server. Alerting, reporting, sending emails, logging, etc. are some of the common features of any modern web application. The framework handles all kinds of job processing required by web applications. The on-demand broker is specifically designed to cater to dynamic job requests from online users to give the best possible user experience without long wait times.

Figure 13 shows an example machine-to-job-type mapping table 1200 that may be used in some embodiments. Map 1300 may be used by an agent during scheduling to cause jobs to be executed only on certain authorized machines based on a particular job type. Cleanup of jobs not authorized for a particular machine can be undertaken by a scheduled process, such as described above with respect to the scheduled job agent.

FIG. 14 shows an example block diagram of a hardware architecture for system 100 in accordance with some embodiments. Client system 1410 communicates with server system 1400 via network 1440 . Network 1440 may include a network of interconnected computing devices, such as the Internet. Network 1440 may also include a local area network (LAN) or may include a point-to-point connection between client system 102 and server system 1000 .

Example client system 1410 and server system 1400 may correspond to client system 102 and server system 104 as shown in FIG. 1 . That is, the hardware elements described in FIG. 14 may be used to implement various software components and actions described and illustrated herein with reference to FIG. 1 et al. For example, the client system 1410 may include at least one processor CPU 1431 , at least one memory 1432 , at least one input/output device I/O 1433 , and components for generating and displaying a user interface UI 1434 . I/O devices 1433 can be comprehensive and can include communication devices, such as transceivers (eg, wireless transceivers, wired transceivers) for sending and receiving data. I/O device 1433 may also include an interface for connecting non-transitory computer-readable storage media to client system 1410 for sending and receiving data.

It should be appreciated that a combination of elements in client system 1410 may be used to implement the example web browser application 114 shown in FIG. 2 . For example, the memory 1432 can load files associated with the application (eg, HTML, XML, JavaScript files), and the CPU 1431 can be used to operate the rendering module, networking module, and JavaScript module discussed above to generate the application. Likewise, I/O devices 1433 may be utilized by networking modules to retrieve various elements from server system 1400 including the SPA.

Server system 1400 also includes various hardware components for implementing software elements for server system 104 , as shown in FIG. 2 . For example, the server system 1400 may further include hardware components of at least one processor CPU 1421 , at least one memory 1422 and at least one input/output device I/O 1423 . I/O devices 1423 can be comprehensive and can include communication devices, such as transceivers (eg, wireless transceivers, wired transceivers) for sending and receiving data. I/O device 1423 may also include an interface for connecting a non-transitory computer-readable storage medium to server system 1400 for sending and receiving data. In one example embodiment, the I/O device 1433 of the client system may perform communication with the I/O 1423 of the server system via a network.

Similar to client system 1410, server system 1400 may implement components for generating applications. For example, memory 1422 may be used to store information in database 120 as well as components and files utilized by web server 116 and application server 118 . The CPU 1421 can be used when executing software necessary to generate corresponding modules requested by the client system 1410 and transmitted to the client system 1410 . For example, the CPU 1421 may be used to generate the necessary modules created by the application server 118 . Likewise, I/O device 1423 may be used by web server 116 to transfer various application elements to client system 1410 . Of course, these examples are non-limiting, and the system contemplates utilizing hardware elements in various aspects.

In the examples described herein, for purposes of explanation and not limitation, specific details are set forth, such as particular nodes, functional entities, techniques, protocols, standards, etc., in order to provide an understanding of the described techniques. It will be apparent to those skilled in the art that other embodiments may be practiced than the specific details described below. In other instances, detailed descriptions of well-known methods, devices, techniques, etc. are omitted so as not to obscure the description with unnecessary detail. Individual functional blocks are shown in the figures. Those skilled in the art will appreciate that the functions of those blocks may be implemented using separate hardware circuits, using software programs and data in conjunction with a suitably programmed microprocessor or general purpose computer, using application specific integrated circuits (ASICs), and/or using one or Multiple digital signal processors (DSP) to achieve. Software program instructions and data may be stored on computer-readable storage media, and when the instructions are executed by a computer or other suitable processor control, the computer or processor performs the described functions. Although databases may be depicted below as tables, other formats, including relational databases, object-based models, and/or distributed databases, may be used to store and manipulate data.

Although process steps, algorithms, etc. may be described or claimed in a particular sequential order, such processes may be configured to operate in a different order. In other words, any order or sequence in which steps may be explicitly described or claimed does not necessarily indicate a requirement that the steps be performed in that order. The steps of processes described herein may be performed in any order possible. Additionally, some steps may be performed concurrently, although described or implied as occurring non-concurrently (eg, because one step is described after another). Furthermore, the illustration of a process by its depiction in the figures does not imply that the illustrated process excludes other changes and modifications thereto, or that the illustrated process or any step thereof is essential to the art, And it does not imply that the illustrated procedures are preferred.

Various forms of computer readable media/transmissions may be involved in carrying data (eg, sequences of instructions) to a processor. For example, data may be (i) delivered from memory to processor; (ii) carried over any type of transmission medium (e.g., wired, wireless, optical, etc.); (iii) formatted and and/or transmitted in formats, standards or protocols such as Ethernet (or IEEE 802.3), ATP, Bluetooth, and TCP/IP, TDMA, CDMA, 3G, etc.; and/or (iv) encrypted to ensure privacy or to prevent Deception in any of a variety of ways known in the art. As used in this document, the term "non-transitory computer-readable storage medium" includes registers, cache memory, ROM, semiconductor memory devices (such as D-RAM, S-RAM or other RAM), magnetic media (such as flash memory, hard disk), magneto-optical media, optical media (such as CD-ROM, DVD, or Blu-ray disc), or other types of devices used for non-transitory electronic data storage. The term "processing system" as used in this document means at least one of: a CPU, GPU, ASIC, FPGA or other hardware circuitry for executing instructions such as, for example, software including the web applications described above program.

When described in this document as "may", "could" or "may" perform an action, a feature or component "may", "could" or "may" be included in or apply to a given context, given given that an item "may", "could" or "could" have a given property, or whenever any similar phrase involving the terms "may", "could" or "may" is used, it should be understood that the given An act, feature, component, property, etc. is present in at least one embodiment, although not necessarily present in all embodiments.

Although the techniques have been described with respect to AngularJS, this is done for convenience of description; it is to be understood that the techniques described in this document are applicable to other SPA technologies, other web technologies, and/or any other software technologies in the context of

While the technology has been described in connection with what is presently considered to be the most practical and preferred embodiment, it is to be understood that the technology should not be limited to the disclosed embodiment, but on the contrary, is intended to cover a variety of Modifications and Equivalent Arrangements.

Claims (18)

1. a kind of server system, including：

At least one processor；And

Processing system at least one processor, the processing system are configured to carry out operation, and the operation includes：

Work data library of the configuration with multiple operation entries in the memory；

Concomitantly, multiple job schedulers are performed independently of one another, and each job scheduler is configured to dispatch the operation number According to having in library the type for the operation dispatched is configured to other job schedulers in the multiple job scheduler not The operation of same type is for execution；And

So that it carries out by any scheduler schedules in the multiple scheduler for the operation of execution.

2. server system according to claim 1, wherein the multiple scheduler includes on-demand scheduler, short interval Scheduler and scheduled job scheduler, the on-demand scheduler operation is to dispatch according to the first kind on on-demand basis Operation, the short interval scheduler operation is to dispatch the work of Second Type occurred repeatedly with the interval smaller than predetermined lasting time Industry, the scheduled job scheduler operation is to dispatch at predetermined specific time or between bigger than the predetermined lasting time Every third type operation.

3. server system according to claim 2, wherein（1）The on-demand scheduler and the short interval scheduler It is performed based on corresponding counter cycle, and respectively so that carrying out the operation of the first kind and Second Type without attached Add scheduling steps, and（2）The operation of third type is carried out according to dispatching algorithm.

4. server system according to claim 1, wherein, according to performing the degree of urgency of operation and/or frequency with it Rate determines into the operation corresponding to one in the different types of operation.

5. server system according to claim 1, wherein, the multiple scheduler includes on-demand job scheduler, Wherein described on-demand job scheduler includes at least high priority dispatch device and low priority scheduler, and wherein described height Priority scheduler is configured with the job throughput than the low priority scheduler bigger.

6. server system according to claim 5, wherein, the on-demand job scheduler is configured to the first number Purpose thread distributes to the high priority job scheduler and by the thread of second number fewer than the thread of the first number Distribute to the lower priority job scheduler.

7. server system according to claim 6, wherein, the high priority job scheduler and the low priority Job scheduler is respectively configured to：

Access the operation entry in the work data library；

The queue being added to corresponding to the operation of operation entry retrieved in memory；And

So that supply operation from the queue in the memory.

8. server system according to claim 7, wherein the high priority job scheduler is configured to described Retrieval and addition before determine its current processing capacity whether, and only determine the processing capacity be in specified threshold with The retrieval and addition are just carried out in the case of upper.

9. server system according to claim 8, wherein, the current processing capacity is to be based on and the high priority The current of queue in the associated memory of job scheduler occupies to determine.

10. server system according to claim 1, wherein the multiple scheduler was included between the first duration Every the short interval job scheduler of calling, and wherein the first duration is between the configured execution being configured based on multiple operations Every determining.

11. server system according to claim 10, wherein, the execution interval is matched including the multiple operation It is specified in the XML file put.

12. server system according to claim 1, wherein the multiple scheduler includes scheduled task dispatcher, The scheduled task dispatcher is configured so that the implementation operation at the time according to determined by dispatching algorithm.

13. server system according to claim 1, wherein each operation includes realizing the object of execution method, wherein Correspondence scheduler in the multiple scheduler calls the execution method to run the operation.

14. server system according to claim 1, wherein, the multiple scheduler is numerous by same Windows services Spread out.

15. server system according to claim 14, wherein each in the scheduler is configured to the transmission heart It jumps, and wherein described Windows services determine the health of each in the scheduler based on the heartbeat.

16. server system according to claim 1, wherein, each in the scheduler is implemented as with phase Answer the agency of the thread pool of ground configuration.

17. a kind of method, including：

Work data library of the configuration with multiple operation entries in memory, the memory are communicatively coupled to have extremely The processing system of a few processor；

Perform multiple job schedulers concomitantly, independently of one another in the processing system, each job scheduler is configured It is configured to adjust with other job schedulers in the multiple job scheduler into having in the work data library is dispatched The operation of the different types of type of the operation of degree is for execution；And

So that it carries out by any scheduler schedules in the multiple scheduler for the operation of execution.

18. a kind of non-transitory computer-readable storage media with the instruction being stored thereon, described instruction is by having The processing system of at least one processor makes the processing system carry out operation when performing, the operation includes：

Work data library of the configuration with multiple operation entries, the memory are communicatively coupled to the place in memory Reason system；

Concomitantly, multiple job schedulers are performed independently of one another, and each job scheduler is configured to dispatch the operation number According to having in library the type for the operation dispatched is configured to other job schedulers in the multiple job scheduler not The operation of same type is for execution；And

So that it carries out by any scheduler schedules in the multiple scheduler for the operation of execution.