Ed, how difficult is this fix? Are you suggesting it for 2.5? On Thu, Apr 26, 2018 at 3:10 AM, Eduard Shangareev < eduard.shangar...@gmail.com> wrote:
> Igniters, > I have described the issue with current approach in "New definition for > affinity node (issues with baseline)" topic[1]. > > Now we have 2 different affinity topology (one for in-memory, another for > persistent caches). > > It causes problems: > - we lose (in general) co-location between different caches; > - we can't avoid PME when non-BLAT node joins cluster; > - implementation should consider 2 different approaches to affinity > calculation. > > So, I suggest unifying behavior of in-memory and persistent caches. > They should all use BLAT. > > Their behaviors were different because we couldn't guarantee the safety of > in-memory data. > It should be fixed by a new mechanism of BLAT changing policy which was > already discussed there - "Triggering rebalancing on timeout or manually if > the baseline topology is not reassembled" [2]. > > And we should have a policy by default which similar to current one > (add nodes, remove nodes automatically but after some reasonable delay > [seconds]). > > After this change, we could stop using the term 'BLAT', Basline and so on. > Because there would not be an alternative. So, it would be only one > possible Affinity Topology. > > > [1] > http://apache-ignite-developers.2346864.n4.nabble.com/New- > definition-for-affinity-node-issues-with-baseline-td29868.html > [2] > http://apache-ignite-developers.2346864.n4.nabble.com/ > Triggering-rebalancing-on-timeout-or-manually-if-the-baselin > e-topology-is-not-reassembled-td29299.html#none >
