From issues-return-39679-archive-asf-public=cust-asf.ponee.io@geode.apache.org Fri Aug 3 00:18:04 2018 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 mx-eu-01.ponee.io (Postfix) with SMTP id 74432180674 for ; Fri, 3 Aug 2018 00:18:04 +0200 (CEST) Received: (qmail 52006 invoked by uid 500); 2 Aug 2018 22:18: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 51988 invoked by uid 99); 2 Aug 2018 22:18:03 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Aug 2018 22:18:03 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 21554C1CA5 for ; Thu, 2 Aug 2018 22:18:03 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -109.501 X-Spam-Level: X-Spam-Status: No, score=-109.501 tagged_above=-999 required=6.31 tests=[ENV_AND_HDR_SPF_MATCH=-0.5, KAM_ASCII_DIVIDERS=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id U6oizT84E2xr for ; Thu, 2 Aug 2018 22:18:02 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id 7ED435F27B for ; Thu, 2 Aug 2018 22:18: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 9790BE01C2 for ; Thu, 2 Aug 2018 22:18: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 4CEC42775F for ; Thu, 2 Aug 2018 22:18:00 +0000 (UTC) Date: Thu, 2 Aug 2018 22:18:00 +0000 (UTC) From: "Bruce Schuchardt (JIRA)" To: issues@geode.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Assigned] (GEODE-5520) Inconsistency created by delta-propagation interaction with concurrency control 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-5520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Schuchardt reassigned GEODE-5520: --------------------------------------- Assignee: Bruce Schuchardt > Inconsistency created by delta-propagation interaction with concurrency control > ------------------------------------------------------------------------------- > > Key: GEODE-5520 > URL: https://issues.apache.org/jira/browse/GEODE-5520 > Project: Geode > Issue Type: Bug > Components: client/server, messaging, regions, serialization > Reporter: Bruce Schuchardt > Assignee: Bruce Schuchardt > Priority: Major > > I tracked a cache inconsistency down to a delta propagation operation that failed over from one server to another and then failed to apply the delta on the new server. > When the full value is sent from the client the message is not marked as a possible-duplicate. Because it was missing this flag the server did not try to recover a concurrency version tag for the operation but instead generated a new version. > When this server propagated the operation to another server it was rejected by that server because it had already processed the operation from the client's original attempt. It recognized this by way of the operation's EventID being recorded in its EventTracker. > This resulted in one server having version X and the other having version X+1 for the entry. > The client then destroyed the same entry with the same server, generating version X+1 in that server. When the server propagated the operation the other server already had X+1 and threw a ConcurrentCacheModificationException. The result was one server having a tombstone for the entry and the other having the value from the delta-propagation operation. > This can be fixed by setting the possible-duplicate flag on the message from the client that contains the full value. The server will then search for a concurrency version tag and use it instead of generating a new one. -- This message was sent by Atlassian JIRA (v7.6.3#76005)