[
https://issues.apache.org/jira/browse/SLING-3164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Egli resolved SLING-3164.
--------------------------------
Resolution: Fixed
Reverted deprecation of getId() and instead marked the id as stable.
There's two special cases to take note of:
* when an instance joins a cluster, it inherits the new cluster's cluster id
(in this situation the cluster id changes for the joining instance)
* when instances part from a cluster, the cluster id is retained (in this
situation there can be potentially multiple clusters with the same id - hence
the cluster id is not unique in this situation. This fact can be used to detect
split brain/network partitioning situations)
> Clarify ClusterView.getId (was: Clarify and deprecate ClusterView.getId)
> ------------------------------------------------------------------------
>
> Key: SLING-3164
> URL: https://issues.apache.org/jira/browse/SLING-3164
> Project: Sling
> Issue Type: Bug
> Affects Versions: Discovery API 1.0.0
> Reporter: Stefan Egli
> Assignee: Stefan Egli
> Fix For: Discovery API 1.0.2
>
>
> As discussed on the list (at [0]) the ClusterView.getId() is currently
> unspecific about whether the id is stable/persistent or not. The current
> implementation of it is not stable and returns a new id with every changing
> cluster view. Without assumptions on the underlying implementation details it
> is not trivial to provide a stable id. This contrasts to the slingId of an
> InstanceDescription - which is guaranteed to be stable. A cluster can reshape
> and join another cluster, hence a cluster id is not trivial to be stable.
> The suggestion is to clarify the unstable nature of that id in its javadoc
> and marking it as deprecated - since there is no use for an unstable id
> really.
> --
> [0] - http://markmail.org/message/kf3pydso7eruiwfg
--
This message was sent by Atlassian JIRA
(v6.1#6144)
