ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Goncharuk <alexey.goncha...@gmail.com>
Subject Re: Reconsider TTL expire mechanics in Ignite
Date Tue, 24 Apr 2018 14:02:27 GMT

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.glukos@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?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message