You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@geode.apache.org by "Dave Barnes (Jira)" <ji...@apache.org> on 2020/08/12 16:42:00 UTC

[jira] [Updated] (GEODE-8323) Need to correctly process QueueRemovalMessage during HARegionQueue initialization

     [ https://issues.apache.org/jira/browse/GEODE-8323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dave Barnes updated GEODE-8323:
-------------------------------
    Fix Version/s: 1.13.0

> 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
>             Fix For: 1.13.0, 1.14.0
>
>
> 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)