Summary

When Confluence switched from wiki markup to XHTML, there was a bug that would deadlock MS SQL Server during the migration process. A stop-gap measure was put in place to temporarily set the number of threads used to 1. This bug was fixed in 4.0.1, but the stop-gap was never removed. Confluence still defaults to 1 thread when an upgrade is occurring on a SQL Server database. Some upgrades are taking upwards of 40 hours to complete due to this.

Environment

• Microsoft SQL Server

Steps to Reproduce

1. Upgrade to Confluence 5.8.4

Expected Results

DefaultSiteMigrator tasks run multi-threaded

Actual Results

DefaultSiteMigrator tasks run in 1 thread.
The below exception is thrown in the atlassian-confluence.log file:

2015-06-17 13:00:37,655 WARN [localhost-startStop-1] [render.xhtml.migration.DefaultSiteMigrator] getNumberOfThreads SQL Server detected so only one thread will be used in migration to avoid dead lock problems.

Notes

• The code to restrict the number of threads was added in 4.0 as a stop-gap to prevent deadlocks from occurring when SQL Server was used
• The deadlock bug was fixed in 4.0.1 but the stop-gap was never removed
  • There is actually a comment in the source code that STILL EXISTS that states:

    This check won't be necessary once CONFDEV-5139 is implemented

• This affects ALL versions of Confluence 4.0.1 and above

Workaround

There is a patch attached to this ticket that will run the migration in multiple threads for SQL Server instances. Steps to apply the patch are in this comment.