Details

JIRA feedback is collected from a number of different sources and is evaluated when planning the product roadmap. If you would like to know more about how JIRA Product Management uses customer input during the planning process, please see our post on Atlassian Answers.

Description

Since 3.13 we have seen an increase in cases with the following error message:

The last packet sent successfully to the server was XXXXX seconds ago, which is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem.

In each case the autoReconnect parameter has been set to true, as per the documentation

The use of this feature is not recommended, because it has side effects related to session state and data consistency when applications don't handle SQLExceptions properly, and is only designed to be used when you are unable to configure your application to handle SQLExceptions resulting from dead and stale connections properly. Alternatively, investigate setting the MySQL server variable "wait_timeout" to some high value rather than the default of 8 hours.

Need to investigate the possible cause of the problems and potential workarounds / fixes.

Summary of Findings:

The MySQL "autoReconnect" parameter is useless and can be removed

The best (simplest) way to make JIRA able to survive MySQL connection timeouts is to set the validationQuery parameter.
See Surviving Connection Closures for details.

The reason that JIRA used to survive these closures prior to v3.13, was that the DB pool we used was accidentally resetting closed connections.