ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Kornev <andrewkor...@hotmail.com>
Subject RE: Cluster group affinity
Date Wed, 07 Oct 2015 08:39:24 GMT
Dmitriy,

This approach would definitely work, if it wasn't for the fact that the cluster groups in
my case are created dynamically and may include any combination of nodes in the cluster (where
the number of combinations grows exponentially with the number of nodes in the cluster). I
don't think it's practical to create that many caches.

I still can't get why the affinity function can't be applied to an arbitrary cluster group,
and why it must necessarily be a cache. Isn't the cache affinity just a special case of the
cluster group affinity defined as ClusterGroup.forCache()?

Thanks
Andrey

> From: dsetrakyan@apache.org
> Date: Tue, 6 Oct 2015 12:07:39 -0700
> Subject: Re: Cluster group affinity
> To: dev@ignite.apache.org
> 
> On Tue, Oct 6, 2015 at 8:46 AM, Andrey Kornev <andrewkornev@hotmail.com>
> wrote:
> 
> > Thanks, Andrey! This definitely helps.
> >
> > It's just that implementing such a simple feature in the "user space"
> > feels awkward and requires intimate knowledge of  fairly low-level details
> > of how things work in the current version.
> >
> > Just curios, how about providing an override for Ignite.affinity() method
> > that ClusterGroup? Is there something fundamentally wrong about calculating
> > the affinity for an arbitrary collection of nodes (such as a ClusterGroup
> > is)?
> >
> 
> Affinity is usually associated with data. In your case you have no data,
> but you still need keys to be always mapped to the same node.  How about
> creating an empty cache and using standard cache API for determining the
> affinity for a key?
> 
> 
> > Regards
> > Andrey
> >
> > > Date: Tue, 6 Oct 2015 18:12:48 +0300
> > > Subject: Re: Cluster group affinity
> > > From: agura@gridgain.com
> > > To: dev@ignite.apache.org
> > >
> > > 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