The ability to execute cache modifications during recovery.

[Vladimir Ershov]

Hi Folks!

Assume case, when some cache partitions with data are lost from the grid,
and thus  EVT_CACHE_REBALANCE_PART_DATA_LOST event happen.

Do we need the ability to execute cache modifications somehow, maybe like
recover(Map<,> missingKeysAndValues) as part of GridDhtPartitionTopology
API?

More details in the related ticket:
https://issues.apache.org/jira/browse/IGNITE-1605

I'm new on this, so any good thoughts would be appreciated!

Wbr,
Vladimir.

[Vladimir Ershov]

As for now I'm going to implement this:

   1. CacheDataLossPolicy with two options: NOOP & FAIL_OPS
   2. CacheDataLossPolicy will be added to CacheConf
   3. EVT_CACHE_REBALANCE_PART_DATA_LOST will be a cluster event
   4. Other caches would not take any action on it.
   5. Cache with FAIL_OPS will be not available for any data get-put access
   after DATA_LOST. until user poll a big steel toggle, which resets the cache
   state.


After this iteration, I, probably, will start to implement something like
recover(Map<,> missingKeysAndValues) as part of GridDhtPartitionTopology
API. Current question is closed, but any further thought are still welcome)



On Thu, Nov 26, 2015 at 1:33 PM, Vladimir Ershov <[hidden email]>
wrote:

> Hi Folks!
>
> Assume case, when some cache partitions with data are lost from the grid,
> and thus  EVT_CACHE_REBALANCE_PART_DATA_LOST event happen.
>
> Do we need the ability to execute cache modifications somehow, maybe like
> recover(Map<,> missingKeysAndValues) as part of GridDhtPartitionTopology
> API?
>
> More details in the related ticket:
> https://issues.apache.org/jira/browse/IGNITE-1605
>
> I'm new on this, so any good thoughts would be appreciated!
>
> Wbr,
> Vladimir.
>
>
>
>