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.

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