| = Container Plugins |
| :toc: macro |
| :toclevels: 3 |
| |
| |=== |
| | Initial version released| 2020, November 2|Andrzej Białecki |
| |=== |
| |
| toc::[] |
| |
| == Container plugins subsystem |
| Container plugins are pluggable components that are defined and instantiated at the |
| `CoreContainer` (node) level. The components usually provide an admin-level API for |
| additional functionality at the Solr node level. |
| |
| === Plugin configurations |
| Plugin configurations are maintained in ZooKeeper in the `/clusterprops.json` file, under |
| the `plugin` entry. The configuration is a JSON map where keys are the plugin names, and |
| values are serialized `org.apache.solr.client.solrj.request.beans.PluginMeta` beans. |
| |
| == Types of container plugins |
| |
| === Plugin life-cycle |
| Plugin instances are loaded and initialized when Solr's `CoreContainer` is first created. |
| |
| Then on each update of the plugin configurations the existing plugin configs are compared |
| with the new configs, and plugin instances are respectively created, removed, or |
| replaced (i.e. removed and added using the new configuration). |
| |
| If a plugin implementation class has a constructor that accepts an instance of |
| `CoreContainer` then it is instantiated using this constructor, and the current instance |
| of `CoreContainer` is passed as argument. |
| |
| === PluginRegistryListener |
| Components that need to be aware of changes in plugin configurations or registration can |
| implement `org.apache.solr.api.ContainerPluginsRegistry.PluginRegistryListener` and register |
| it with the instance of registry available from `coreContainer.getContainerPluginsRegistry()`. |
| |
| === ClusterSingleton plugins |
| Plugins that implement `ClusterSingleton` interface are instantiated on each |
| Solr node. However, their start/stop life-cycle, as defined in the interface, |
| is controlled in such a way that only a single running instance of the plugin |
| is present in the cluster at any time. |
| |
| (Currently this is implemented by re-using the Overseer leader election, so all |
| `ClusterSingleton`-s that are in the RUNNING state execute on the Overseer leader). |
| |
| Any plugin type can implement this interface to indicate to Solr that |
| it requires this cluster singleton behavior. |
| |
| // explain plugins that register Api-s |
| // explain plugins that don't implement any Api |
| === ClusterEventProducer plugin |
| In order to support the generation of cluster-level events an implementation of |
| `ClusterEventProducer` is created on each Solr node. This component is also a |
| `ClusterSingleton`, which means that only one active instance is present in the |
| cluster at any time. |
| |
| If no plugin configuration is specified then the default implementation |
| `org.apache.solr.cluster.events.impl.DefaultClusterEventProducer` is used. A no-op |
| implementation is also available in `org.apache.solr.cluster.events.NoOpProducer`. |
| |
| === ClusterEventListener plugins |
| Plugins that implement the `ClusterEventListener` interface will be automatically |
| registered with the instance of `ClusterEventProducer`. |
| |
| == Plugin management API |
| |
| == Predefined plugin names |
| |
| Plugins with these names are used in specific parts of Solr. Their names are reserved |
| and cannot be used for other plugin types: |
| |
| // XXX uncomment when we move the config to plugins |
| //`placement-plugin`:: |
| //plugin that implements `PlacementPlugin` interface. This type of plugin |
| //determines the replica placement strategy in the cluster. |
| |
| `cluster-event-producer`:: |
| plugin that implements `ClusterEventProducer` interface. This type of plugin |
| is used for generating cluster-level events. |
