Application pools
Application pools are used to separate the processes in which a Component executes. They are also used to specify which Components are executed in the same process.
Application pools are defined in iCore Administrator. The definition contains only basic properties like Name, Description, Categories and other standard entity properties, there is no other configuration. An Application pool is configured on each Server that implements the Application pool. Every system has a system-internal default Application pool defined right from the start.
Implementing an Application pool
Each Server is configured to provide one or more Application pools. Application pools are implemented by one or more Servers. This means that the Application pool implementation consists of one or more “physical” Application pools that are implemented by one or more of the Servers in the system. A Server instantiates an Application pool at runtime.
Configuring an Application pool
For each Application pool implemented by a Server, you can configure the number of worker processes in each Server implementation of the Application pool. On each process, it is possible to set the number of "slots" (concurrent Jobs).
For more information, see Server.
Application pools and Components
Every Component is configured to run in an Application pool, either a user-defined Application pool or the system internal default Application pool.
Application pools at runtime
At runtime, the service tries to find the least loaded Server providing the Application pool specified in the Component configuration. If all implementations of the requested pool type are busy, the execution of the Component is put on hold until an empty slot appears in the Application pool.
Restarting Application pools
Application pools can be manually restarted via the Administrator GUI or a iCore PowerShell cmdlet. With this command, it is not necessary to restart the iCore system to make recently added or compiled Component definitions available in iCore runtime.
During an Application pool restart, all Servers are instructed to retire any currently running Worker hosts and start new Worker hosts for the latest compiled Component definitions. During this process, new Jobs will be started in the new Worker hosts, using the new Component definitions (as long as there are slots available), while any already running Jobs are allowed to finish executing. Once all the Jobs in a retired Worker host are complete, the Worker host will terminate. The total number of available slots for running Jobs do not change during the Application pool restart. Free slots are transferred to the new Worker host as they become available.
When an Application pool restart has been completed, the Application pool generation counter is increased by 1 on the following Server parts:
- Server Monitor
- System Event Processor
- Worker Host Manager
During normal circumstances, these Server parts should be running the same Application pool generation. You can determine which generation each Server part is running by checking the System monitor. When you perform a "normal" system restart, the generation counter will be reset to 1.
note
While the Application pool restart option works well in a majority of use cases, there are some situations in which it is not desireable to have a mix of old and new Component definitions running simultaneously, depending on their implementation and interaction with surrounding systems. In those cases, a system restart is recommended.
Inconsistencies related to Application pool restarts may specifically cause problems in clustered iCore systems. For more information, see the Service options tab in the System settings.