Rollout an edition

Operating Systems: AIX, HP-UX, Linux, Solaris, Windows

Rollout an edition

When you perform a rollout to an edition, you replace an active edition with a new edition. The new edition might be a simple modification to the application, or contain a more substantial change. As long as the new edition is backward compatible, then you can perform a rollout to replace the active edition without impacting existing clients. To perform a rollout to a new edition, first install the application edition with the new edition information.

Before you begin
You must have an application edition that is installed and started, and have configurator or administrator administrative privileges to perform this task. Avoid trouble: Performing a rollout fails when two user IDs on two administrative consoles attempt to complete the process in parallel.gotcha

About this task

You can also use the application edition manager if you are using the Compute Grid component and want to perform a rollout to Compute Grid applications. These are Java™ Enterprise Edition 5 (Java EE 5) applications that conform to one of the grid programming models.

Procedure

Install the new edition. Use the same steps that are described in Installing an edition but specify your new edition information. For example, type 2.0 in the Application edition field and Second edition in the Application description field. Select the same deployment targets that are used for the current edition.
Save and synchronize your nodes.
Specify the rollout settings. Click Applications > Edition control center > application_name. Select your new edition, for example, 2.0, and click roll out.
Specify the following settings for enterprise or other middleware applications:

Select Atomic or Grouped rollout type.
Use group rollout to replace editions on members of the target cluster in a group of one. Group rollout is the most typical choice, and is useful when the cluster contains four or more members. Alternatively, you can perform group rollout with a specified group size through scripting. For more information, read about Application edition management administrative tasks. When the new edition becomes available during group rollout, all requests are directed to the new edition.
Use atomic rollout to replace one edition with another on half of the cluster at a time. This rollout type serves all user requests with a consistent edition of the application. Because all user requests are served a consistent edition, your cluster runs at half capacity. If your cluster has four or more members, consider dividing up the cluster into smaller groups by performing a group rollout. Atomic mode is also used with a single server deployment target. In a single server deployment target, the actions that are carried out against the second half of the cluster are omitted. Avoid trouble: Before you perform an atomic rollout, determine the load capability of the target server cluster. Performing an atomic rollout activates the new edition on half of the cluster first, and then activates the edition on the remaining half of the cluster. While the first half of the cluster is taken offline and updated, application requests are routed to the second half of the cluster. Verify that half the cluster can handle the entire load during the rollout period.gotcha
Select the reset strategy. The reset strategy instructs the application edition manager how each deployment target loads the new edition into the server runtime.
Use a Soft strategy to reset the application by stopping or restarting the application in each server of the cluster as the next edition replaces the old edition in that server. Soft reset is the most typical choice and the most optimal performing application reset because it results in loading the new edition by recycling the application in the running application server. The server stays up during this process. With soft reset, native libraries are not unloaded from memory. Soft reset is generally safe for applications that use no native libraries. When soft reset is used in a production environment, monitor the application server process to ensure that sufficient virtual memory exits.
A Hard reset strategy recycles the each entire application server of the cluster as the next edition replaces the former edition in the server, refreshing both process memory and any native libraries used by the application. This strategy prevents virtual storage exhaustion and allows new versions of native libraries to be loaded. Select hard reset as your reset strategy when you perform a rollout to an edition that depends on new versions of native libraries or other dependencies that are refreshed only by recycling the entire application server, or if you have large applications that consume a lot of memory for just-in-time compilation (JIT).
Set the drainage interval in seconds. The drainage interval gives the HTTP sessions time to complete before the application or server is reset. The drainage interval specifies the amount of time that the application edition manager waits before the reset strategy starts.
Affinities, such as transaction, activity, and compensation-scope, and activities unknown to WebSphere^® Virtual Enterprise lengthen the effective drainage interval because the server does not stop until these units of work complete. Applications with activities unknown to WebSphere Virtual Enterprise can use the AppEditionManager MBean quiesce initiated notification as a trigger to begin shutdown processing and exploit the drainage interval as a time period during which to complete the shutdown. This process is unnecessary for persistent sessions, for example, those backed in database or replicated through VMware Distributed Resource Scheduler (DRS), but is important for transient (in memory) sessions.
To prevent the loss of transient sessions, set the drainage interval to exceed the application session timeout interval. After the rollout starts, as each server updates, the server is marked as ineligible to begin any new sessions. Set this value to 0 to not wait for sessions to complete.
Specify the following settings for Session Initiation Protocol (SIP) applications:

Choose a quiesce strategy. The quiesce strategy specifies how old servers or cluster members that host the current edition are removed. This setting does not affect the new edition that is being rolled out.

Quiesce server or cluster members after all active sessions or dialogs are completed.: Removes the server or cluster member when all of the active sessions and dialogs for the server or cluster member complete.
Quiesce servers or cluster member after the specified interval: Removes the server or cluster member after a specified time period. Specify an amount of time, in seconds, minutes, or hours.
Attention: Performing a rollout is not supported for SIP applications that are deployed on a dynamic cluster that has been converted from a static cluster.

Start the rollout. Click OK. This action launches an interruption-free replacement of the previous edition with your new edition.

Results

For an edition that is not in validation mode, the new edition replaces the current edition after the rollout completes. An edition that is in validation rolls out on the original deployment target and the cloned environment is deleted. The routing rules are updated to begin routing to your new edition.
For a Compute Grid application, after the drainage time, the job scheduler will cancel those jobs (of the rolling out application) which are still running on the quiesced endpoints.

What to do next

To validate the results, click Applications > Edition control center > application_name. Your new edition is the active edition on the deployment target. The new edition automatically starts, because it replaces a running edition.
When you perform a rollout to an edition in validation mode, the binding names are changed back to the original values. For example: /clusters/cluster1-validation/jdbc/CustomerData are changed back to /clusters/cluster1/jdbc/CustomerData. Attention: Edition validation does not work properly for applications that are deployed on a dynamic cluster that is converted from a static cluster.

Related concepts

Application edition manager concepts

Related tasks

Installing an edition
Rollback an edition
Activating concurrent editions
Validating an edition

Related reference

Routing and service policies
Administrative roles and privileges
Related information

Application edition management administrative tasks