geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Barrett <jbarr...@pivotal.io>
Subject Re: [Discussion] Geode-Native Removing Stats from Public API
Date Tue, 21 Nov 2017 07:46:26 GMT
Couldn’t agree more for the Java side of things. The first step is deprecating the API for
adding custom stats.

> On Nov 20, 2017, at 11:13 PM, Swapnil Bawaskar <sbawaskar@pivotal.io> wrote:
> 
> A lot of statistics we have are exposed over JMX. I think we should make an
> effort to expose all the stats over JMX, making them consumable with
> existing tooling rather than investing in jVSD.
> 
>> On Mon, Nov 20, 2017 at 2:32 PM Addison Huddy <ahuddy@pivotal.io> wrote:
>> 
>> 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> <(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
View raw message