[
https://issues.apache.org/jira/browse/GEODE-8323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17153007#comment-17153007
]
ASF subversion and git services commented on GEODE-8323:
--------------------------------------------------------
Commit 625a204f1a7173323648c05bb0002aded06e2a69 in geode's branch
refs/heads/feature/GEODE-8067 from Eric Shu
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=625a204 ]
GEODE-8323: Process QueueRemovalMessage after queue initialized. (#5333)
> Need to correctly process QueueRemovalMessage during HARegionQueue
> initialization
> ---------------------------------------------------------------------------------
>
> Key: GEODE-8323
> URL: https://issues.apache.org/jira/browse/GEODE-8323
> Project: Geode
> Issue Type: Bug
> Components: client queues
> Reporter: Eric Shu
> Assignee: Eric Shu
> Priority: Major
> Labels: caching-applications
>
> Currently, these events in queue removal message are ignored as the idea is
> that correct setting of messageTimeToLive and
> subscriptionMessageTrackingTimeout should prevent a previous seen event
> replayed on a client.
> However, it failover scenario occurs, a restarted/newly joined member could
> gii from a secondary HARegionQueue which has those events not removed by the
> QRM. As the restarted member starts the timer for messageTimeToLive after it
> restarted. The event could live longer than the messageTimeToLive setting if
> starts from the original operation time. If this time is longer than the
> subscriptionMessageTrackingTimeout setting on the client, the client will not
> prevent the replay of the stray event. This could leads to data inconsistency
> between client and server.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
