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 requests that are routed through the on demand router (ODR). 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.
Application lazy start process
To make valuable resources available for other dynamic clusters in an environment that routes requests through the ODR, you 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. You 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: You 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.bprac
Related concepts
The lazy start controller
Related tasks
Creating dynamic clusters Configure application lazy start
Related reference
Dynamic cluster administrative tasks