Andrey, probably it is, but I am not sure if I have ever had a thought for
mentioned scenario.
I think you should get existing implementation and use it like this. Make
sure to cache assignments as this may be quiet expensive operation.
Ignite ignite = Ignition.start(cfg);
ClusterGroup group = ignite.cluster().forPredicate(new Predicate());
final List<ClusterNode> snapshot = new ArrayList<>(group.nodes());
RendezvousAffinityFunction aff = new RendezvousAffinityFunction();
List<List<ClusterNode>> parts = aff.assignPartitions(new
AffinityFunctionContext() {
@Nullable @Override public List<ClusterNode>
previousAssignment(int part) {
return null;
}
@Override public int backups() {
return 0;
}
@Override public List<ClusterNode> currentTopologySnapshot() {
return snapshot;
}
@Override public AffinityTopologyVersion
currentTopologyVersion() {
return null;
}
@Nullable @Override public DiscoveryEvent discoveryEvent() {
return null;
}
});
// Picking node.
ClusterNode node = parts.get(aff.partition(key)).get(0);
--Yakov
2015-10-07 11:39 GMT+03:00 Andrey Kornev <andrewkor...@hotmail.com>:
> 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: dsetrak...@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 <andrewkor...@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: ag...@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 <
> andrewkor...@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: ag...@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 <
> > > andrewkor...@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: dsetrak...@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 <
> > > > > andrewkor...@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
> > >
> > >
>
>
