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 <mst...@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 <bschucha...@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 > >> <eburgha...@pivotal.io> wrote: > >> > >>> +1 for removal > >>> > >>> On Thu, Nov 16, 2017 at 1:46 PM, Jacob Barrett <jbarr...@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 > >>>> > >>>> > >>>> > >>>> > >>>> > > >
