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]
smime.p7s
Description: S/MIME cryptographic signature
