+1 In fact, after implementing this, we will no longer need rendezvous affinity.
Why do we need other affinity if we already provided ideal assignment to user ? I suggest hiding affinity function from public API and make available publicly only things like partition count and backup filter, because implementing correct affinity function is error prone and rarely needed. It's even be possible to store/calculate single partition map for all caches if they share same partition count. 2017-11-09 21:44 GMT+03:00 Vladimir Ozerov <[email protected]>: > Huge +1. > > Related question - is it possible to use affinity comparison to "merge" > partition maps of caches with similar affinity functions? If we do that, we > will be able to get rid of these nasty "cache groups". > > On Thu, Nov 9, 2017 at 7:42 PM, Dmitriy Setrakyan <[email protected]> > wrote: > > > I think it definitely makes sense to add the Fair affinity function back > to > > Ignite. > > > > On Thu, Nov 9, 2017 at 11:46 PM, Alexey Goncharuk < > > [email protected]> wrote: > > > > > Igniters, > > > > > > After spending some time on baseline topology review, it came to my > mind > > > that we can return stateful affinity functions for persistent caches. > > Since > > > now we will have a topology which is persisted to the cluster > metastore, > > > why not save the partition affinity distribution together with it? > > > > > > If we have this distribution saved, we can use it after cluster > restart, > > so > > > the scenario which was broken with fair affinity is no longer valid. We > > > will always have an old partition distribution and we will be able to > > > consistently restore it after the cluster restart. > > > > > > As for the old colocation issue, we only need to define a way to > > 'compare' > > > affinity functions for equality, then we can simply choose another > > cache's > > > distribution. > > > > > > Do you think this makes sense and worth adding it to Ignite? If so, I > > will > > > extends the baseline topology IEP with another phase. > > > > > > -- AG > > > > > > -- Best regards, Alexei Scherbakov
