ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Gura <ag...@gridgain.com>
Subject Re: Cluster group affinity
Date Tue, 06 Oct 2015 15:12:48 GMT
Andrey,


> 1) I'm expected to return an instance of the internal class
> AffinityTopologyVersion.


If you are talking about AffinityContextFunction.currentTopologyVersion
method then for now this method is nowhere uses. But it make sense to
return non null value in order to avoid problems in the future.

2) the consequences of returning null from
> AffinityFunctionContext.previousAssignment and
> AffinityFunctionContext.discoveryEvent methods (because I can't provide any
> meaningful implementation for them) are not clear.
>

Both methods declared as @Nullable, so affinity function developer should
correctly handle this cases. In Ignite only FairAffinityFunction uses these
methods. FairAffinityFunction tries to obtain left node Id from event of
EventType.EVT_NODE_LEFT or EventType.EVT_NODE_FAILED type. It needs to
exclude this node assignment from previous assignments. So if your cluster
group lost node you can return EVT_NODE_LEFT discovery event with Id of
lost node from discoveryEvent method and assignments for previous cluster
group state from previousAssignment method.

RendezvousAffinityFunction uses only currentTopologySnapshot() and
backups() methods of AffinityFunctionContext interface.


On Tue, Oct 6, 2015 at 5:07 PM, Andrey Kornev <andrewkornev@hotmail.com>
wrote:

> Andrey, thanks!
>
> But a "properly formed AffinityFunctionContext" is the problem:
> 1) I'm expected to return an instance of the internal class
> AffinityTopologyVersion.
> 2) the consequences of returning null from
> AffinityFunctionContext.previousAssignment and
> AffinityFunctionContext.discoveryEvent methods (because I can't provide any
> meaningful implementation for them) are not clear.
>
> Please advise.
>
> Thanks
> Andrey
>
> > Date: Tue, 6 Oct 2015 16:43:10 +0300
> > Subject: Re: Cluster group affinity
> > From: agura@gridgain.com
> > To: dev@ignite.apache.org
> >
> > Andrey,
> >
> > See AffinityFunction.assignPartitions method. It returns assignment list
> as
> > List<List<ClusterNode>> where index of element in returned list
> corresponds
> > to partition number. Assignment for each partition represented as list of
> > nodes where primary node is always the first. So you can use existing
> > affinity functions for you case just passing properly formed
> > AffinityFunctionContext to assignPartitions method.
> >
> > On Tue, Oct 6, 2015 at 4:25 PM, Andrey Kornev <andrewkornev@hotmail.com>
> > wrote:
> >
> > > Dmitriy,
> > >
> > > The affinity function only maps a key to a partition id and it doesn't
> > > seem to provide a way to map the partition id to a cluster node. So
> I'm a
> > > little bit confused right now.
> > >
> > > Could you please clarify?
> > >
> > > Thanks a lot
> > > Andrey
> > >
> > > > From: dsetrakyan@apache.org
> > > > Date: Mon, 5 Oct 2015 09:53:25 -0700
> > > > Subject: Re: Cluster group affinity
> > > > To: dev@ignite.apache.org
> > > >
> > > > On Mon, Oct 5, 2015 at 2:28 AM, Andrey Kornev <
> andrewkornev@hotmail.com>
> > > > wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > I have a user-defined cluster group and I'd like to be able to
> > > > > consistently pick the same node in the group for a given key.
> > > Essentially,
> > > > > what I want is a cluster group affinity that is not associated
> with any
> > > > > cache. How can I do it?
> > > > >
> > > >
> > > > Andrey, perhaps you could just take our affinity function and use it
> > > > directly, no?
> > > >
> > > >
> > > > >
> > > > > Thanks
> > > > > Andrey
> > > > >
> > >
> > >
> >
> >
> >
> > --
> > Andrey Gura
> > GridGain Systems, Inc.
> > www.gridgain.com
>
>



-- 
Andrey Gura
GridGain Systems, Inc.
www.gridgain.com

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