Exactly, thats what I wrote :) Carsten
2013/10/11 Felix Meschberger <[email protected]> > Hi > > Am 11.10.2013 um 05:45 schrieb Carsten Ziegeler: > > > 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. > > Whatever -- deprecate or not -- I wold like to have the doc be clear: > Either stable or not. The longer I use APIs the more I realize that notions > such as "not guaranteed to ..." essentially mean, that it is not usable and > dependable. > > Regards > Felix > > > > > 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] > > -- Carsten Ziegeler [email protected]
