No Downtime Production redeployment in WebLogic

Upgrading a running application in a J2EE production environment isn't easy. You either have to undeploy the old version of the application and deploy the new one—causing a temporary outage—or you may have to set up a redundant server/cluster to route the new requests.

BEA WebLogic Server 9.0 supports a production redeployment feature that provides a way to seamlessly upgrade an application in a production environment without affecting application availability. After redeploying a new version of the application, all new client connection requests go to the new application. The existing client connections continue to use the old application that will be undeployed/retired after all the existing connections are closed. The two application versions are completely isolated from each other and do not share any resources. Alternatively, the old version of the application can be retired by specifying a retire timeout for the application.

This article uses a sample application to demonstrate this functionality.

Requirements

Currently, WebLogic Server 9.0 supports this production redeployment feature only for Web application (WAR) modules and enterprise applications (EARs). All other types of archives (EJB JAR, JCA RAR, WebServices archives, JMS, or JDBC standalone modules) are not supported. EARs can contain all supported module types, except WebServices archives. Production redeployment only supports HTTP clients; Java clients are not supported. Attempting to perform production redeployment with an unsupported archive type will result in an error. To redeploy such modules, remove their version identifiers and explicitly redeploy the modules.

In addition, only versioned applications can be redeployed using this feature. A versioned application is an application that has an application archive version specified in the manifest of the application archive.

A deployed application must specify a version number before you can perform subsequent production redeployment operations on the application. In other words, you cannot deploy a non-versioned application and later perform production redeployment with a new version of the application.

WebLogic Server 9.0 can host a maximum of two different versions of an application at any one time. Also, when you redeploy a new version of an application, you cannot change the application's deployment targets, security model, or persistent store settings. To change any of the above features, you must first undeploy the active version of the application.

Application Version Information

The application version information can be specified in the MANIFEST.MF file's WebLogic-Application-Version property. The manifest is a special file that can contain information about the files packaged in a JAR file. By tailoring this "meta" information that the manifest contains, you enable the JAR file to serve a variety of purposes.

For example, an application archive whose application archive version is "v1" could have the following manifest content:

Manifest-Version: 1.0



Created-By: 1.4.1_05-b01 (Sun Microsystems Inc.)



WebLogic-Application-Version: v1

The application archive version is a string that can only contain the following characters: alphanumeric ("A"-"Z," "a"-"z," "0"-"9"), period ("."), underscore ("_"), and hyphen ("-"). The length of the application archive version should be less than 215 characters. Additionally, the application archive version string cannot be "." or "..". You can either specify a version for an application using the manifest file, or assign one when using the Deployer tool's -appversion option. The value specified in MANIFEST.MF file will take precedence over the -appversion value.

The version number is important when considering the redeployment of versionable applications. If a new application archive version is specified, WebLogic Server will perform production redeployment with version isolation. If the same application archive version is specified, WebLogic Server will perform in-place redeployment.

The Sample Versioned Application

The attached sample application (VersionedApp1) contains a Web application, which has three JSP files:

• The versionedjsp.jsp file contains a simple print statement.
• The invalidatesession.jsp contains a session.invalidate() command to invalidate all the sessions.
• The timeoutsession.jsp file contains code to set the timeout value for the session.

The other application, VersionedApp2, contains the same set of files, but the versionedjsp.jsp file will print a different message.

We'll use these applications to demonstrate the versioning process.

Deploying the Application

The sample applications provided along with this article do not have version information in their manifest files. If you want to use production redeployment with an application that does not include a version string in the manifest file, the Deployer tool allows you to manually specify a unique version string using the -appversion option when deploying or redeploying an application. Run this command to deploy the application with a version of version1:

java weblogic.Deployer -adminurl http://localhost:8802

 -username weblogic -password weblogic -name VersionedApp

 -targets adminServer

 -deploy -source C:/tmp/VersionedApp1 -appversion version1

Deployer is a Java-based deployment tool that provides a command-line interface to the WebLogic Server deployment API. Deployer is intended for administrators and developers who want to perform interactive, command line-based deployment operations.

Note that the version string specified with -appversion is applied only when the deployment source files do not specify a version string in MANIFEST.MF. For applications with version information in the manifest files, you need not provide the -appversion option.

You can also display version information for deployed applications from the command line using the Deployer -listapps command. So for example, after deploying the above application you can run this command to list the application:

java weblogic.Deployer -adminurl http://localhost:8802 

-user weblogic -password weblogic -listapps

Redeploying a New Version of the Application

Now that we've deployed the application, let's look at redeploying it. Since our deployment files do not contain version information in the manifest files, we perform redeploy with the -appversion option as mentioned above:

java weblogic.Deployer -adminurl http://localhost:8802

 -username weblogic -password weblogic -name VersionedApp

 -targets adminServer -redeploy -source

 C:/tmp/VersionedApp2 -appversion version2

If you want to specify a fixed time period after which the older version of the application is undeployed (regardless of whether clients finish their work), use the -retiretimeout option with the -redeploy command. (-retiretimeout specifies the number of seconds after which the older version of the application is retired):

java weblogic.Deployer -adminurl http://localhost:8802

 -username weblogic -password weblogic -name VersionedApp 

 -targets adminServer -redeploy -source

 C:/tmp/VersionedApp2 -appversion version2 -retiretimeout 300

If WebLogic Server has not yet retired an application version, you can immediately undeploy the application version without waiting for retirement to complete. This may be necessary if, for example, an application remains in the retiring state with only one or two long-running client sessions that you do not want to preserve. To force the undeployment of a retiring version of an application, use the -undeploy command and specify the application version:

java weblogic.Deployer -adminurl http://localhost:8802

 -username weblogic -password weblogic -name VersionedApp

 -targets adminServer -undeploy -name VersionedApp

 -appversion version1

If you do not explicitly specify an application version with the -appversion option, WebLogic Server undeploys the active version and all retired versions of the application.

Verifying the Deployment

After deploying the first version of the application, open a browser and invoke the versionedjsp.jsp:

http://localhost:8802/VersionedApp/versionedjsp.jsp

That should establish an HTTP session to the VersionedApp1 application. In the browser window we should see the "Output from VersionedApp1 JSP" message. After deploying the VersionedApp2 application, open another browser window and invoke the versionedjsp.jsp. Now we should see the "Output from VersionedApp2 JSP" message from the VersionedApp2 application. At this time, both the versions of application should be alive.

Now invoke the invalidatesession.jsp from the first browser window:

http://localhost:8802/VersionedApp/invalidatesession.jsp

This will invalidate all the established sessions to the VersionedApp1 application. Take a look at the server console window. The retirement process should have started now. Wait a few moments for the retirement process to complete and invoke versionedjsp.jsp from the first browser window:

http://localhost:8802/VersionedApp/versionedjsp.jsp

This time you should see the "Output from VersionedApp2 JSP" message from the VersionedApp2 application.

Rolling Back the Production Redeployment Process

Reversing the production redeployment process switches the state of the active and retiring applications and redirects new client connection requests accordingly. Reverting the production redeployment process may be necessary if you detect a problem with a newly deployed version of an application, and you want to stop clients from accessing it.

To roll back the production redeployment process, issue a second -redeploy command and specify the deployment source files for the older version:

java weblogic.Deployer -adminurl http://localhost:8802

  -user weblogic -password weblogic -redeploy

  -name VersionedApp C:/tmp/VersionedApp1

  -retiretimeout 300

Conclusion

Production redeployment is a very powerful functionality. With this functionality, customers get the ability to roll out application upgrades in a production environment transparently, without disruption to clients. Production redeployment not only requires fewer hardware resources but also provides more flexibility and control of application availability. Administrators should definitely consider using this functionality in production environments, which will not only make their tasks easier, but also provide minimal disruption to the end user.