This is a very interesting situation. This would affect a backing DB in exactly the same way. Probably also a WAN Gateway replication. Should be checking for retry before adding to queue.
Does the same thing happen if the originator is a client instead of an accessor? -- Mike Stolz Principal Engineer, GemFire Product Manager Mobile: +1-631-835-4771 On Thu, Mar 16, 2017 at 12:27 PM, Dan Smith (JIRA) <j...@apache.org> wrote: > Dan Smith created GEODE-2674: > -------------------------------- > > Summary: Lucene index is out of sync with data region due to > retried event > Key: GEODE-2674 > URL: https://issues.apache.org/jira/browse/GEODE-2674 > Project: Geode > Issue Type: Bug > Reporter: Dan Smith > > > We're seeing issues where the data in the lucene index does not match the > data in a region. Here's what I see happening > > # An accessor starts doing a put > # The put goes to the current primary > # Primary distributes the put to the secondary > # Primary closes it's cache > # New primary does a destroy on the same entry > # The accessor retries the put because the old primary closed the cache > # The retried put is added to the queue, after the destroy. But it is not > added to the region, because the region detects that it is a retry. > # The lucene index applies the put. Now there is an extra entry in the > index that is not in the region. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.15#6346) >
