[
https://issues.apache.org/jira/browse/IGNITE-11704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16951983#comment-16951983
]
Pavel Kovalenko commented on IGNITE-11704:
------------------------------------------
[~ascherbakov]
I've fixed several of your concerns others are commented:
1. Tombstone object storing has optimized:
Any object (key or value) has a header (object len + object type). The object
type can be regular, binary or byte array. In the previous version, the
tombstone will be regular cache object with marshalled "null" value. In current
version, I introduced a special type of object - Tombstone that doesn't store
any value, only header. All checking for the tombstone has optimized.
2. I think it's fine. Every clear tombstone task periodically check is
partition become in not OWNING state. In this case, a clear tombstones
operation is stopped. Yes, there can be a window of time where both clear
tombstones and eviction can happen, but it shouldn't be long.
3. DropCacheContextDuringEvictionTest is reworked due to reuse test
PartitionsEvictManagerAbstractTest for checking tomstones failure.
cacheGroupMetricsRegistryName is added as a utility method as part of cache
group tombstone metrics.
GridCommandHandlerIndexingTest - merge artifact, should be ignored.
4. I've added a comment when this condition is true.
5. This test already exists
(org.apache.ignite.internal.processors.cache.distributed.CacheRemoveWithTombstonesTest#testRemoveAndRebalanceRaceTx)
6. I've reworked code and now clearAll and clearTombstones have a common
codebase.
Could you please review it again?
> Write tombstones during rebalance to get rid of deferred delete buffer
> ----------------------------------------------------------------------
>
> Key: IGNITE-11704
> URL: https://issues.apache.org/jira/browse/IGNITE-11704
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexey Goncharuk
> Assignee: Pavel Kovalenko
> Priority: Major
> Labels: rebalance
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently Ignite relies on deferred delete buffer in order to handle
> write-remove conflicts during rebalance. Given the limit size of the buffer,
> this approach is fundamentally flawed, especially in case when persistence is
> enabled.
> I suggest to extend the logic of data storage to be able to store key
> tombstones - to keep version for deleted entries. The tombstones will be
> stored when rebalance is in progress and should be cleaned up when rebalance
> is completed.
> Later this approach may be used to implement fast partition rebalance based
> on merkle trees (in this case, tombstones should be written on an incomplete
> baseline).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)