From dev-return-27289-apmail-geode-dev-archive=geode.apache.org@geode.apache.org Mon Nov 20 18:24:06 2017 Return-Path: X-Original-To: apmail-geode-dev-archive@minotaur.apache.org Delivered-To: apmail-geode-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id AD5BB171C7 for ; Mon, 20 Nov 2017 18:24:06 +0000 (UTC) Received: (qmail 39230 invoked by uid 500); 20 Nov 2017 18:24:06 -0000 Delivered-To: apmail-geode-dev-archive@geode.apache.org Received: (qmail 39183 invoked by uid 500); 20 Nov 2017 18:24:06 -0000 Mailing-List: contact dev-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 dev@geode.apache.org Received: (qmail 39170 invoked by uid 99); 20 Nov 2017 18:24:06 -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; Mon, 20 Nov 2017 18:24:06 +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 49227180640 for ; Mon, 20 Nov 2017 18:24:05 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.3 X-Spam-Level: X-Spam-Status: No, score=-0.3 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=pivotal-io.20150623.gappssmtp.com 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 5qZKU5Zhwoua for ; Mon, 20 Nov 2017 18:24:03 +0000 (UTC) Received: from mail-io0-f171.google.com (mail-io0-f171.google.com [209.85.223.171]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 611C45FDB9 for ; Mon, 20 Nov 2017 18:24:01 +0000 (UTC) Received: by mail-io0-f171.google.com with SMTP id q101so16681794ioi.1 for ; Mon, 20 Nov 2017 10:24:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pivotal-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=50lYi3y3/Z/VGIOVdoAH3K7eu5zjXEDa6OBKE+l/t34=; b=MkrRvREwrioxpctWO694aNLMIPkkL4wteXy+waOue+c+wXzhfXlZswYxpSVoCKuQOd 2N3ybCJ+Z81jS26rlNHzNIaeHLjvUy8DfALlj6u5oXsN4KTbC/ewhqZe7aLcsvsv0E89 PZmQl7mPQF9H9MlVgBXGNXKMMnpXUnJN1iktX5ICGMFw6f2Q3Xwxf7p1W/eYb/cskBif TyRvKoqFyyzlFsBAQv4dThcjD+jWJm+ovBwe2Zb/v5TECiVhzxJQV8vacNgU1V7mU9M2 DV6sP5XlewDB4pYW2cCClODs0+tSGRr2rLiENws/cEWlApBbWfYrMwWqwpsVGTHftzD3 XJSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=50lYi3y3/Z/VGIOVdoAH3K7eu5zjXEDa6OBKE+l/t34=; b=L0sERo7u1OQU79uya2VkYMYnUiXC7vyoPDpSuuW/WA0v3rYH2dyDv5fK74kxA42xAZ o7tMAzPWfI7yCW7M/5kgsyt1goqabG+fsWSGFi5FxuZhmMGc8LrIH+dQRqxJXSAFZSKv Scl/chEqpcydpCSVzu8YW7nQQqk/d8wdKUYshAuAlPoGOjIshjShNwt/b0Ima4XrEza0 WYIb0eywEUOvvFhwaBmwXk4R34+mHl2k7FzdhvXe7wl798ARjwjfloE9Qqeqy/Z0i6kV LTxh+z02f41yF6cyeEgJwiYSvPTp6FdBONoHtkumEU8/e7HZaoqZUeq6otR1L6cIxHpE R3WQ== X-Gm-Message-State: AJaThX758vTswTIa2rwBKkBoXshpcQrlUinINIbvCB2p7Sc+pq9fP1sJ P5Xko8LTve81JQpqL5BeTVno9pI9Tp1BfWl0X+IXFw== X-Google-Smtp-Source: AGs4zMbjmyWnEODjB3NY3NjPIz1PuCWqHDG/UtxRbVS4JS90v1NLYHPrDK7FnKzdq4xR0YN1SY53ot2Xz51iZyihDik= X-Received: by 10.107.5.142 with SMTP id 136mr13847678iof.229.1511202233313; Mon, 20 Nov 2017 10:23:53 -0800 (PST) MIME-Version: 1.0 References: <206FE8E8-BB0D-4B66-A0EE-86B6F72EE02B@pivotal.io> <37be4811-431e-6861-ac19-232987a1476b@pivotal.io> In-Reply-To: From: Jacob Barrett Date: Mon, 20 Nov 2017 18:23:42 +0000 Message-ID: Subject: Re: [Discussion] Geode-Native Removing Stats from Public API To: dev@geode.apache.org Content-Type: multipart/alternative; boundary="001a113edec04d09c1055e6e30fd" --001a113edec04d09c1055e6e30fd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To clarify, the goal here is to remove access from the public API to inject custom stats into our stats stream. We would still collect stats for the internals of the client. The rational is multifaceted: 1) The C++ API is would need a non-trivial amount of time to modernize. The current API uses pointers of pointers for maintaining collections. There is a strange cross relationship between components in the stats classes which create unique pointer ownership questions. Rather than solving those now and further dragging out the modernization of the C++ API we would drop it and evaluated adding it back in a modern way in the future. Though I suspect adding it back in the future will never happen for the reasons below. 2) The storage format for our stats in proprietary to Geode and lacks wide market adoption. 3) There are no modern tools for analyzing the statistics generated. Geode lacks a tool for viewing or analyzing the statistics. Unless work is prioritized on completing the jVSD application then users are forced to write custom applications to extract the contents of the stats files. I support the removal from the Java public API for reasons 2 and 3. Unless we put a full effort into creating the ecosystem around the stats format to make it usable we should remove it from the public API. I strongly encourage that we remove it internally too but that is for another discussion. -Jake On Mon, Nov 20, 2017 at 9:43 AM Michael Stolz wrote: > I'm not clear on why we are removing stats gathering capability. > Do we know that customers aren't using this? > Is it badly broken? > > What is actually driving this work? > > -- > Mike Stolz > Principal Engineer, GemFire Product Lead > Mobile: +1-631-835-4771 <(631)%20835-4771> > > On Mon, Nov 20, 2017 at 11:42 AM, Bruce Schuchardt > > wrote: > > > Should this be done for the Java caches as well? > > > > > > On 11/17/17 11:48 AM, David Kimura wrote: > > > >> I agree, a statistics interface seems beyond the scope of Geode Native > >> client responsibility. Hiding or removing seems appropriate to me. > >> > >> Thanks, > >> David > >> > >> On Fri, Nov 17, 2017 at 11:29 AM, Ernest Burghardt > >> wrote: > >> > >>> +1 for removal > >>> > >>> On Thu, Nov 16, 2017 at 1:46 PM, Jacob Barrett > >>> wrote: > >>> > >>> I want to open a discussion regarding the removal of StatisticsFactor= y > >>>> and > >>>> related APIs from the public API. I can't see that we would want the > >>>> Geode > >>>> Native client to be a first class statistics/metrics gathering API. > >>>> There > >>>> are plenty of other first class players in this space. If this isn't= a > >>>> feature of the client then I suggest it be moved internally. It=E2= =80=99s > highly > >>>> unlikely it=E2=80=99s being used but in the case that it is we can c= onsider > >>>> moving > >>>> it back after some serious refactoring as it relies on an over > >>>> abundance of > >>>> raw pointers. Rather than spend time refactoring it now let=E2=80=99= s just > hide > >>>> it > >>>> away. > >>>> > >>>> -Jake > >>>> > >>>> > >>>> > >>>> > >>>> > > > --001a113edec04d09c1055e6e30fd--