Mailing-List: contact issues-help@geode.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geode.apache.org
Date: Tue, 25 Jul 2017 16:01:00 +0000 (UTC)
From: "Fred Krone (JIRA)" <jira@apache.org>
To: issues@geode.apache.org
Message-ID: <JIRA.13089912.1500996149000.8704.1500998460876@Atlassian.JIRA>
In-Reply-To: <JIRA.13089912.1500996149000@Atlassian.JIRA>
References: <JIRA.13089912.1500996149000@Atlassian.JIRA> <JIRA.13089912.1500996149082@jira-lw-us.apache.org>
Subject: [jira] [Updated] (GEODE-3293) Rapid Recovery Improvements
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Fred Krone updated GEODE-3293:
------------------------------
    Summary: Rapid Recovery Improvements  (was: Option to invalidate state data after a cluster crash)

> Rapid Recovery Improvements
> ---------------------------
>
>                 Key: GEODE-3293
>                 URL: https://issues.apache.org/jira/browse/GEODE-3293
>             Project: Geode
>          Issue Type: Wish
>          Components: persistence
>            Reporter: Fred Krone
>              Labels: rapid_recovery
>
> This story is an epic to wrap mitigating to stale cache data.
> When GemFire is used is a fast moving data scenario every second it is down its data becomes more stale vs a system of record like a backing DB.  When the cluster is recovered its data will essentially be an aging snapshot.  In scenarios where data accuracy is essential (always?) it would be nice to have an option to invalidate stale data before allowing reads.


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)