geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Addison Huddy <ahu...@pivotal.io>
Subject Re: [Discussion] Geode-Native Removing Stats from Public API
Date Mon, 20 Nov 2017 22:31:39 GMT
Thanks for the clarification Jake. So yes, I'm in agreement that we
should simplify the C++ API and remove the stats API from the C++ client.

\ah

On Mon, Nov 20, 2017 at 10:23 AM, Jacob Barrett <jbarrett@pivotal.io> wrote:

> 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 <mstolz@pivotal.io> 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 <
> bschuchardt@pivotal.io
> > >
> > 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
> > >> <eburghardt@pivotal.io> wrote:
> > >>
> > >>> +1 for removal
> > >>>
> > >>> On Thu, Nov 16, 2017 at 1:46 PM, Jacob Barrett <jbarrett@pivotal.io>
> > >>> wrote:
> > >>>
> > >>> I want to open a discussion regarding the removal of
> StatisticsFactory
> > >>>> 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’s
> > highly
> > >>>> unlikely it’s being used but in the case that it is we can consider
> > >>>> 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’s
just
> > hide
> > >>>> it
> > >>>> away.
> > >>>>
> > >>>> -Jake
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message