ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joel Lang (JIRA)" <j...@apache.org>
Subject [jira] [Created] (IGNITE-11873) Enabling SQL On-heap Row Cache results in row cache being inconsistent with off-heap storage
Date Fri, 24 May 2019 19:44:00 GMT
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)

Mime
View raw message