From dev-return-45596-archive-asf-public=cust-asf.ponee.io@ignite.apache.org Wed Apr 3 14:19:45 2019 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 142E4180600 for ; Wed, 3 Apr 2019 16:19:44 +0200 (CEST) Received: (qmail 32495 invoked by uid 500); 3 Apr 2019 14:19:44 -0000 Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ignite.apache.org Delivered-To: mailing list dev@ignite.apache.org Received: (qmail 32484 invoked by uid 99); 3 Apr 2019 14:19:44 -0000 Received: from mail-relay.apache.org (HELO mailrelay1-lw-us.apache.org) (207.244.88.152) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Apr 2019 14:19:44 +0000 Received: from mail-it1-f178.google.com (mail-it1-f178.google.com [209.85.166.178]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id 454F99575 for ; Wed, 3 Apr 2019 14:19:43 +0000 (UTC) Received: by mail-it1-f178.google.com with SMTP id q14so11378656itk.0 for ; Wed, 03 Apr 2019 07:19:43 -0700 (PDT) X-Gm-Message-State: APjAAAVOW5knLaqymMK1gQbDW5GUoyCScv6673X/qxz/jHcubM0SAcgu kWXb0HI5cB5F4QhiWf168NYI0DKoSY8h3xSMISs= X-Google-Smtp-Source: APXvYqxflNW67jB+CK605DlAeH0Fuu3vecy6FF+PhJPWzMSuCA0mIeFzm3yapWp22d73pMkVLPxSgBg1xPcMyLfZoZ0= X-Received: by 2002:a24:36d4:: with SMTP id l203mr363769itl.143.1554301182858; Wed, 03 Apr 2019 07:19:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Anton Vinogradov Date: Wed, 3 Apr 2019 17:19:32 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Consistency check and fix (review request) To: dev@ignite.apache.org Content-Type: multipart/alternative; boundary="000000000000e0e05c0585a0f19a" --000000000000e0e05c0585a0f19a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ilya, This is impossible due to a conflict between some isolation levels and get-with-consistency expectations. Basically, it's impossible to perform get-with-consistency after the other get at !READ_COMMITTED transaction. The problem here is that value should be cached according to the isolation level, so get-with-consistency is restricted in this case. Same problem we have at case get-with-consistency after put, so we have restriction here too. So, the order matter. :) See OperationRestrictionsCacheConsistencyTest [1] for details. [1] https://github.com/apache/ignite/blob/8b0b0c3e1bde93ff9c4eb5667d794dd64a8b0= 6f0/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/= consistency/OperationRestrictionsCacheConsistencyTest.java On Wed, Apr 3, 2019 at 4:54 PM Ilya Kasnacheev wrote: > Hello! > > Sounds useful especially for new feature development. > > Can you do a run of all tests with cache.forConsistency(), see if there a= re > cases that fail? > > Regards, > -- > Ilya Kasnacheev > > > =D1=81=D1=80, 3 =D0=B0=D0=BF=D1=80. 2019 =D0=B3. =D0=B2 16:17, Anton Vino= gradov : > > > Igniters, > > > > Sometimes, at real deployment, we're faced with inconsistent state acro= ss > > the topology. > > This means that somehow we have different values for the same key at > > different nodes. > > This is an extremely rare situation, but, when you have thousands of > > terabytes of data, this can be a real problem. > > > > Apache Ignite provides a consistency guarantee, each affinity node shou= ld > > contain the same value for the same key, at least eventually. > > But this guarantee can be violated because of bugs, see IEP-31 [1] for > > details. > > > > So, I created the issue [2] to handle such situations. > > The main idea is to have a special cache.withConsistency() proxy allows > > checking a fix inconsistency on get operation. > > > > I've created PR [3] with following improvements (when > > cache.withConsistency() proxy used): > > > > - PESSIMISTIC && !READ_COMMITTED transaction > > -- checks values across the topology (under locks), > > -- finds correct values according to LWW strategy, > > -- records special event in case consistency violation found (contains > > inconsistent map > and last values ), > > -- enlists writes with latest value for each inconsistent key, so it wi= ll > > be written on tx.commit(). > > > > - OPTIMISTIC || READ_COMMITTED transactions > > -- checks values across the topology (not under locks, so false-positiv= e > > case is possible), > > -- starts PESSIMISTIC && SERIALIZABLE (at separate thread) transaction > for > > each possibly broken key and fixes it on a commit if necessary. > > -- original transaction performs get-after-fix and can be continued if > the > > fix does not conflict with isolation level. > > > > Future plans > > - Consistency guard (special process periodically checks we have no > > inconsistency). > > - MVCC support. > > - Atomic caches support. > > - Thin client support. > > - SQL support. > > - Read-with-consistency before the write operation. > > - Single key read-with-consistency optimization, now the collection > > approach used each time. > > - Do not perform read-with-consistency for the key in case it was > > consistently read some time ago. > > > > [1] > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-31+Consistency+che= ck+and+fix > > [2] https://issues.apache.org/jira/browse/IGNITE-10663 > > [3] https://github.com/apache/ignite/pull/5656 > > > --000000000000e0e05c0585a0f19a--