Ivan, Agree about the use-case when we have a read-write-through store. However, we allow to use Ignite in-memory caches even without 3rd party stores, in this case the same issue is still present. Maybe we can keep local expire for read-through caches and have strongly consistent expire for other modes?
2018-04-24 16:51 GMT+03:00 Ivan Rakov <ivan.glu...@gmail.com>: > Alexey, > > Distributed expire will result in serious performance overhead, mostly on > network level. > I think, the main use case of TTL are in-memory caches that accelerate > access to slower third-party data source. In such case nothing is broken if > data is missing; strong consistency guarantees are not needed. I think, > that's why we should keep "local expiration" at least for in-memory caches. > Our in-memory page eviction works in the same way. > > Best Regards, > Ivan Rakov > > On 24.04.2018 16:05, Alexey Goncharuk wrote: > >> Igniters, >> >> We recently experienced some issues with TTL with enabled persistence, the >> issues were related to persistence implementation details. However, when >> we >> were adding tests to cover more cases, we found more failures, which, I >> think, reveal some fundamental issues with expire mechanism. >> >> In short, the root cause of the issue is that we expire entries on primary >> and backup nodes independently, which means: >> 1) Partition sizes may have different values at different times which will >> trigger false-negative checks on partition map exchange which was recently >> added >> 2) More importantly, this may lead to inconsistent primary and backup node >> values when EntryProcessor is used, because an entry processor may observe >> a non-null value on one node and a null value on another node. >> >> In my opinion, the second issue is critical and we must change the expiry >> mechanics to run expiry in a distributed mode, with cache mode semantics >> for entry remove. >> >> Thoughts? >> >> >
