[jira] [Assigned] (GEODE-966) HashIndex with Overflow region detection/conversion needs to occur sooner

["Jason Huynh (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GEODE-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jason Huynh reassigned GEODE-966:
---------------------------------

    Assignee: Jason Huynh

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