The next task in the use case example is to deploy the service to the resource pools on which it will run. To start a WLOC service, you deploy it using the WLOC Administration Console, or configure it for auto-deployment. WLOC chooses one or more resource pools for the initial deployment.
To choose resources pools for an initial deployment, WLOC follows this procedure:
The Controller examines the process requirements that you configured for the service.
The Controller examines all resource pools that are currently active—including those that are hosting other services—and uses the following process of elimination to determine which resource pools are candidates for hosting the service:
If the service specifies software requirements, resource pools that do not offer access to all of the required software are eliminated as candidates.
If the service consists of a single process, resource pools that offer fewer computing resources than the service's minimum resource requirements are eliminated.
If the service consists of multiple processes, WLOC may use multiple resource pools to run the service.
After this process of elimination, WLOC determines which resource pool or combination of resource pools can be used to host the service. Then, it uses one of the following placement algorithms that you configure when you create the service to choose a resource pool or collection of resource pools:
Prefer resource pools with the most resources: WLOC selects the resource pool combination that provides the greatest amount of computing resources.
Prefer resource pools with fewer resources: WLOC selects the resource pool that most closely matches the minimum resource requirements of the service. This algorithm ensures the most efficient use of resources in your data center.
Deployment Scenario
In this example, we will deploy the CreditCheckService from the Administration Console. Note that before we start the service, the state of the service is undeployed, which indicates that there are no instances running. When we start the service, the following occurs:
The Controller evaluates the process requirements for each process group in the service. When we specified the resource requirements in Define Resource Requirements for the Service, we specified that there should be a minimum of 1 process for each process group.
The Controller compares the resource pools available for each process group in the service against the resource agreements and eliminates any resource pools that cannot host the service. Because the only requirement that we specified is minimum number of processes, it will randomly choose one of the two Managed Servers for the ManagedServers process group.
Use the placement algorithm that we specified when we defined the service properties, Prefer resource pools with the most resources, to determine the resource pool on which to place the service.
The Controller stages each of the instances individually.
The Controller starts each of the instances individually. When the minimum number of processes from each group is started, the service is deployed.
The Controller evaluates the runtime policy. When the average load across all the instances in the ManagedServers process group exceeds the defined value, another JVM instance is started.
In a real world client application, a typical setting for the MaxAverageJVMProcessorLoad might be .8, indicating that when the average load across all the instances in the ManagedServers process group exceeds 80%, an additional JVM instance is started. For the purposes of this example, we set the value of MaxAverageJVMProcessorLoad to 0 to trigger the required action.
The runtime policy is continually evaluated. When the constraint is violated again and there are no other available processes to start, the action fails.
Note:
When the service is deployed, two additional directories are created in the Agent directory: stderr and stdout. The JVM standard output stream is directed to the stdout directory and the standard error stream is output to the stderr directory. Because we accepted the defaults when we created the Plain Agent using the Configuration Wizard, these directories are as follows:
Note:
C:\WLOC_UseCase\user_projects\PlainAgent\stderr
Note:
C:\WLOC_UseCase\user_projects\PlainAgent\stdout
Deploy the Service
To deploy the CreditCheckService:
Click the Inventory tab in the WLOC navigation bar and click Services.
The CreditCheckService is displayed in the Services table.
Select the CreditCheckService check box and click Start.
Note:
We have expanded the hierarchy in the Inventory pane to illustrate the process groups and the configured process group instances. As the state of a process changes, the changes are reflected in the Inventory pane: when a process is not running, is unstaged, or its state cannot be determined, it appears grayed out. When a process is started, it appears in a solid, blue state. When a process is destroyed, it returns to the grayed-out state.
The message Request to start service was successfully sent is displayed, and the Status column in the table reflects the transition states of the service.
As the service is proceeding through the various transition states of the deployment process, view the following in the console:
The runtime status changes in the Status column to reflect the current or transitional state as follows:
undeployed—No JVM instances are running.
staging—The service is transitioning from undeployed to staged state.
staged—No JVM instances are running (same as undeployed for a Plain Agent.)
starting—The service is transitioning from staged to deployed state.
deployed—The minimum number (at least) of JVMs associated with the service are running.
The state of the process is shown in the Inventory pane. As each JVM process is started, it changes to dark blue in the Inventory pane.
The Task and Event Viewer displays each event as it occurs.
When the minimum number of instances are started, the service state is changed to deployed and the runtime policy is evaluated.
The Task and Event Viewer indicates a Quality of Service (QOS) violation and the second ManagedServers JVM instance is started. Note that the Managed Server process group is red in the Inventory pane indicating that a QOS violation occurred.
The ManagedServers process group changes to green in the Inventory pane when the second JVM instance is started, indicating that the action to rectify the violation has completed.
The runtime policy is continually evaluated. Another QOS violation occurs. Because there are no other available processes to start, the action fails, and the ManagedServers process group turns red in the Inventory pane again.
