[
https://issues.apache.org/jira/browse/IGNITE-19394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-19394:
-----------------------------------
Epic Link: IGNITE-17304
> 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
> Priority: Major
> Labels: ignite-3
>
> 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)
