Alexey, What if user touch backup entry via readFromBackup=true? Should we start distributed operation ( e.g. TTL update or expiration) in that case?
On Tue, Apr 24, 2018 at 5:02 PM, Alexey Goncharuk < alexey.goncha...@gmail.com> wrote: > 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? > >> > >> > > > -- Best regards, Andrey V. Mashenkov
