By rolling out an edition, you replace an active edition with a
new edition. The new edition might be a simple modification to the application,
such as a bug fix, or a more substantial change. As long as the new edition
is backward compatible, it can be rolled out to replace the active edition
without impacting existing clients. To roll out a new edition, you must first
install the application edition with the new edition information. You can
also use the application edition manager if you are using the Compute Grid
component and want to rollout Compute Grid applications. These are Java 2
Platform Enterprise Edition (J2EE) applications that conform to one of the
grid programming models.
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.
Note: Application edition rollout fails
when two user ID's on two administrative consoles attempt a parallel application
edition rollout.
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
the Applications > Edition control center > application_name.
Select your new edition, for example, 2.0, and click Rollout. Specify
the following settings:
- 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
is large. 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 is very large, consider
dividing up your rollout into smaller groups by using group rollout. Atomic
mode can also be 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.
- 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 best performing application reset, because it
loads 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 are rolling out an application 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 Extended Deployment lengthen the effective drainage interval,
because the server does not stop until these units of work complete. Applications
with activities unknown to Extended Deployment 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 is unnecessary for persistent sessions, for example, those
backed in database or replicated through 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.
- Launch the rollout. Click OK. This action launches
an interruption-free replacement of the older 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. 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 should be the active
edition on deployment target. The new edition automatically starts, because
it replaces a running edition.
When an application edition in validation
mode is rolled out, the binding names must be changed back to the original
values. For example: /clusters/cluster1-validation/jdbc/CustomerData must
be changed back to /clusters/cluster1/jdbc/CustomerData.