Joel Lang created IGNITE-11873:
----------------------------------
Summary: Enabling SQL On-heap Row Cache results in row cache being
inconsistent with off-heap storage
Key: IGNITE-11873
URL: https://issues.apache.org/jira/browse/IGNITE-11873
Project: Ignite
Issue Type: Bug
Components: cache, persistence, sql
Affects Versions: 2.7
Reporter: Joel Lang
Attachments: entry1.png, entry2.png
When enabling the SQL On-heap Row Cache feature on a persistent, atomic,
replicated cache, I found that after a number of queries and updates, averaging
from 40 to 60 updates, the on-heap cache will become inconsistent with the
off-heap storage. This manifests on a single, non-clustered Ignite node that I
test with.
Specifically I would query a cache using SQL for a specific entry, but when
updating the entry using a normal put() on the cache, the entry would not be
changed from the perspective of the next SQL query. This causes the business
code to not behave as expected.
When examining the state of the cache from DBeaver using a select query, I've
found that the problem row in question is duplicated in the query results, and
out of order despite ordering the results by key:
!entry1.png!
Restarting Ignite to clear the on-heap cache reveals the actual row:
!entry2.png!
When looking at the state of H2RowCache from a heap dump, I found that there
where two different instances of GridH2KeyValueRowOnheap containing two
different instances of the cache value in different states: the one I'm seeing
and the one I'm trying to update it to.
As a side effect of all of this, the ModifyingEntryProcessor always fails on
that row because "entryVal" is never equal to "val" when checked in the
process() method.
If more information is needed to reproduce I can try to make a simple example
next week after the holiday.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
