ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joel Lang (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (IGNITE-11873) Enabling SQL On-heap Row Cache results in row cache being inconsistent with off-heap storage
Date Tue, 28 May 2019 14:54:00 GMT

     [ 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)

Mime
View raw message