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

Macro Migration Service is Automatically Set to True After Upgrade

XMLWordPrintable

      After upgrading to Confluence version 5.1.5, the Macro Migration Service configuration in BANDANA table is set to true.

      Configuration can be found by using this query:

      SELECT * FROM bandana WHERE BANDANACONTEXT = 'com.atlassian.confluence.content.render.xhtml.migration.macro.MacroMigrationService' AND BANDANAKEY = 'migration.required';

      This causes Confluence instance with lot of pages and users suddenly performing great number of editing operations in the database and may cause an outage.

          Form Name

            [CONFSERVER-32318] Macro Migration Service is Automatically Set to True After Upgrade

            Paul Curren added a comment -

            Hi Deivdi,

            I'm afraid there is no configurable way of disabling this behaviour. The best option I can give is to reduce the amount of resource it is using.
            Set the system property remigration.threads to 1 and set remigration.batchsize to 10.

            Cheers,

            Paul C

            Paul Curren added a comment - Hi Deivdi, I'm afraid there is no configurable way of disabling this behaviour. The best option I can give is to reduce the amount of resource it is using. Set the system property remigration.threads to 1 and set remigration.batchsize to 10. Cheers, Paul C

            Steve Haffenden (Inactive) added a comment -

            Hi Patrice

            This is working as design and as such is not a bug. From one of the developers on the team:

            Any time a plugin is installed or updated (such as will happen on system upgrade) a search is performed to find any pages in the system that haven't been migrated from wiki markup yet. These pages won't have been converted because they used macros which had no XHTML version. (Hence the reason we give it another go when plugins are upgraded.). This is working as designed.

            As such I'm going to close this issue out.

            Regards
            Steve Haffenden
            Confluence Bugmaster
            Atlassian

            Steve Haffenden (Inactive) added a comment - Hi Patrice This is working as design and as such is not a bug. From one of the developers on the team: Any time a plugin is installed or updated (such as will happen on system upgrade) a search is performed to find any pages in the system that haven't been migrated from wiki markup yet. These pages won't have been converted because they used macros which had no XHTML version. (Hence the reason we give it another go when plugins are upgraded.). This is working as designed. As such I'm going to close this issue out. Regards Steve Haffenden Confluence Bugmaster Atlassian

            Paul Curren added a comment -

            I'm not sure this should be a bug.

            Basically, any time a plugin is installed or updated (such as will happen on system upgrade) a search is performed to find any pages in the system that haven't been migrated from wiki markup yet. These pages won't have been converted because they used macros which had no XHTML version. (Hence the reason we give it another shot when plugins are upgraded.)

            This is working as designed. So I'm thinking of any of the following are actually better fixes to make -

            1. Make the MacroMigrationService a blocking operation which puts the system out of action while it runs.
            2. Make the MacroMigrationService a manually invoked operation. When we detect it should run we somehow notify an admin and have them invoke it at a time that is suitable.
            3. Make the MacroMigrationService less resource intensive so that there is no threat of an outage.

            And with respect to (3) there are system properties you can use to control how much memory and how much CPU the macro migration will consume.

            Paul Curren added a comment - I'm not sure this should be a bug. Basically, any time a plugin is installed or updated (such as will happen on system upgrade) a search is performed to find any pages in the system that haven't been migrated from wiki markup yet. These pages won't have been converted because they used macros which had no XHTML version. (Hence the reason we give it another shot when plugins are upgraded.) This is working as designed. So I'm thinking of any of the following are actually better fixes to make - Make the MacroMigrationService a blocking operation which puts the system out of action while it runs. Make the MacroMigrationService a manually invoked operation. When we detect it should run we somehow notify an admin and have them invoke it at a time that is suitable. Make the MacroMigrationService less resource intensive so that there is no threat of an outage. And with respect to (3) there are system properties you can use to control how much memory and how much CPU the macro migration will consume.

              shaffenden Steve Haffenden (Inactive)
              prompas Patrice Rompas (Inactive)
              Affected customers:
              0 This affects my team
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: