Upgrading Payara Server

There are two valid methods of fully upgrading to a new release of Payara Server. Either of the following two methods would work in most circumstances:

  1. Backing up and restoring the existing configuration to a new installation.

  2. Maintaining completely separate domain and node directories and pointing the new version to the existing directories.

Method 1: Backup and Restore

This method involves the following steps:

  1. Stop the running domain

    The asadmin backup-domain subcommand will only work if the domain is not running so, if this method is chosen for a production system, there would need to be an arranged period of downtime.
  2. Run asadmin backup-domain from the existing Payara Server installation

  3. Once the domain has been backed up, restore the domain to the newly downloaded Payara Server installation by running asadmin restore-domain from the bin directory of the new Payara Server installation

After following these steps, you should be left with a similar directory structure to the following:

/opt/payara/161/payara41/glassfish/domains/myDomain
/opt/payara/162/payara41/glassfish/domains/myDomain
/opt/payara/backups/myDomain/myDomain_2016_05_27_v00001.zip

This method only backs up the domain directory and its contents. Any instances you have in node directories will need to regenerated by using the --sync=full option of the start-local-instance subcommand:

asadmin start-local-instance --sync=full myInstance

This will recreate the instance from scratch. Be aware, though, that this will not recreate things stored in the instance directory which are outside of the configuration like JMS file stores. If there is any JMS persistence which does not use a database, these must be handled manually.

See Restore a Payara Domain for more detail.

Method 2: Move the domain directory and node directories

An alternative to backing up and restoring the domain, then recreating the instances, would be to create the domain and node directories in a location separate to the installation. For example, if you download Payara Server 4.1.1.154, created a domain, and then wanted to use Payara Server 4.1.1.162, you would use the following process:

/opt/payara/payara-4.1.154/payara41 bin/asadmin create-domain --domaindir /tmp myTempDomain
/opt/payara/payara-4.1.154/payara41 cd ../../payara-4.1.162/payara41
/opt/payara/payara-4.1.162/payara41 bin/asadmin start-domain --domaindir /tmp myTempDomain

This will use the 4.1.1.154 installation to create a new domain, and then run it with the 4.1.1.162 installation.

You can do the same thing with nodes too:

/opt/payara/payara-4.1.154/payara41 bin/asadmin create-node --nodedir /tmp myLocalNode

In this way, the user configuration is always kept separate to the installation, and rollback is as simple as using the previous installation directory.

If you are using Payara Server on Linux, you could take advantage of "symbolic links" to make life easier. When your domain directory is in a non-standard location, it means that you need to specify its location with each start/stop/restart command. If you were to create a symbolic link to the domain directory inside the default domains directory, then all of your existing scripts will carry on as normal.

You could even extend this further to create a symbolic link to whichever Payara Server installation was currently used in production, for example:

/opt/payara/live/payara41/....

This means that any rollback is as simple as stopping the server, updating a symbolic link and starting it again.

Without the use of symbolic links, things get a bit more manual (though still quite straightforward). The asadmin start-domain subcommand has a --domaindir option which allows you to specify the location of a domain directory. So you could have a directory structure like this:

/opt/payara/154/payara41/....
/opt/payara/161/payara41/....
/opt/payara/162/payara41/....
/opt/payara/domains/myDomain
/opt/payara/nodes/myLocalNode

Then you could start your domain with whatever version of Payara Server you wanted:

/opt/payara/154/payara41/bin/asadmin start-domain --domaindir /opt/payara/domains myDomain

…​or like this:

/opt/payara/162/payara41/bin/asadmin start-domain --domaindir /opt/payara/domains myDomain
The --domaindir option specifies the parent directory for your domain and where you would store all of your domains if needed.

You can also start nodes in the same way:

/opt/payara/162/payara41/bin/asadmin start-local-instance --nodedir /opt/payara/nodes myLocalNode

JDK 11: Upgrade Considerations

Applies to Payara Server 5.192 and superior releases

The domain.xml configuration file contains instructions for handling JDK 11. Without these instructions, Payara Server will not start up on JDK 11 and/or will throw many exceptions during runtime.

If older, pre-5.192, domains are being migrated this has to be taken into account. The following jvm-options have to be added to the java-config element in domain.xml:

<jvm-options>[9|]--add-opens=java.base/jdk.internal.loader=ALL-UNNAMED</jvm-options>
<jvm-options>[9|]--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED</jvm-options>
<jvm-options>[9|]--add-exports=java.base/jdk.internal.ref=ALL-UNNAMED</jvm-options>
<jvm-options>[9|]--add-opens=java.base/java.lang=ALL-UNNAMED</jvm-options>
<jvm-options>[9|]--add-opens=java.base/java.nio=ALL-UNNAMED</jvm-options>
<jvm-options>[9|]--add-opens=java.base/sun.nio.ch=ALL-UNNAMED</jvm-options>
<jvm-options>[9|]--add-opens=java.management/sun.management=ALL-UNNAMED</jvm-options>
<jvm-options>[9|]--add-opens=java.base/sun.net.www.protocol.jrt=ALL-UNNAMED</jvm-options>
<jvm-options>[9|]-Xbootclasspath/a:${com.sun.aas.installRoot}/lib/grizzly-npn-api.jar</jvm-options>

The following jvm-options have to be removed:

<jvm-options>-Djava.endorsed.dirs=${com.sun.aas.installRoot}/modules/endorsed${path.separator}${com.sun.aas.installRoot}/lib/endorsed</jvm-options>
<jvm-options>-Djava.ext.dirs=${com.sun.aas.javaRoot}/lib/ext${path.separator}${com.sun.aas.javaRoot}/jre/lib/ext${path.separator}${com.sun.aas.instanceRoot}/lib/ext</jvm-options>