[
https://issues.apache.org/jira/browse/SLING-3195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli resolved SLING-3195.
--------------------------------
Resolution: Fixed
Assignee: Stefan Egli
The ClusterView.getId is now stable according to the following aspects:
* there is a new property 'clusterId' stored in the (voting)view.
* this property is created when a new vote is started.
** when there is an established view at that point in time, the clusterId of
that established view is kept - hence it becomes stable
** when there is no established view at that point, then a new one has to be
defined the first time. For that, the viewId itself is taken - which
corresponds to the clusterId that was defined for the 'isolated mode'. Hence
for one-node cases the clusterId is also stable in this case.
In the case where an instance joins another cluster, the clusterId of that
joining instance will change. This is unavoidable and completely acceptable.
In the case of a (network) partitioning, the two split parts will retain the
clusterId. If the two split parts are (through connectors) part of the same
topology this results in two clusters of a topology having the same clusterId.
Depending on the point of view, this is a bug or a feature: it can be used to
detect (network) partitioning cases.
> Provide a property to uniquely identify a Cluster
> -------------------------------------------------
>
> Key: SLING-3195
> URL: https://issues.apache.org/jira/browse/SLING-3195
> Project: Sling
> Issue Type: New Feature
> Components: Extensions
> Affects Versions: Discovery Impl 1.0.0
> Reporter: Chetan Mehrotra
> Assignee: Stefan Egli
> Fix For: Discovery Impl 1.0.2
>
>
> In some scenarios we need to unique idenitfy a cluster via stable identifier.
> ClusterView provides an ID property but that is termed as unstable
> [SLING-3164]. It would be helpful if it can be made stable or some other
> mechanism is provided to identify the cluster
> Mail Thread - http://markmail.org/message/kf3pydso7eruiwfg
--
This message was sent by Atlassian JIRA
(v6.1#6144)
