From issues-return-39680-archive-asf-public=cust-asf.ponee.io@geode.apache.org Fri Aug 3 00:18:10 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 87C7518067B for ; Fri, 3 Aug 2018 00:18:09 +0200 (CEST) Received: (qmail 52014 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 51995 invoked by uid 99); 2 Aug 2018 22:18:03 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-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 spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 4AD9E1806E4 for ; Thu, 2 Aug 2018 22:18:03 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -110.301 X-Spam-Level: X-Spam-Status: No, score=-110.301 tagged_above=-999 required=6.31 tests=[ENV_AND_HDR_SPF_MATCH=-0.5, 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 (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id ENd0T4mnLCfq 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 D80FC5F3DA 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 C5E1DE2632 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 4810B27756 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] [Created] (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 Bruce Schuchardt created GEODE-5520: --------------------------------------- Summary: 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 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)