Restarting the PolicyCenter cluster servers

There are several different scenarios that require you to bring down one or more members of the PolicyCenter cluster and then restart the servers.

Server restart after server maintenance

In performing maintenance on the servers in the PolicyCenter cluster, do the following for each PolicyCenter server in the Guidewire cluster, as required:

  • Set the server run level to maintenance.
  • Perform the needed work.
  • Restart the server.

Server restart after rolling upgrade

In an application configuration upgrade (known as rolling upgrade), you bring down a single server, in the cluster, upgrade its application configuration, and bring that server back up. You then repeat this process with each member of the PolicyCenter cluster in turn, until all cluster members use the upgraded configuration.

Important: Start the configuration upgrade on a single cluster server and let it fully initialize before starting the upgrade process on the other cluster members.

Before starting a rolling upgrade, click Start Rolling Upgrade in the Server Tools Upgrade and Versions screen. You can do this on any server in the PolicyCenter cluster. This action indicates that a rolling upgrade of the individual cluster members is in progress.

After completing the upgrade of all cluster servers, click Rolling Upgrade Complete in the Server Tools Upgrade and Versions screen. This action indicates that all servers in the cluster now use the upgrade WAR/EAR file and that the rolling upgrade process is complete.

Server restart after full PolicyCenter upgrade

In a full upgrade, you bring down all members of the PolicyCenter cluster completely. Before starting a full upgrade, click Start Full Upgrade in the Server Tools Upgrade and Versions screen. You can do this on any server in the PolicyCenter cluster. This action sets a flag in the PolicyCenter database to indicate that a full upgrade is in progress. As long as the upgrade-in-progress flag exists, it is not possible to start a PolicyCenter cluster member that uses the old (non-upgrade) WAR/EAR file.

In a full database upgrade, you must start a single cluster server and allow it to complete the full upgrade cycle before starting the upgrade on the remaining servers. After all the servers in the PolicyCenter cluster start with the upgrade WAR/EAR file, PolicyCenter automatically deletes the upgrade-in-progress flag from the PolicyCenter database.

Use the following guidelines as you bring up the individual cluster members:

  • After the first cluster server completes the upgrade cycle, it is possible to bring up all other servers in the PolicyCenter cluster in parallel. However, if starting a large numbers of servers causes resource contention, insert a short interval of time between each server start, for example, 10 seconds.
  • As a general rule, start servers that manage back-end processes first. For example, start servers with the batch and messaging roles before starting servers with the ui role.

Server restart after database restore

It is sometimes the case that you want to restore the PolicyCenter cluster database from one of the following:
  • A non-cluster server
  • A server in a different cluster environment but with the same code base

Attempting to start the PolicyCenter server after the database restore can generates database errors sufficient to cause the server to not start. To prevent these errors, it is necessary to start a single cluster node and let it cycle through a full database upgrade before starting the other members of the PolicyCenter cluster.

To set the full upgrade flag on a server as you start the server, use the following JVM system property, with YYYYMMDD being today's date:
  • -Dgw.pc.full.upgrade.intended.date=YYYYMMDD
For example:
  • gwb runServer -Dgw.pc.full.upgrade.intended.date=20180726

After the first server completes the database upgrade operation, start the other servers in the PolicyCenter cluster.

Server restart after database outage

In the unlikely event in which the PolicyCenter database node is not shut down gracefully (due to a disaster, perhaps), it is possible to encounter errors as you restart the database node.

User interface (UI) connections
User interface (UI) processes that have their connections interrupted, or, that have gone stale after obtaining connection objects, can experience errors. However, PolicyCenter eventually evicts these items from the application cache. After the database is online again and standard operations resume, PolicyCenter creates new, clean, connection objects.
Batch processes
Batch processes (writer or fat batch processes) can experience errors after a database failure. However, these batch processes will run again at the next scheduled execution, or, you can start the batch processes manually, if desired.
Messaging destinations
It is possible for messaging destinations to be suspended during database outage due to repeated, failed, retries of the messaging destination. If so, you need to restart the suspended destinations manually.