geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GEODE-966) HashIndex with Overflow region detection/conversion needs to occur sooner
Date Thu, 03 Mar 2016 23:22:18 GMT

    [ https://issues.apache.org/jira/browse/GEODE-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15178816#comment-15178816
] 

ASF subversion and git services commented on GEODE-966:
-------------------------------------------------------

Commit 4914142105e2ec478679efdc1737ab9972b30d1e in incubator-geode's branch refs/heads/develop
from [~huynhja]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=4914142 ]

GEODE-966 HashIndex with Overflow region detection/conversion needs to occur sooner

Conversion of HashIndex to CompactRangeIndex due to overflow is determined before the create
task is created.  This prevents the index map from getting into a weird state.


> HashIndex with Overflow region detection/conversion needs to occur sooner
> -------------------------------------------------------------------------
>
>                 Key: GEODE-966
>                 URL: https://issues.apache.org/jira/browse/GEODE-966
>             Project: Geode
>          Issue Type: Bug
>          Components: querying
>            Reporter: Jason Huynh
>            Assignee: Jason Huynh
>
> We maintain a map of indexes in the index manager, where the indexTask is the key and
the FutureTask or Index is the value.
> At the same time we convert hash indexes to compact range indexes when used for overflow
regions.
> At the first pass, say a process creates hash index task (TASK1) and stuffs the future
task into the map.
> At some future time, (before the hash index future task completes) another index task
(TASK2) comes in with the same expression
> When the hash index task completes, it does an indexes.put(index task, index).
> This put uses the equals method of the index task which has multiple stages. It first
matches by name, then has a short circuit to detect if this is an index lookup and then it
matches by index expression. Because we have changed the actual index type of the hash index
to that of a functional index for overflow regions, this put will actually match TASK2 depending
on the order in which we traverse the map keys (possibly related to why we didn't see this
problem pre 1.8?)
> We end up with a map where the TASK1 still maps to a future task and get this weird behavior.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message