Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-37710

Confluence remigrates our content on restart if a plugin is updated

XMLWordPrintable

      The recent fix in Confluence 5.7.4 ( CONF-35004 ) means that on each restart following a plugin update/upgrade/install, Confluence attempts to re-migrate all our "unmigrated" pages (1,800 pages and their attachments) because we have some unknown macros in those pages. These pages seem to get re-migrated again if we update any plugin, enable/re-enable plugins followed by a restart.

      This is polluting the change history of the pages because it adds another version on each page. It also appears that the attachments on those pages are getting re-indexed.

      I understand the fix may have been intentional but it's having some bad side-effects.

      Also related:

      Workaround

      A workaround has been added to the description of related ticket CONF-32837, which provides a method via SQL to disable the remigration job on restarts. As with all database manipulation tasks, please be sure to test this on a non-Production environment first.

      In the release of 5.10.8, a system variable is added to turn off the remigration behavior during startup. To use this feature:

      1. open CONF_INSTALL_FOLDER/bin/setenv.sh (or setenv.bat under windows)
      2. locate "CATALINA_OPTS" and add the below line to the file:
        CATALINA_OPTS="-Dconfluence.startup.remigration.disable=true $ {CATALINA_OPTS}"
      3. save the file and restart tomcat

          Form Name

            [CONFSERVER-37710] Confluence remigrates our content on restart if a plugin is updated

            Robert Chang added a comment -

            A workaround has been added to the description of related ticket CONF-32837, which provides a method via SQL to disable the remigration job on restarts. As with all database manipulation tasks, please be sure to test this on a non-Production environment first.

            Robert Chang added a comment - A workaround has been added to the description of related ticket CONF-32837 , which provides a method via SQL to disable the remigration job on restarts. As with all database manipulation tasks, please be sure to test this on a non-Production environment first.

            Richard Atkins added a comment -

            The migration code triggers when a plugin with a xhtml-macro is installed, in case it used to only be a regular wikimarkup macro, or in case that macro wasn't present at all, but now is.

            We can make the code a lot smarter about how it chooses what content to migrate, and which macro installs should trigger it. This can include:

            • if we're doing a plugin upgrade, and the old version had xhtml-macro "foo", and the new version has xhtml-macro "foo", then don't migrate anything
            • if we're doing a plugin upgrade, and the old version had wikimarkup macro "foo", and the new version has xhtml-macro "foo" - check (via the search index) if there are any usages of "foo" in unmigrated content. If there are none, then don't migrate anything
            • if we're doing a plugin upgrade, and the old version didn't have any macros, but the new version has xhtml-macro "foo" - check (via the search index) if there are any usages of "foo" in unmigrated content. If there are none, then don't migrate anything

            We can also be smarter about whether we store a new version of a page when migrating. If we didn't actually change anything, then we shouldn't store the new version. Note that as of Confluence 5.8, we inject a macroId into the content for each xhtml-macro, so any check for changes to save will need to ignore that. There is also a known issue around remigration inserting redundant empty paragraphs around block-level macros that can ruin padding on some tables and comments (or any place where we don't do a great job of collapsing adjacent newlines) - any fix should address this issue as well.

            Richard Atkins added a comment - The migration code triggers when a plugin with a xhtml-macro is installed, in case it used to only be a regular wikimarkup macro, or in case that macro wasn't present at all, but now is. We can make the code a lot smarter about how it chooses what content to migrate, and which macro installs should trigger it. This can include: if we're doing a plugin upgrade, and the old version had xhtml-macro "foo", and the new version has xhtml-macro "foo", then don't migrate anything if we're doing a plugin upgrade, and the old version had wikimarkup macro "foo", and the new version has xhtml-macro "foo" - check (via the search index) if there are any usages of "foo" in unmigrated content. If there are none, then don't migrate anything if we're doing a plugin upgrade, and the old version didn't have any macros, but the new version has xhtml-macro "foo" - check (via the search index) if there are any usages of "foo" in unmigrated content. If there are none, then don't migrate anything We can also be smarter about whether we store a new version of a page when migrating. If we didn't actually change anything, then we shouldn't store the new version. Note that as of Confluence 5.8, we inject a macroId into the content for each xhtml-macro, so any check for changes to save will need to ignore that. There is also a known issue around remigration inserting redundant empty paragraphs around block-level macros that can ruin padding on some tables and comments (or any place where we don't do a great job of collapsing adjacent newlines) - any fix should address this issue as well.

              zzhou Zhenhuan Zhou (Inactive)
              a38518e05741 David Yu
              Affected customers:
              2 This affects my team
              Watchers:
              19 Start watching this issue

                Created:
                Updated:
                Resolved: