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]
