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:58:00 GMT

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

Mime
View raw message