FYI: Created https://issues.apache.org/jira/browse/SLING-3164 for this.
Without objections I will go ahead and adjust the javadoc of the API.. Cheers, Stefan On 10/11/13 2:45 PM, "Carsten Ziegeler" <[email protected]> wrote: >Rethink this, I guess my use cases call more for a cluster name or cluster >description - which is a user created information. >The more I think about it, the more I tend to agree that we should >deprecate it and clearly state that the id is not guaranteed to be stable >(for people using is already). And once my use cases are more concrete >than >ideas, we can see how to fulfil them. > >Carsten > > >2013/10/11 Stefan Egli <[email protected]> > >> On 10/11/13 1:35 PM, "Carsten Ziegeler" <[email protected]> wrote: >> >> >Hi, >> > >> >yes, I totally agree either we have the id stable or its of no use - I >> >thought that it is stable, actually :) But fortunately the javadocs are >> >unclear about this. >> >I guess it heavily depends on the used implementation whether a stable >>id >> >is easy to implement or not >> >> Given that we have a cluster leader I would assume that the leader could >> define the cluster Id. However I see problems when two clusters join >>each >> other (as is possible eg in crx): there the two clusters both would have >> had 'stable' cluster ids. After the join, for one of the two parties the >> cluster id would change. Hence it might be inherently impossible to have >> stable cluster ids.. in that case, what's the gain of having it in the >> API.. it would only be 'stable-but'.. >> >> > - I could imagine use cases where the id >> >corresponds to the data center where the cluster is running and >>therefore >> >provide useful information. >> >Therefore I'm a little bit hesitant to remove the method - however we >> >could >> >add javadocs like "it is not guaranteed that the id is stable across >>view >> >changes, however implementation should provide stable ids" >> >> I'd vote for either removing it (ie first deprecating it) or improving >>it >> (ie making it 'stable-but'). >> >> Cheers, >> Stefan >> >> > >> >WDYT? >> > >> >Carsten >> > >> > >> >2013/10/11 Stefan Egli <[email protected]> >> > >> >> Hi, >> >> >> >> The discovery's ClusterView contains a 'getId()' which returns the >> >>current >> >> ClusterView's ID. I'm not sure this ID is any good though. First, it >>is >> >> only valid for the lifetime of the ClusterView - ie if an instance >> >>joins a >> >> cluster, a new ClusterView is created, with a new ID. Second, what >>would >> >> this ID be usable for, especially given the relatively short >> >> validity/lifetime of it? It does not reflect a stable, persistent >> >> identifier of the cluster after all. If you want to learn which other >> >> instances are part of the local instance, then the API already >>provides >> >> that access. >> >> >> >> Comparing this to InstanceDescription.getSlingId(): that one iss by >> >> definition the 'slingId' which is retrieved from SettingsService and >>is >> >> thus guaranteed to be stable/persistent. So the API is somewhat >> >> inconsistent regarding the ClusterView.getId. >> >> >> >> I thus suggest getting rid of ClusterView.getId ie marking it as >> >> deprecated. (Or, an alternative would be to come up with a stable, >> >> persistent clusterId but that is potentially more complex) >> >> >> >> Wdyt? >> >> >> >> Cheers, >> >> Stefan >> >> >> > >> > >> > >> >-- >> >Carsten Ziegeler >> >[email protected] >> >> > > >-- >Carsten Ziegeler >[email protected]
