Multiple production versions through WebLogic production redeployment

Production redeployment is a facility in WebLogic that provides the ability to temporarily have multiple versions of the same web application of web service active at the same time.

Sometimes, changes in application functionality require redeployment of the application. In the theoretical case of instantaneous responses from applications, we could argue that the roll out of a new version of an application is akin to the flip-of-the-switch: request A is handled by version X, the switch is flipped to bring version X+1 live and the next request B is taken care of by the new version. This, however, is not the reality. Requests take longer to process than no time at all. Besides, requests live in the context of a session – this applies to database as well as application server. This means that replacing version X with a new version X+1 in a throw-the-switch manner would not only potentially interrupt pending non-zero duration requests but would also – and far more harmfully – destroy all pending sessions. This would definitely not constitute zero-downtime application upgrade.

In order to not lose pending requests and sessions during application upgrades, there clearly is a need for the (temporary) co-existence of two versions of applications – the old one with potentially the pending conversations and the new one to deal with all newly initiated conversations.

Various products in Fusion Middleware have somewhat different ways of supporting this multi-version situation. This article looks at WebLogic for Web Services and Web applications (including ADF and WebCenter Portal applications).

WebLogic Server is used to deploy and run Web applications – such as ADF and WebCenter Portal applications – as well as Web Services. For all of these, WebLogic supports a mechanism called production redeployment. This too is a method for (temporary) multi-version support.

Suppose we have an Application called X. It has been deployed some time ago and is being used quite heavily. A new version of this application has been developed. If the application X has version information included – the WebLogic-Application-Version property in the file ApplicationRoot\meta-inf\MANIFEST.MF has been set – it qualifies for production redeployment. This means that when the new version of Application X is deployed as a redeployment of Application X, WebLogic ensures that for a limited period of time it will have both version 1 and version 2 of the application running, side by side. Version 2 is used for all new sessions. Version 1 is kept around for existing sessions. Only requests in the context of sessions that were created against version 1, before version 2 had been deployed, will be serviced by version 1. The old version is either kept around for a fixed period of time or until all sessions have been concluded. The next illustration shows the situation some time after the new version has been production redeployed: some new sessions have been created on version 2 and some pre-existing sessions are still connected to version 1.

In this scenario, none of the users suffers unavailability of the application. Either the user starts a new session on version 2 or the user’s session continues running on version 1. No planned downtime!

URL rewriting

Prolonged use of parallel multiple versions is not supported by WebLogic’s Production Redeployment feature: all new sessions will be initiated on the new version, if you like it or not. If you do not, there is another option – which requires a little more work on your part but offers more flexibility through the use of URL rewriting. For example using Apache HTTP server in front of WebLogic and then leveraging its mod_rewrite plugin, you can reroute requests for http://domain:port/application/path?someOptionalParameters to the version specific application URL such as http://domain:port/application_v2/path?someOptionalParameters.

The actual rewrite logic is written in instructions in a configuration file. When the file is changed, the modifications are automatically reloaded so a server restart is not required. Note: the rewrite instructions can be quite sophisticated, for example looking at the client from which the request originates in order to determine to which URL to forward the request and checking whether the request is one initiating or continuing a session.

Resources

Production Redeployment , WebLogic Versioning by JaySenSharma on Middleware Magic blog – http://middlewaremagic.com/weblogic/?p=394

Introduction to URL Rewriting with Apache MOD_REWRITE – blog article by Ross Shannon – http://www.yourhtmlsource.com/sitemanagement/urlrewriting.html