Hi Mike, I think this probably would effect a backing DB the same way. There is some information in the AsyncEvent that can be used to not replay an event with see - AsyncEvent.getSequenceID(). But the problem with that is that it's really difficult for someone implementing an AsyncEventListener to keep track of all of all of the previously seen sequence ids.
I think the same thing will happen if the originator is a client. -Dan On Thu, Mar 16, 2017 at 10:12 AM, Michael Stolz <mst...@pivotal.io> wrote: > 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) > > >
