[
https://issues.apache.org/jira/browse/IGNITE-11873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Lang updated IGNITE-11873:
-------------------------------
Attachment: TestSQLBug.java
> 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
> Priority: Minor
> Attachments: TestSQLBug.java, 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)
