JIRA Software 7.4.x upgrade notes

Please follow the instructions in the general Upgrading JIRA applications guide, as well as the JIRA Software 7.4.x specific instructions below. The general guide contains important tasks that are essential for getting your upgraded JIRA installation to work correctly and, if necessary, migrating existing configurations.

You should also make sure that your licenses and add-ons are all up-to-date. Removing any incompatible add-ons before upgrading may help you avoid problems during your upgrade process. You can check the compatibility of your add-ons before your upgrade using the JIRA update check. You can start JIRA from the command line with your add-ons disabled if you're having issues.

This page describes known issues as well as changes you should be aware of before deciding whether or not to upgrade to JIRA Software 7.4.x.

On this page:

Information for JIRA developers

See Preparing for JIRA 7.4 for important information that could affect your add-ons or scripts. Also, see our Java API policy for JIRA.

Information for administrators

Modified startup files

We’ve added new options to the setenv.bat / setenv.sh file to enable garbage collection (GC) logging on JIRA startup. GC logs can be used to monitor the performance of JIRA by indicating when Java is collecting garbage, how long this process takes, and which resources can be freed. When you start the upgraded JIRA, the new log files will be stored in <installation-directory>/logs. For more info on GC logging, see Using garbage collection logs.

These are the new options:

-XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCTimeStamps -XX:+PrintGCCause -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=20M -Xloggc:"%atlassian_logsdir%\atlassian-jira-gc-%%t.log"

Running JIRA on MySQL

MySQL introduced a change in MySQL 5.7.6 which requires your JIRA user for the data base to have the REFERENCES permission. If you're upgrading to JIRA Software 7.4 and MySQL 5.7.6 or above, you need to make sure your JIRA user has this permission.

Running JIRA applications over SSL

We upgraded Apache Tomcat in JIRA Software 7.3, and if you're running your JIRA application over SSL, and have already configured Apache Tomcat with HTTPS, you'll need to update your server.xml HTTPS connector with the correct protocol. If you don't, JIRA will fail to start. To update the required protocol:

1. Make sure JIRA is stopped.
2. Navigate to your server.xml page at <JIRA_INSTALL>/conf/server.xml.

3. Locate your HTTPS connector, which will look something similar to this:

   <Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol"
                 maxHttpHeaderSize="8192" SSLEnabled="true"
                 maxThreads="150" minSpareThreads="25"
                 enableLookups="false" disableUploadTimeout="true"
                 acceptCount="100" scheme="https" secure="true"
                 clientAuth="false" sslProtocol="TLS" useBodyEncodingForURI="true"
                 keyAlias="jira" keystoreFile="<JIRA_HOME>/jira.jks" keystorePass="changeit" keystoreType="JKS"/>

   and change the protocol so that it looks more like this:

   <Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"
                 maxHttpHeaderSize="8192" SSLEnabled="true"
                 maxThreads="150" minSpareThreads="25"
                 enableLookups="false" disableUploadTimeout="true"
                 acceptCount="100" scheme="https" secure="true"
                 clientAuth="false" sslProtocol="TLS" useBodyEncodingForURI="true"
                 keyAlias="jira" keystoreFile="<JIRA_HOME>/jira.jks" keystorePass="changeit" keystoreType="JKS"/>

4. Save your changes.
5. Start JIRA.

You may perform these steps during your upgrade, but make sure you perform them before you start JIRA at the end of the upgrade process.

Automatic backup removal

Previous JIRA versions created an automatic XML backup whenever JIRA attempted an upgrade. This process was very resource intensive, prone to errors, and we never recommended it. As such, we've removed it completely, and continue to recommend you always perform a backup using your native database tools.

JIRA Software Data Center zero downtime upgrades

JIRA Software Data Center 7.3 included the functionality to upgrade the JIRA nodes on your clustered instance to subsequent JIRA Software versions with zero downtime. This is only achievable when you upgrade from JIRA Software 7.3 to a higher version, such as JIRA Software 7.4.x.

If you're running a version of JIRA Software Data Center within the range of 7.3.2 to 7.3.6, and you're performing a zero downtime upgrade to JIRA Software 7.4.x, there is a known issue whereby the Support Tools plugin's Cluster Cache Replication check will fail. While performing the upgrade as a System administrator, if you check  > System > Support Tools > Instance Health Check, you'll see the error messages. These can be safely ignored. This only occurs with the bundled version of the Support Tools plugin. If you manually upgrade the Support Tools plugin before you start your zero downtime upgrade, this issue will not occur.

Version specific detail

• Upgrading from a 7.1 or later version - There are no known issues.
• Upgrading from a 7.0.x version - There is a known issue regarding gadgets, and there is a workaround described in the JIRA Software 7.1.x upgrade notes.
• Upgrading from a version earlier than 7.0 - Please consult the Migration hub as it contains information on important user management, application access and log in changes. You must upgrade to JIRA Software 7.0 first (we always recommend the latest bugfix release, in this case 7.0.11), before upgrading to JIRA Software 7.4.