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 - 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"
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]
