JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle GlassFish Server 3.1-3.1.1 High Availability Administration Guide
search filter icon
search icon

Document Information


1.  High Availability in GlassFish Server

2.  Setting Up SSH for Centralized Administration

3.  Administering GlassFish Server Nodes

4.  Administering GlassFish Server Clusters

5.  Administering GlassFish Server Instances

6.  Administering Named Configurations

7.  Configuring Web Servers for HTTP Load Balancing

8.  Configuring HTTP Load Balancing

9.  Upgrading Applications Without Loss of Availability

Application Compatibility

Upgrading In a Single Cluster

To Upgrade an Application in a Single Cluster

Upgrading in Multiple Clusters

To Upgrade a Compatible Application in Two or More Clusters

Upgrading Incompatible Applications

To Upgrade an Incompatible Application by Creating a Second Cluster

10.  Configuring High Availability Session Persistence and Failover

11.  Configuring Java Message Service High Availability

12.  RMI-IIOP Load Balancing and Failover


Upgrading Incompatible Applications

If the new version of the application is incompatible with the old version, use the following procedure. For information on what makes applications compatible, see Application Compatibility. Also, you must upgrade incompatible application in two or more clusters. If you have only one cluster, create a “shadow cluster” for the upgrade, as described below.

When upgrading an incompatible application:

To Upgrade an Incompatible Application by Creating a Second Cluster

  1. Create a “shadow cluster” on the same or a different set of machines as the existing cluster. If you already have a second cluster, skip this step.
    1. Use the Administration Console to create the new cluster and reference the existing cluster’s named configuration.

      Customize the ports for the new instances on each machine to avoid conflict with existing active ports.

    2. For all resources associated with the cluster, add a resource reference to the newly created cluster using asadmin create-resource-ref.
    3. Create a reference to all other applications deployed to the cluster (except the current upgraded application) from the newly created cluster using asadmin create-application-ref.
    4. Configure the cluster to be highly available using asadmin configure-ha-cluster.
    5. Create reference to the newly-created cluster in the load balancer configuration file using asadmin create-http-lb-ref.
  2. Give the new version of the application a different version identifier from the old version.
  3. Deploy the new application version with the new cluster as the target. Use a different context root or roots.
  4. Start the new cluster while the other cluster is still running.

    The start causes the cluster to synchronize with the domain and be updated with the new application.

  5. Test the application on the new cluster to make sure it runs correctly.
  6. Disable the old cluster from the load balancer using asadmin disable-http-lb-server.
  7. Set a timeout for how long lingering sessions survive.
  8. Enable the new cluster from the load balancer using asadmin enable-http-lb-server.
  9. Export the load balancer configuration file using asadmin export-http-lb-config.
  10. Copy the exported configuration file to the web server instance’s configuration directory.

    For example, for Sun Java System Web Server, the location is web-server-install-dir/https-host-name/config/loadbalancer.xml.

  11. After the timeout period expires or after all users of the old application have exited, stop the old cluster and undeploy the old application version.