Uploaded image for project: 'XWiki Platform'
  1. XWiki Platform
  2. XWIKI-25259

Run the extension index and security scan schedulers on a single cluster member

    XMLWordPrintable

Details

    • Improvement
    • Resolution: Unresolved
    • Major
    • None
    • 12.10
    • None
    • Unknown

    Description

      Problem

      In a cluster whose members share a remote Solr server (solr.type=remote), the extension index (extension_index core) is shared by all the members, but each member runs the extension index and security scan background work as if it were alone:

      • ExtensionIndexInitializerListener starts the ExtensionIndexJobScheduler on every member at ApplicationReadyEvent: each member runs an ExtensionIndexJob right away and then every hour, so N members crawl the searchable remote extension repositories N times (N times the outgoing traffic, and N failures on a site without internet access) and N writers update the same Solr core concurrently.
      • ExtensionIndexCleanupListener runs on ApplicationStartedEvent on every member and deletes from the shared core every entry marked as core or installed extension that the starting member's own core and installed extension repositories do not know. A member whose installed extensions differ or lag behind (for example during a rolling upgrade) deletes entries which are valid for the other members.
      • ExtensionSecurityInitializerListener starts the ExtensionSecurityScheduler when a local extension index job finishes. Its comment assumes that this happens on a single member, but since every member runs its own index job, every member starts its own security scanner. Members scanning at about the same time each count the same vulnerabilities as new, so administrators can receive duplicate "new security vulnerabilities" notifications.

      Finding from a review of the code for running XWiki in a Kubernetes cluster (code reading, not reproduced: in particular the duplicate notifications were not observed).

      Proposal

      Use the cluster singleton node (see the linked issue) when the extension index is shared, that is when remote observation is enabled and Solr is remote:

      • The extension index scheduler runs only on the singleton node, for the main wiki and all the subwikis (the singleton node may serve no request, so the subwikis are never loaded there). When an instance becomes the singleton node it starts the scheduler (the previous singleton node may have stopped in the middle of an indexing); when it loses that role it cancels the periodic indexing without interrupting a running job.
      • The cleanup of the extension index runs only on the singleton node, at startup and when an instance becomes the singleton node.
      • The security scanner is started only on the singleton node after its index job, started when an instance becomes the singleton node (if an index job already ran there) and stopped when it loses that role.
      • An administrator who explicitly starts an indexing from the UI of another member still gets that job run on that member.

      Without cluster, or when each member has its own embedded Solr (and so its own extension index), nothing changes.

      Attachments

        Issue Links

          Activity

            People

              ciaens Clément Christiaens
              ciaens Clément Christiaens
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

                Created:
                Updated: