tree 667e582963b7cfe1d68b6f613cbaa6b6231d3978
parent d970c3787d20ad6c7a0d04bb9ac23988f6fd2962
author Gancho Tenev <gancho@apache.org> 1569616102 -0700
committer Bryan Call <bcall@apache.org> 1571414664 -0700

"Plugin (un)used" post reload notification

Most of the plugins is assumed to use per-plugin-instance data-structures
when reloading their configs and only a few of them that wish to optimize
performance or deal with the complexities of using per-plugin DSO "global"
data-structures would use plugin configuration reload notifications like
`TSRemapPreConfigReload` and `TSRemapPostConfigReload`.

Instead of trying to foresee the needs or the expectations of each use-case,
a more "open-ended" and straight-forward design was chosen for the configuration
reload notifications. The notifications are broadcasted to all loaded plugins
at the moments before and after the reload attempt, regardless of whether
a plugin is part of the new configuration or not.

During the `TSRemapPostConfigReload` we already decided to notify the
plugin if the plugin reload was successful or not so the plugins can
recover adequately in case of configuration reload failure.

This change adds a signal to show if the particular plugin was part of
the new configuration. This will be beneficial for use-cases that expect
plugin reload notification not to be called in case they are not part of
the new configuration so they can ignore the notification.

This change also attempts to clarify related documentation and code
comments as well.