Weblogic Deployment Staging Mode

Overview:
In this post we will discuss that how a small configuration can cause huge delay application deployment.

In our cluster environment ( 1 AdminServer + 2 Managed Servers) , application deployment started taking huge time (sometime 45 mins or so) which was bit frustrating and causing delay in environment to be ready.

Admin Server and 1 Managed Server is running on Host A and Other Managed Server is running on Host B. After analyzing our deployment settings ,we figured that , in weblogic config.xml file, "<staging-mode>" element under app-deployment was set to "stage", which had a significant impact on deployment.

Understanding weblogic staging Mode is very important to avoid such delay. So i plan to publish them , so that it can help others.


Introduction:
Weblogic comes with three different flavors of staging mode.

1. NoStage
2. Stage
3. External_Stage

Using Nostage Mode Deployment

In nostage mode, the Administration Server does not copy the archive files from their source location. Instead, each target server must access the archive files from a single source directory for deployment. The staging directory of target servers is ignored for nostage deployments.

For example, if you deploy a Java EE Application to three servers in a cluster, each server must be able to access the same application archive files (from a shared or network-mounted directory) to deploy the application.

Note:

The source for the deployment files in nostage mode is the path provided by the user at deployment time (as opposed to stage mode, where the source is the path in each server’s staging directory). However, even in nostage mode, WebLogic Server copies out parts of the deployment to temporary directories. This enables users to update entire archived deployments or parts of archived deployments.

In nostage mode, the Web application container automatically detects changes to JSPs and servlets. Nostage also allows you to later update only parts of an application by updating those parts in one file system location and then redeploying.

The Administration Console uses nostage mode as the default when deploying only to the Administration Server (for example, in a single-server domain). weblogic.Deployer uses the target server’s staging mode, and Administration Servers use nostage mode by default. You can also select nostage mode if you run a cluster of server instances on the same machine, or if you are deploying very large applications to multiple machines that have access to a shared directory. Deploying very large applications in nostage mode saves time during deployment because no files are copied.

Using Stage Mode Deployment

In stage mode, the Administration Server copies the deployment files from their original location on the Administration Server machine to the staging directories of each target server. For example, if you deploy a Java EE Application to three servers in a cluster using stage mode, the Administration Server copies the deployment files to directories on each of the three server machines. Each server then deploys the Java EE Application using its local copy of the archive files.

When copying files to the staging directory, the Administration Server creates a subdirectory with the same name as the deployment name. So if you deployed using the command:

java weblogic.Deployer -adminurl http://localhost:7001 -user weblogic
   -password weblogic -name mytestear -stage -targets mycluster
   -deploy c:\bea\wlserver_10.0\samples\server\medrecd\dist\physicianEar

a new directory, mytestear, would be created in the staging directory of each server in mycluster. If you do not specify a deployment name, a default deployment name (and staging subdirectory) is used:

§  For exploded archive deployments, the deployment name and staging subdirectory are the name of the directory you deployed (physicianEar in the example above).

§  For archived deployments, the default deployment name is the name of the archive file without the extension. For example, if you deploy physicianEar.ear, the deployment name and staging subdirectory are physicianEar.

The Administration Console uses stage mode as the default mode when deploying to more than one WebLogic Server instance. weblogic.Deployer uses the target server’s staging mode as the default, and Managed Servers use stage mode by default.

Stage mode ensures that each server has a local copy of the deployment files on hand, even if a network outage makes the Administration Server unreachable. However, if you are deploying very large applications to multiple servers or to a cluster, the time required to copy files to target servers can be considerable. Consider nostage mode to avoid the overhead of copying large files to multiple servers.

Using External_stage Mode Deployment

External_stage mode is similar to stage mode, in that target servers deploy using local copies of the deployment files. However, the Administration Server does not automatically copy the deployment files to targeted servers in external_stage mode; instead, you must copy the files to the staging directory of each target server before deployment. You can perform the copy manually or use automated scripts.

Within each target server’s staging directory, deployment files must be stored in a subdirectory that reflects the deployment name. This can either be the name you type in for the deployment, or the default deployment name (the name of the exploded archive directory, or the name of the archive file without its file extension).

External_stage mode is the least common deployment staging mode. It is generally used only in environments that are managed by third-party tools that automate the required copying of files. You may also choose to use external_stage mode when you are deploying very large applications to multiple machines and you do not have a shared file system (and cannot use nostage mode). Using external_stage in this scenario decreases the deployment time because files are not copied during deployment.

You can use the -noversion option to turn off the requirement that deployment files be on the Administration Server, but the -noversion option causes versioning information to be ignored so you cannot use the -noversion option with versioned applications.

Resources
http://docs.oracle.com/cd/E11035_01/wls100/deployment/deploy.html#wp1027044