Setting Server State

Setting server state during an install

Overview

There are a number of ways to set server state during and post install. These fall into two categories:

  • Those managed from within the WebSphere part of the install, including rolling updates, stop/start server etc
  • Those managed by the deploy process orchestration scripts. Include post-install stop/start/ripple

Controlled from deployment orchestration scripts

Please see the WebSphere specific tasks documentation for starting/stopping servers and clusters.

Controlled from the Jython deploy process

By default, during an install, all cluster members on all nodes are stopped at the start of the deployment and will not be restarted again at the end of the deployment. The following parameters may be used to modify this behavior.

The following variables may be set:

Variable Description Default Value
restartServerAfterInstall Restart a server following an installation. Note that the server will only be restarted if it was running prior to the install. If set to false it will never be restarted afer an install. false
requirePreInstallClusterRunning Requires that, to perform an install the cluster must be running before the deploy is started. If this is set to 'true', deployments to environments where the cluster is stopped will fail Set to 'true' for WebSphere Process Server false
disableRestarts By default, a cluster is always stopped prior to a deployment. Setting this parameter prevents that stop from occurring and disables restarts of the cluster. This is set by the performRollingUpdate if the performRollingUpdate pre checks are successful. It can also be set in the Jython file explicitly and must be set for WebSphere Process server. false
performRollingUpdate Perform rolling updates. You should set restartServerAfterInstall to 'false'. This will update code on each node in the cluster in turn, and restart the servers on that node only after the install. This ensures that the service is always active. Should consider setting session replication to allow seamless session failover during the deployment. false