[
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)
