Application lazy start
An application lazy start is the activation of the first application server instance of a deactivated dynamic cluster when an application request arrives. You decide which applications to deactivate and subsequently lazily start. Use application lazy start if you have an environment in which the ratio of the number of dynamic clusters to the number of nodes is high, and if many dynamic clusters are not accessed for a long time period.
Application lazy start is available for HTTP or HTTPS requests that are routed through the on demand router (ODR). Application lazy start is not available if you use Intelligent Management for web servers. Internet Inter-ORB Protocol (IIOP) and Java Message Service (JMS) requests cannot be used because they are not routed through the ODR.
Do not use application lazy start on dynamic clusters that run Session Initiation Protocol(SIP) applications. Do not enable lazy start if elasticity mode is enabled.
Application lazy start process
To make valuable resources available for other dynamic clusters in an environment that routes requests through the ODR, we can temporarily deactivate idle dynamic clusters, stop all server instances, and release valuable resources for other active clusters. Later, when a request arrives for one of the deactivated clusters, the cluster is activated and at least one server instance is started. In the meantime, a HTTP error code 503 (server unavailable) page is displayed when a user tries to access the server. The error page informs you that the requested application is starting and to resubmit the request shortly. We can configure the ODR to display a special error page that includes an HTTP meta refresh tag so that the browser can automatically re-send the request after a certain time period.
A lazy start controller monitors request activity for dynamic clusters that can be deactivated when idle, and lazily started when a request arrives. When a request arrives at the ODR for an inactive dynamic cluster, lazy start controller triggers placement controller to run off cycle and start an instance for that cluster. The lazy start controller also advises the placement controller when to deactivate the inactive clusters.
The following diagram demonstrates the activity flows of the lazy start and placement controller:
Figure 1. Application lazy start activity flow
Best practice: We can set the inactivity timeout on a dynamic cluster in automatic mode, but the application placement controller does not necessarily stop an instance after that period of inactivity if no memory contention exists on the computer that hosts this server instance. The application placement controller leverages the inactivity timeout to stop a dynamic cluster instance only if a host does not have enough memory to keep the current number of server instances running. The lazy start controller does not stop instances unless absolutely necessary or proactiveIdleStop is in use. For more information about the proactiveIdleStop custom property, read about dynamic cluster custom properties.bprac
Related concepts
Related tasks