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?
