Hi Yakov,
Not sure if it's a good idea, because if we remove that flag, it will
mean that left only one way to set previous logic - implement backup
filter. And I don't know how it will influence persistence. I think it's
a good candidate for 3.0 as it's not so urgent.
Thanks!
16.07.2018 21
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
Dmitry, it hink we can do this change right away. All we need is to add
proper error message on cache config validation in order to tell user that
default changed and manual configuration is needed for compatibility.
--Yakov
2018-07-16 15:47 GMT+03:00 Dmitry Karachentsev :
> Created a ticket and
Created a ticket and mapped to 3.0 version, as it changes basic default
behavior:
https://issues.apache.org/jira/browse/IGNITE-9011
Thanks!
13.07.2018 22:10, Valentin Kulichenko пишет:
Dmitry,
Good point. I think it makes sense to even remove (deprecate) the
excludeNeighbors property and alwa
Dmitry,
Good point. I think it makes sense to even remove (deprecate) the
excludeNeighbors property and always distribute primary and backups to
different physical hosts in this scenario. Because why would anyone ever
set this to false if we switch default to true? This also automatically
fixes th
