[jira] [Commented] (SLING-12283) Configuration in Cluster mode are not in sync

["Julian Sedding (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SLING-12283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17861063#comment-17861063 ] 

Julian Sedding commented on SLING-12283:
----------------------------------------

Further analysis showed that this issue occurs when a factory configuration is manually created using the Felix webconsole. The webconsole uses the API {{ConfigurationAdmin#createFactoryConfiguration(...)}} to create such a configuration. In contrast to the {{ConfigurationAdmin#getFactoryConfiguration(...)}} methods, which create a {{service.pid}} by concatenating the {{factoryPid}}, a tilde character ('~') and the "name" part (an arbitrary string passed by the caller), the {{ConfigurationAdmin#createFactoryConfiguration(...)}} methods, as implemented by Felix' implementation of the Configuration Admin specification, create a {{service.pid}} by concatenating the {{factoryPid}}, a dot character ('.') and a randomly generated UUID. The UUID part cannot be controlled by the caller of the message, and thus it is impossible to re-create a factory configuration with the exact same {{service.pid}} on a second cluster node.

The strategy implemented in PR #15 works as follows:
(1) The {{ConfigTaskCreator}} class, which implements the {{ResourceTransformer}} interface, already extracts the {{service.pid}}, and in the case of a factory configuration the {{factoryPid}}, from the filename of a {{RegisteredResource}} representing a configuration. In this extraction logic, the {{service.pid}} extracted from the filename is first matched against the format of configurations created using Felix' {{ConfigurationAdmin#createFactoryConfiguration(...)}} implementation, and the {{factoryPid}} and {{name}} are extracted. If it doesn't match, the previous logic, looking for a '~' separator etc is used.
(2) In the {{ConfigUtil#getConfiguration(...)}} method, which is used to check if a given configuration already exists, a check for a configuration using a "legacy naming convention" is used if no configuration was found with a name following the expected '~' separated format.

With these two changes the behaviour is as follows:
# a factory configuration is created on cluster node A using the webconsole
# via {{org.apache.sling.installer.provider.jcr}}, the configuration is persisted in the JCR repository using the format {{<factoryPid>.<random uuid>}}
# cluster node A sees the new RegisteredResource for the configuration, but finds a "live" configuration via the legacy support from point (2) above
# cluster node B sees the new RegisteredResource for the configuration, doesn't find a matching "live" configuration, and adds the configuration in the format {{<factoryPid>~<name>}}, where {{<name>}} is the same uuid used on cluster node A

> Configuration in Cluster mode are not in sync
> ---------------------------------------------
>
>                 Key: SLING-12283
>                 URL: https://issues.apache.org/jira/browse/SLING-12283
>             Project: Sling
>          Issue Type: Bug
>            Reporter: Rishabh Daim
>            Priority: Major
>
> {color:#172b4d}Configuration in Cluster mode is not in sync. When instances are in shared mode, and a new configuration is created under 1st instance, it is not reflected correctly in 2nd instance. {color}
> {color:#172b4d}The factory PID and hence properties are altered in the 2nd instance.{color}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)