Details
-
Bug
-
Resolution: Fixed
-
Low
-
5.7, 5.6.6, 5.7.1, 5.7.3, 5.7.4, 5.8.2, 5.8.4, 5.8.5, 4.7.3
-
None
Description
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
- 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
- There is actually a comment in the source code that STILL EXISTS that states:
- 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.
Attachments
Issue Links
- incorporates
-
CONFSERVER-27094 Misleading information on the log upon startup when using SQL Server
- Closed