Ivan Bessonov created IGNITE-19394:
--------------------------------------
Summary: RW index scan may skip entries because of GC
Key: IGNITE-19394
URL: https://issues.apache.org/jira/browse/IGNITE-19394
Project: Ignite
Issue Type: Bug
Reporter: Ivan Bessonov
The problem is in a peek cursor contract.
Right now, SortedIndexLocker#acquireLockNextKey assumes that if "peek" returned
a value with successfully acquired lock, "next" will iterate over the same
value.
This is not true, if the result of "peek" call was removed by GC. In such case,
"next" will actually skip the real next value, that should have been returned
to the user.
We must introduce a new invariant - "hasNext" and "next" always take into
account latest result of "peek", it it's been called *after* previous
"hasNext"/"next". This will fix the bug.
Tricky concurrent test required.
h4. Tangent issues
Two consecutive calls of "peek", before and after the lock, make us scan index
twice. Not sure if there's an easy way to reduce the amount of reads though.
Also, RW and RO cursors should probably be implemented differently, forcing all
these features into a single implementation is nonsense. RO cursor should never
peek anything, it may even throw an exception. This will allow it to have
internal cache, for example, making it much more efficient.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
