Re: Review Request 44050: GEODE-966 HashIndex with Overflow region detection/conversion needs to occur sooner

[anilkumar gingade <ag...@pivotal.io>]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/44050/#review121361
-----------------------------------------------------------


Ship it!




Ship It!

- anilkumar gingade


On Feb. 26, 2016, 12:19 a.m., Jason Huynh wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/44050/
> -----------------------------------------------------------
> 
> (Updated Feb. 26, 2016, 12:19 a.m.)
> 
> 
> Review request for geode, anilkumar gingade, Barry Oglesby, Dan Smith, and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> -------
> 
> We currently do not allow overflow regions to create hash indexes, however the detection of this scenario is happening too late.  In which case, the index manager index map can end up in a very odd state.
> 
> Description from ticket:
> 
> 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.
> 
> 
> Diffs
> -----
> 
>   geode-core/src/main/java/com/gemstone/gemfire/cache/query/internal/index/IndexManager.java 7a0b1a9 
> 
> Diff: https://reviews.apache.org/r/44050/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>