I'm afraid, description of page-based eviction in documentation is not quite correct. Page-based eviction (RANDOM_LRU or RANDOM_2_LRU) can be activated only if persistent store is /disabled/. It defines algorithm for choosing page in RAM to remove all contents completely.

On the other hand, when persistent store is /enabled/, eviction from RAM to disk is enabled by default and is not customizable by user. So answer to first question 1 is no - you shouldn't specify anything in configuration to make disk eviction work.

About question 2 - You will lose partition after crash of N1. Losing of partition is always undesirable scenario. By default, partition will be reset, and you can't say for sure which version of partition (old from disk or new from another node) will be resolved as actual after join of N1.
Safe solution - configure backup nodes. Your data will be safe at N3.
Another safe solution - set safe partition loss policy (e.g. PartitionLossPolicy.READ_WRITE_SAFE). All reads/writes from lost partition will throw an exception until crashed node N1 returns to the topology. After that, "1" entry will be recovered.

Thanks for raising this topic, we'll fix the documentation soon.

Best Regards,
Ivan Rakov

On 10.08.2017 5:38, userx wrote:
Hi team,

I was going through the documentation of durable memory at

As per the documentation, durable memory comes into picture when
PersistentStore configuration is enabled. Now durable memory uses both
RAM(hot data) and disk (superset). When the RAM part reaches a threshold
(80% by default as per the documentation), the durable data retains only hot
data in RAM and rest on the disk.

So does that mean that there is a default eviction policy which comes into
existence ? Or does the user explicitly has to mention the same in
configuration ? What happens if he does not mention the eviction policy in
configuration ?

Suppose there are 2 nodes N1 (different physical box) and N2 (different
physical box) and the data is distributed in PARTITIONED mode and persistent
store is enabled.

Here is the example of entries

N1-> "1","X"
N2-> "2","Y"

Suppose N1 crashes and goes down and does not come up at all for say 5
hours. Is "1" retrievable at all during that time if N1 went down after an
entry to its WAL file or we loose N1 ? If say the entry was not able to be
made in WAL file and should we have configured a back up as N3 (different
physical box), would it have saved "1" ?

View this message in context: 
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Reply via email to