Kirill Tkalenko created IGNITE-23417:
----------------------------------------
Summary: Fix race between compaction and KeyValueStorage#range
Key: IGNITE-23417
URL: https://issues.apache.org/jira/browse/IGNITE-23417
Project: Ignite
Issue Type: Bug
Reporter: Kirill Tkalenko
Assignee: Kirill Tkalenko
I found that in IGNITE-23288 a problem with
*org.apache.ignite.internal.metastorage.server.KeyValueStorage#range* was not
solved.
To understand it, let's look at an example:
* Let's say there is a key "bar" and it has revisions 1, 3, 5 (tombstone).
* We set the compaction revision to 5, via
*KeyValueStorage#setCompactionRevision*.
* We waited for complete all cursors on revision less than or equal to 5.
* We invoke *KeyValueStorage#compact* on revision 5 and let's say it will be
quite long.
* We will not be able to create a cursor on revision 5, but on 6 it is quite
possible.
* We create a cursor for revision 6.
* Cursor reaches the key "bar" and what can happen:
# Compaction deleted the key "bar" from storage before opening the cursor -
then everything is {color:#00875A}fine{color}.
# Compaction did not have time to delete the "bar" key - the cursor will return
an entry with revision 5, which {color:#DE350B}should not present{color}.
# Compaction started deleting the "bar" key in parallel - the cursor will
either {color:#DE350B}get a value for revision 5 or throw an error{color}.
In this ticket we need to fix cases 2 and 3.
Also, we must not forget the case that if the cursor was created on a revision
less than or equal to the new revision of the compaction, from the example this
is on revision 5 but strictly before calling
*KeyValueStorage#setCompactionRevision(5)*. Then we must return the entry on
revision 5 after *KeyValueStorage#setCompactionRevision(5)*.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
