To Upgrade Components Without Loss of Service

In a clustered environment, a rolling upgrade redeploys an application with a minimal loss of service and sessions. A session can be any replicable artifact, including:

• HttpSession

• SingleSignOn

• SipApplicationSession

• SipSession

• ServletTimer

• DialogFragment

• stateful session bean

You can use the load balancer and multiple clusters to upgrade components within the Communications Server without any loss of service. A component can, for example, be a JVM, the Communications Server, or a web application.

A rolling upgrade can take place under light to moderate load conditions. The procedure should be doable in a brief amount of time, about 10-15 minutes per server instance.

Applications must be compatible across the upgrade. They must work correctly during the transition, when some server instances are running the old version and others the new one. The old and new versions must have the same shape (for example, non-transient instance variables) of Serializable classes that form object graphs stored in sessions. Or, if the shape of these classes is changed, then the application developer must ensure that correct Serialization behavior occurs. If the application is not compatible across the upgrade, the cluster must be stopped for a full redeployment.

The Basic3pcc sample application includes an Ant target, do-rollingupgrade, which performs all the rolling upgrade steps for you. This sample application is included with the Communications Server in the as-install/samples/sipservlet/Basic3pcc directory. The Basic3pcc application and the Ant target are available only with the JAR installer of Communications Server.

The following procedure describes how to upgrade an application running on all instances of a cluster.

1. Run the following commands on the converged load balancer in the cluster,

   asadmin set domain.converged-lb-configs.clb_config_name.property.load-increase-factor=1

   asadmin set domain.converged-lb-configs.clb_config_name.property.load-factor-increase-period-in-seconds=0

2. Set the value of the dynamic-reconfig attribute to false in the cluster.

3. Redeploy a new version of the application.

   Because you have set the dynamic-reconfig attribute to false, the new version of the application will be loaded to the instance only when the instance restarts.

4. Disable the instance from the converged load balancer by using the following asadmin command:

   asadmin disable-converged-lb-server instance_name

5. Back up the current session with the following command:

   asadmin backup—session store instance_name

   By default, the session files are stored at instance-dir/rollingupgrade.

6. Stop the instance with the following command:

   asadmin stop-instanceinstance_name

7. Start the instance.

   asadmin start-instance instance_name

8. Restore the session.

   asadmin restore—session—store instance_name

9. Enable the instance to the converged load balancer.

   asadmin enable-converged-lb-server instance_name

10. Use the following command to get the latest version of the session store, which could have been updated by another instance accessing this session store.

    asadmin reconcile—session—store instance_name

11. For all instances in the cluster, repeat steps 3 to 9.

12. Set the value of the dynamic-reconfig attribute to true in the cluster.