Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 121A4163AA9 for ; Tue, 25 Jul 2017 17:24:03 +0200 (CEST) Received: (qmail 74335 invoked by uid 500); 25 Jul 2017 15:24:03 -0000 Mailing-List: contact issues-help@geode.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@geode.apache.org Delivered-To: mailing list issues@geode.apache.org Received: (qmail 74059 invoked by uid 99); 25 Jul 2017 15:24:02 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Jul 2017 15:24:02 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 3ED321A0882 for ; Tue, 25 Jul 2017 15:24:02 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -100.002 X-Spam-Level: X-Spam-Status: No, score=-100.002 tagged_above=-999 required=6.31 tests=[RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id pjsCQ0A7nB2T for ; Tue, 25 Jul 2017 15:24:01 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id 4A2CC5FD7E for ; Tue, 25 Jul 2017 15:24:01 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id D3027E0D7D for ; Tue, 25 Jul 2017 15:24:00 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 3D0E723F15 for ; Tue, 25 Jul 2017 15:24:00 +0000 (UTC) Date: Tue, 25 Jul 2017 15:24:00 +0000 (UTC) From: "Fred Krone (JIRA)" To: issues@geode.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (GEODE-3293) Option to invalidate state data after a cluster crash MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/GEODE-3293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fred Krone updated GEODE-3293: ------------------------------ Description: 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. was: 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. > Option to invalidate state data after a cluster crash > ----------------------------------------------------- > > 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)