> On June 3, 2016, 10:10 p.m., Dan Smith wrote: > > I think there should be a test with these changes.
Dan, I am adding that...Wanted to get early feedback on this and get tests started... I will add the test changes to this review post. - anilkumar ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/48188/#review136116 ----------------------------------------------------------- On June 3, 2016, 12:49 a.m., anilkumar gingade wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/48188/ > ----------------------------------------------------------- > > (Updated June 3, 2016, 12:49 a.m.) > > > Review request for geode, anilkumar gingade, Barry Oglesby, Bruce Schuchardt, > Jason Huynh, William Markito, nabarun nag, Dan Smith, and xiaojian zhou. > > > Repository: geode > > > Description > ------- > > The CQEvents as seen by CQs are cached in order to avoid applying CQ queries > on old values. > > In case of a destory CQEvent, the CQEvents are marked with destroy tokens and > removed from > the cache after the CQEvent is added to HAQueue. > This works fine for the CQs registered locally, but for the CQs registered on > peer server, the > CQs weren't removed from the cache, which resulted in generating wrong > CQEvent for subsequent > operation. > This change removes the destroy CQevent from the cache after the CQEvent is > distributed to > peer server. > > > Diffs > ----- > > > geode-core/src/main/java/com/gemstone/gemfire/internal/cache/DistributedCacheOperation.java > 6a7b4f2 > > Diff: https://reviews.apache.org/r/48188/diff/ > > > Testing > ------- > > Reproduce the issue with manual testing. The test passed after the changes > are made to remove cached destroy events from remote CQs. > > > Thanks, > > anilkumar gingade > >