geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (GEODE-1985) IndexManager.needsRecalculation can miss cases where recalulation is needed
Date Mon, 07 Nov 2016 20:34:58 GMT


ASF subversion and git services commented on GEODE-1985:

Commit 2e1a8c420fd984bdcc605ababe93b0e6c6b29919 in incubator-geode's branch refs/heads/feature/GEODE-288
from [~upthewaterspout]
[;h=2e1a8c4 ]

GEODE-1985: Updating the SAFE_QUERY_TIME after updating indexes

This is a fix for pretty specific race condition
1) T1 does a put and gets to the point of calling setIndexBufferTime,
but hasn't updated the indexes
2) T2 starts a query and finds the entry in the index even though the
value no longer matches the query
3) T1 finishes the put
4) T2 checks to see if should revaluate the entry, but decides not to
because based on the SAFE_QUERY_TIME value the entry changed before the
query started.

By moving the update to SAFE_QUERY_TIME down, the if the an entry
doesn't need reevaluation based on the SAFE_QUERY_TIME, we know the
index was updated before the query started.

There is currently an updateInProgress flag to handle the issue of the
query executing before the SAFE_QUERY_TIME is updated. If the entry is
updated, but not the index, the updateInProgress flag will be set.

> IndexManager.needsRecalculation can miss cases where recalulation is needed
> ---------------------------------------------------------------------------
>                 Key: GEODE-1985
>                 URL:
>             Project: Geode
>          Issue Type: Bug
>          Components: querying
>            Reporter: Dan Smith
>            Assignee: Dan Smith
>             Fix For: 1.1.0-incubating
> When returning query results from an index, we check IndexManager.needsRecalculation
to see if an entry might have changed while the query was in progress. 
> Unfortunately, this method can return false negatives If an entry has not yet updated
the SAFE_QUERY_TIME field.
> The SAFE_QUERY_TIME is updated in LocalRegion.updateStatsForPut. That method is called
*after* the region entry was modified. So the SAFE_QUERY_TIME could be 0, even though an entry
was modified, which will make this expression false.

This message was sent by Atlassian JIRA

View raw message