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