[
https://issues.apache.org/jira/browse/IGNITE-2655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15310311#comment-15310311
]
Denis Magda commented on IGNITE-2655:
-------------------------------------
[~v.pyatkov], I've reviewed your latest changes. Please see my comments in the
pull-request. In short the code can fail or work improperly.
[~yzhdanov], I would use this predicate for backups only, leaving method's
signature as is, considering that the primary is chosen by affinity function
before. As you said if someone needs to control the location of primary he can
write his own affinity function and most likely he will because "partition
number" passed to the filter says nothing in regards to where this partition is
physically located.
>> As I side note I would say that we are trying to force our users to do some
>> programming. Does anyone have any idea on how to do this without code? How
>> about supporting simple string expressions based on node attributes and/or
>> ip addresses?
Presently I would fully rely on the programmable way because it's flexible and
covers all the cases. If there is a demand for the thing you're talking about
we can add an overloaded method that will except a kind of predicate.
[~dsetrakyan], presently the API is left the same for all the supported
affinity function:
{{public void setAffinityBackupFilter(@Nullable IgniteBiPredicate<ClusterNode,
List<ClusterNode>> affinityBackupFilter)}}
where
the first parameter (ClusterNode) is a node being tested and the second list
contains nodes that are already assigned for a partition (primary is always the
first).
> AffinityFunction: primary and backup copies in different locations
> ------------------------------------------------------------------
>
> Key: IGNITE-2655
> URL: https://issues.apache.org/jira/browse/IGNITE-2655
> Project: Ignite
> Issue Type: Bug
> Reporter: Denis Magda
> Assignee: Vladislav Pyatkov
> Priority: Critical
> Labels: important
> Fix For: 1.7
>
>
> There is a use case when primary and backup copies have to be located in
> different racks, building, cities, etc.
> A simple scenario is the following. When nodes are started they will have
> either "rack1" or "rack2" value in their attributes list and we will enforce
> that the backups won't be selected among the nodes with the same attribute.
> It should be possible to filter out backups using IP addresses as well.
> Presently rendezvous and fair affinity function has {{backupFilter}} that
> will work perfectly for the scenario above but only for cases when number of
> backups for a cache is equal to 1.
> In case when the number of backups is bigger than one {{backupFilter}} will
> only guarantee that the primary is located in different location but will NOT
> guarantee that all the backups are spread out across different locations as
> well.
> So we need to provide an API that will allow to spread the primary and ALL
> backups copies across different locations.
> The proposal is to introduce {{AffinityBackupFilter}} with the following
> method
> {{AffinityBackupFilter.isAssignable(Node n, List<Node> assigned)}}
> Where n - potential backup to check, assigned - list of current partition
> holders, 1st is primary
> {{AffinityBackupFilter}} will be set using
> {{affinity.setAffinityBackupFilter}}.
> {{Affinity.setBackupFilter}} has to be deprecated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
