Improve Plugin Management

Description

The plugin manager:

  • Should process plugins in a parent/child hierarchy in order. This prevents child plugin loading to be deferred when a parent plugin has not yet been loaded. This requires waiting for another execution of the monitor, which can add up of there's a longer hierarchy.

  • Could process non-related plugins in parallel (which can considerably speed up the initial loading of plugins directly after Openfire is started).

  • The code-base should be split in multiple classes, bringing some order in the hodgepodge that is now the code

  • Plugin canonical names should always be determined in the same way (notably, some existing code neglects to lower-case the directory name).

  • Code should be updated to make use of the Java 7+ file system integration.

  • Dev-plugins should not be loaded 'outside' of the normal plugin load routines, as this circumvents various checks. Dev plugin paths should be processed in the same way as regular plugins directory.

  • Plugins that fail to load should not be retried every iteration. Instead, they should be marked as failed (eventually).

  • Plugin hierarchies that have a loop should properly be detected.

Environment

None

Activity

Show:

Guus der Kinderen June 14, 2016 at 7:23 AM

This PR contains the related changes (which turned out to be a refactoring): https://github.com/igniterealtime/Openfire/pull/598

Two new properties were introduced:

  • plugins.loading.retries (default to 5): Maximum attempts to load a plugin, before giving up.

  • plugins.loading.max-parallel (defaults to 4): Number of concurrent processes that initialize plugins during startup of the server. After the initial boot of Openfire, no more than 1 thread is used, as no more than one plugin is expected to change at the same time.

Fixed

Details

Assignee

Reporter

Fix versions

Priority

Created June 10, 2016 at 1:12 PM
Updated December 18, 2016 at 3:10 PM
Resolved December 18, 2016 at 3:10 PM

Flag notifications