From dev-return-33832-archive-asf-public=cust-asf.ponee.io@ignite.apache.org Tue Apr 24 15:29:02 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 96DC7180671 for ; Tue, 24 Apr 2018 15:29:01 +0200 (CEST) Received: (qmail 29740 invoked by uid 500); 24 Apr 2018 13:29:00 -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 29728 invoked by uid 99); 24 Apr 2018 13:28:59 -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; Tue, 24 Apr 2018 13:28:59 +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 4CA95C039D for ; Tue, 24 Apr 2018 13:28:59 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id 2nTl3A1ptfOY for ; Tue, 24 Apr 2018 13:28:58 +0000 (UTC) Received: from mail-ot0-f172.google.com (mail-ot0-f172.google.com [74.125.82.172]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 611AC5FBA9 for ; Tue, 24 Apr 2018 13:28:58 +0000 (UTC) Received: by mail-ot0-f172.google.com with SMTP id h8-v6so21232791otj.7 for ; Tue, 24 Apr 2018 06:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Am923DjGeYlON4uTdxySHAnk+zEqthYJ6wTQPH0wlbk=; b=pgQzHzD0uTp+cRNfvXnFSRU/Kc6v3gu/ux1PCbiyetliHsSa3drgGpSX5ivO1FeKVY hZhRv35nnKcZ8Zwi+MSn4lchnNWZN9unzzGMsi08Kw/LTuzkKCx4dJdTFudrgMQs5neh Uk7ZVKXRnvwLAENXtBkxcoyV4jXh5qBcnnmW103WJ/jEgLA9pA52vMTPDDj11MMUdfOb B6HdEgEne4VCG+GyjCNTAYQ8EDuG9rSE7B1BYFJsvSpjwc9QVVrXFqhksX+CUiGBPV9p rxtB+T5efNxJrKeQg6lS4ZEUo3bYIkCAW84PqC50BDJlGy4p6lwZvB530qBPHdpbxzuE 4ecA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Am923DjGeYlON4uTdxySHAnk+zEqthYJ6wTQPH0wlbk=; b=iTDPv/Bq6eVQICK2tLXODr19vAqvl/oTNYjshXi80U8si4kVLWs2fl1BDXc47UjGUQ 4IurY6K8jNp6vb4Q4jyuLuFNpKrQNxq+uBlL3NiX7mJ9QkaqY3kXgki3GPnlDuL3kL4Y AuQDu+vZtRBl1Ql1LX4Odt7+PGApzJoYIrHtgRNn17nOyMEkqqpsXYGg3HJX/fp01EY+ 6CcKW1c2SafTaFFwJ1pkWtFm/YPZx7whm7TcOA0VtpE5zSLaAjSZ+zrNJZ66a7g5d/6C gDUhvw+LG69gv6GWdgdVumBFeztEDST3gsPiDrEBH+YySzTukjhJBAXYV583FbnHebfu yHdA== X-Gm-Message-State: ALQs6tBiZgnyUge9H1tLL3KLgMuU7gnxqIH0OCKH4dD7eRp6DUf6hIb3 TZQNaprRyGsSYyah11OvUffB2T8VmezU4Ug+s3IrqUPc X-Google-Smtp-Source: AB8JxZq2vimM0pFaarlW4VYpUXRKyqmd53IfrNeYLRXv2CtgWoOScDbVEnvEGTHJNLb48jWt98EkyzORwnLpW2apQgU= X-Received: by 2002:a9d:5719:: with SMTP id p25-v6mr8058309oth.282.1524576531723; Tue, 24 Apr 2018 06:28:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.53.69 with HTTP; Tue, 24 Apr 2018 06:28:51 -0700 (PDT) From: Sergey Kalashnikov Date: Tue, 24 Apr 2018 16:28:51 +0300 Message-ID: Subject: cache size() calculation for MVCC To: dev@ignite.apache.org Content-Type: text/plain; charset="UTF-8" Hi Igniters, I need your advice on a task at hand. Currently cache API size() is a constant time operation, since the number of entries is maintained as a separate counter. However, for MVCC-enabled cache there can be multiple versions of the same entry. In order to calculate the size we need to obtain a MVCC snapshot and then iterate over data pages filtering invisible versions. So, it is impossible to keep the same complexity guarantees. My current implementation internally switches to "full-scan" approach if cache in question is a MVCC-enabled cache. It happens unbeknown to users, which may expect lightning-fast response as before. Perhaps, we might add a new constant to CachePeekMode enumeration that is passed to cache size() to make it explicit? The second concern is that cache size calculation is also included into Cache Metrics API and Visor functionality. Will it be OK for metrics and things alike to keep returning raw unfiltered number of entries? Is there any sense in showing raw unfiltered number of entries which may vary greatly from invokation to invokation with just simple updates running in background? Please share your thoughts. Thanks in advance. -- Sergey