Hi Dmitry, I agree with Val. It seems to me that this flag does not make sense and we can get rid of it.
The most important thing that you mentioned (at least for me) is the following: > 2. if there are not enough backup nodes (or no backupFilter) - try to distribute according to excludeNeighbors = true The current implementation of RendezvousAffinity function just silently ignore this case and does not attempt to assign partitions on other nodes. I mean the case when backupFilter is used. We definitely need to try to assign partitions on other nodes even if that nodes do not satisfy the backupFilter. And, of course, a proper message should be printed in a log file. Thanks, Slava. пт, 13 июл. 2018 г. в 18:05, Dmitry Karachentsev <dkarachent...@gridgain.com >: > Hi folks, > > Why RendezvousAffinityFunction.excludeNeighbors [1] is false by default? > It's not obvious that if user wants to run more than one node per > machine it has also set this flag to true explicitly. Maybe it would be > better to set it to true by default? > > At the same time if excludeNeighbors is true, it ignores backupFilter. > Why it's not vice-versa? For example: > > 1) if backupFilter is set - it will be used, > > 2) if there are not enough backup nodes (or no backupFilter) - try to > distribute according to excludeNeighbors = true, > > 3) if this is not possible too (or excludeNeighbors) = false - assign > partitions as possible. > > [1] > > https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/affinity/rendezvous/RendezvousAffinityFunction.html#setExcludeNeighbors-boolean- > > Are there any drawbacks in such approach? > > Thanks! > >
