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

Plugin being disabled after being upgraded or re-enabled

    XMLWordPrintable

Details

    Description

      Symptoms

      The problem appears to be that a plugin is somehow disabled after a Confluence instance is restarted. If you look through the logs you'll find something like:

      WARN ... [com.atlassian.plugin.DefaultPluginManager] isPluginEnabled Plugin com.atlassian.confluence.extra.widgetconnector is out of sync with the plugin system, disabling
      

      If you look at the access logs for the same time, you should find that someone was administering that plugin either via the Plugins or Plugin Repository admin areas.

      You might also see messages in the main log of the form:

      ERROR ... [atlassian.renderer.v2.V2Renderer] render Unable to render content due to system error: Cannot retrieve plugin module before it is enabled: PluginModuleHolder[com.atlassian.confluence.extra.widgetconnector.WidgetMacro@3c6957]
      

      when users make subsequent calls to pages that use the plugin. Note that the plugin might still appear enabled after the time of the first log message, but it will be disabled after a Confluence restart.

      Cause

      There is a known issue with the Atlassian Plugin framework (PLUG-222) where, if a plugin's "enabled" state is queried in one thread while it is being changed in another (due to an upgrade, uninstall/reinstall or disable/enable) the plugin's state will be set to "disabled". However, this state may not be getting checked until Confluence is restarted because a subclass of DefaultPluginManager, ConfluencePluginManager, stores the enabled state separately.

      Plugin state can be checked very frequently, depending on the cache, so the problem can be caused by almost any usage of Confluence during the small window of plugin state change (typically less than a second).

      The fix for the problem will involve a change to the Plugin framework code to "lock" the plugin's state while it is being administered, and most likely a reworking of the ConfluencePluginManager code to better synchronize the state.

      Workaround

      The problem arises because the plugin is being accessed while it's being altered and will not occur during everyday usage. To re-enable an incorrectly-disabled plugin, simply enable the plugin when no-one is using Confluence, and check the logs to confirm that the above warning message doesn't re-appear.

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              dtaylor David Taylor (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: