I still believe the difference is very subtle for a naked eye. Seems like both, topology validator and data loss check are almost identical:
- both get invoked whenever topology changes - both can prohibit some operation on cache, e.g. updates in case of topology validator or updates/reads/both in case of data loss check I think the design screams for these two abstractions to be combined into one. Otherwise, we are only going to muddle the API. D. On Fri, Jan 15, 2016 at 12:17 AM, Alexey Goncharuk < [email protected]> wrote: > Still not sure how they are similar: > > TopologyValidator is invoked on every topology change and provides a > boolean result whether topology is ready to be used. Currently there is no > way to mark a 'failed' topology as valid without another topology change. > > This new method that Vladimir suggests resets the partition state after it > has been lost, it does not invoke topology validator and does not need a > topology change to work. > > 2016-01-15 10:59 GMT+03:00 Dmitriy Setrakyan <[email protected]>: > > > Alexey, > > > > All I am saying is that the difference between topology validator and > this > > new method becomes very subtle. One just looks like a subset of another. > Am > > I wrong? > > > > D. > > > > On Thu, Jan 14, 2016 at 2:38 AM, Alexey Goncharuk < > > [email protected]> wrote: > > > > > Dmitriy, > > > > > > Are you suggesting that we need to pass partitions state to a topology > > > validator so that user needs to check it manually. I do not think this > is > > > convenient for an end-user and like the approach with the policy that > > > Vladimir suggested better. > > > > > > Raul, > > > > > > I assume you want to add IgniteCacheEx interface? How one would get it? > > > Another thing that crossed my mind was that it may be more efficient to > > > reset the state of multiple caches simultaneously, so maybe we should > add > > > this method to Ignite and pass a list of cache names? > > > > > >
