[
https://issues.apache.org/jira/browse/IGNITE-11873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Lang updated IGNITE-11873:
-------------------------------
Description:
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.
I've attached a file I used to test the issue. That test revealed that it only
occurs when both persistence and SQL on-heap cache are enabled. If one or the
other is disabled then there is no issue.
was:
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.
Attached a test file to reproduce the issue and updated the description.
The issue only seems to occur when both persistence and the SQL on-heap cache
are enabled.
> 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.
> I've attached a file I used to test the issue. That test revealed that it
> only occurs when both persistence and SQL on-heap cache are enabled. If one
> or the other is disabled then there is no issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
