Eduard, I'm not sure I understand what you mean by "policy". Is it an interface that will have a few default implementations and user will be able to create his own one? If so, could you please write an example of such interface (how you see it) and how and when it's methods will be invoked.
On Wed, Apr 25, 2018 at 10:10 PM, 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- > baseline-topology-is-not-reassembled-td29299.html#none > -- Best regards, Ilya
