ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Valentin Kulichenko <valentin.kuliche...@gmail.com>
Subject Re: Resurrect FairAffinityFunction
Date Tue, 25 Jul 2017 18:54:28 GMT
Semyon,

We had some improvements, but to knowledge fair affinity still provides
much better distribution (at least I haven't seen any results showing
otherwise). Please correct me if I'm wrong.

Actually, I think it's not an issue with fair function in particular, but
rather a design flow in affinity manager. The exact same issue will exist
not only with fair function, but with ANY function that
uses AffinityFunctionContext#previousAssignment to calculate assignments.
And the context is provided from the outside, function has nothing to do
with it.

So let's fix the root cause and bring innocent FairAF back :)

-Val

On Tue, Jul 25, 2017 at 1:07 AM, Semyon Boikov <sboikov@gridgain.com> wrote:

> Valentin,
>
> As far as I know in 2.0 some changes were made in rendezvous function so
> now it can provide better result. Do you have some numbers for 2.0 so that
> we can compare rendezvous and fair affinity functions?
>
> Thanks
>
> On Tue, Jul 25, 2017 at 5:13 AM, <dsetrakyan@apache.org> wrote:
>
> > Agree with Val, we should bring it back.
> >
> > ⁣D.​
> >
> > On Jul 24, 2017, 8:14 PM, at 8:14 PM, Valentin Kulichenko <
> > valentin.kulichenko@gmail.com> wrote:
> > >Guys,
> > >
> > >Some time ago we removed FairAffinityFunction from the project.
> > >However, my
> > >communication with users clearly shows that is was a rush decision.
> > >Distribution showed by Fair AF is much better than default and for some
> > >users it's extremely important. Basically, there are cases when
> > >rendezvous
> > >function is no-go.
> > >
> > >The reason for removal was that it was possible to get inconsistent
> > >results
> > >in case multiple caches were created on different topologies. However,
> > >I
> > >think this is fixable. As far as I understand, the only thing we need
> > >to do
> > >is to maintain a single AffinityFunctionContext for all the caches with
> > >same affinity function. Currently for each cache we have separate
> > >context
> > >which holds the state used by Fair AF. If the state is different, we
> > >have
> > >an issue.
> > >
> > >The only question is how to check whether two functions are the same or
> > >not. In case both cache node filter and backup filter are not
> > >configured,
> > >this is easy - if number of partitions and excludeNeighbors flag are
> > >equal
> > >for two functions, these functions are also equal.
> > >
> > >With filters it's a bit more complicated as these are custom
> > >implementations and in general case we don't know how to compare them.
> > >Although, to solve this problem, we can enforce user to implement
> > >equals()
> > >method for these implementation if Fair AF is used.
> > >
> > >I propose to make changes described above and bring Fair AF back.
> > >
> > >Thoughts?
> > >
> > >-Val
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message