Distributed scheduler
A method, system, and computer readable medium for managing applications on an application execution system are disclosed. On an application server the number of instances of a first application type that are in a busy state is determined. This determination is performed at each respective time interval in a plurality of time intervals. Then, a first running average for the busy state of the first application type is computed based upon the number of instances of the first application type that are in a busy state, at the application server, at each respective time interval. A removal request is sent when the first running average for the busy state meets a first removal criterion. The removal request is a request to remove the application server from a data structure that specifies which of a plurality of application servers accept service requests for the first application type.
1. A method of managing applications on an application execution system, the method comprising:
receiving, by one or more processors, a first instruction to execute a first application from a front-end server;
retrieving and loading, by the one or more processors, a first instance of a first application into volatile storage in response to receiving the first instruction;
executing, by the one or more processors, the first instance of the first application;
transmitting, by the one or more processors, a result indicator to the front-end server, the result indicator signaling that the executing has been completed;
after transmitting the result indicator, determining, by the one or more processors, whether the first application meets one or more criteria;
retaining, by the one or more processors, the first instance of the first application in volatile storage when the first application meets the one or more criteria, wherein the one or more criteria comprise at least one of: exceeding a number of respective application instances of the first application in volatile storage available for handling new requests; or exceeding a number of errors encountered during execution of the first application;
determining a state of the first instance of the first application, wherein the state of the first instance may be available or busy; and
receiving and loading, by the one or more processors, a first instance of a new version of the first application into volatile storage when a state of all instances of the first application is busy.
2. The method of claim 1 , further comprising:
receiving a second instruction to execute the first application from the front-end server;
executing the first instance of the first application upon determining the state of the first instance of the first application is available.
3. The method of claim 1 , further comprising:
receiving a second instruction to execute the first application from the front-end server;
retrieving and loading a second instance of a first application into volatile storage in response to receiving the second instruction and upon determining the state of the first instance of the first application is busy; and
executing the second instance of the first application.
4. The method of claim 3 , further comprising:
transmitting another result indicator to the front-end server, the result indicator signaling that the executing of the second instance of the first application has been completed;
after transmitting the another result indicator, determining whether the first application meets one or more criteria; and
retaining the second instance of the first application in volatile storage when the first application meets the one or more criteria.
5. The method of claim 1 , further comprising:
removing the first instance of the first application in volatile storage when the first application fails to meet the one or more criteria.
6. An application execution system for managing application comprising:
an application server having one or more processors coupled to memory, the one or more processors being configured to:
receive a first instruction to execute a first application from a front-end server;
retrieve and load a first instance of a first application into volatile storage in response to receiving the first instruction;
execute the first instance of the first application;
transmit a result indicator to the front-end server, the result indicator signaling that the executing has been completed;
after transmitting the result indicator, determine whether the first application meets one or more criteria;
retain the first instance of the first application in volatile storage when the first application meets the one or more criteria, wherein the one or more criteria comprise at least one of: exceeding a number of respective application instances of the first application in volatile storage available for handling new requests; or exceeding a number of errors encountered during execution of the first application;
determine a state of the first instance of the first application, wherein the state of the first instance may be available or busy; and
receive and load, by the one or more processors, a first instance of a new version of the first application into volatile storage when a state of all instances of the first application is busy.
7. The system of claim 6 , wherein the processors are further configured to:
receive a second instruction to execute the first application from the front-end server;
execute the first instance of the first application upon determining the state of the first instance of the first application is available.
8. The system of claim 6 , wherein the processors are further configured to:
receive a second instruction to execute the first application from the front-end server;
retrieve and load a second instance of a first application into volatile storage in response to receiving the second instruction and upon determining the state of the first instance of the first application is busy; and
execute the second instance of the first application.
9. The system of claim 8 , wherein the processors are further configured to:
transmit another result indicator to the front-end server, the result indicator signaling that the executing of the second instance of the first application has been completed;
after transmitting the another result indicator, determine whether the first application meets one or more criteria; and
retain the second instance of the first application in volatile storage when the first application meets the one or more criteria.
10. The system of claim 6 , wherein the processors are further configured to:
remove the first instance of the first application in volatile storage when the first application fails to meet the one or more criteria.
11. A non-transitory computer-readable medium storing instructions, which when executed by one or more processors, cause the one or more processors to:
receive a first instruction to execute a first application from a front-end server;
retrieve and load a first instance of a first application into volatile storage in response to receiving the first instruction;
execute the first instance of the first application;
transmit a result indicator to the front-end server, the result indicator signaling that the executing has been completed;
after transmitting the result indicator, determine whether the first application meets one or more criteria;
retain the first instance of the first application in volatile storage when the first application meets the one or more criteria, wherein the one or more criteria comprise at least one of: exceeding a number of respective application instances of the first application in volatile storage available for handling new requests; or exceeding a number of errors encountered during execution of the first application;
determine a state of the first instance of the first application, wherein the state of the first instance may be available or busy; and
receive and load, by the one or more processors, a first instance of a new version of the first application into volatile storage when a state of all instances of the first application is busy.
12. The non-transitory computer-readable medium of claim 11 , wherein the instructions further cause the one or more processors to:
receive a second instruction to execute the first application from the front-end server;
execute the first instance of the first application upon determining the state of the first instance of the first application is available.
13. The non-transitory computer-readable medium of claim 11 , wherein the instructions further cause the one or more processors to:
receive a second instruction to execute the first application from the front-end server;
retrieve and load a second instance of a first application into volatile storage in response to receiving the second instruction and upon determining the state of the first instance of the first application is busy; and
execute the second instance of the first application.
14. The non-transitory computer-readable medium of claim 13 , wherein the instructions further cause the one or more processors to:
transmit another result indicator to the front-end server, the result indicator signaling that the executing of the second instance of the first application has been completed;
after transmitting the another result indicator, determine whether the first application meets one or more criteria; and
retaining the second instance of the first application in volatile storage when the first application meets the one or more criteria.
15. The non-transitory computer-readable medium of claim 11 , wherein the instructions further cause the one or more processors to:
remove the first instance of the first application in volatile storage when the first application fails to meet the one or more criteria.