You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Udo Kohlmeyer <uk...@pivotal.io> on 2016/10/19 19:55:05 UTC
Removal of nonSingleHopCount stat from client
Hi there Guys,
I've created https://issues.apache.org/jira/browse/GEODE-2017 to track
the removal of the nonSingleHopCount stat from the client, as it is
potentially a redundant stat.
From the implementation it only increments on "singleHop" enabled pools
when an operation requires more than one hop to complete. This exact
same metric is tracked in "metaDataRefreshCount", which tracks the
amount of meta data refreshes on the client. Which is automatically
refreshed when an operation requires more than one hop.
Does anyone have any objection in the removal of this stat?
--Udo
Re: Removal of nonSingleHopCount stat from client
Posted by Amey Barve <am...@gmail.com>.
I remember, we had added similar stat for nc, but not sure who all use it
On Thu, Oct 20, 2016 at 11:44 PM, Udo Kohlmeyer <uk...@pivotal.io>
wrote:
> Given the feedback received it seems we can remove this stat without fear
> of retribution.
>
> --Udo
>
>
>
> On 19/10/16 3:11 pm, Kirk Lund wrote:
>
>> +1
>>
>> FYI: I know of one customer that uses the old "gemfire stats" command,
>> polling repeatedly for certain stat values written to a gfs file from a
>> native client as a crude form of monitoring, so some folks do make use of
>> client stats (we should give them a better way to monitor clients tho)
>>
>>
>> On Wed, Oct 19, 2016 at 2:56 PM, Bruce Schuchardt <bschuchardt@pivotal.io
>> >
>> wrote:
>>
>> +1 for removing it
>>>
>>> It's redundant, we've rarely used client statistics and I hear that
>>> people
>>> generally have stats turned off in clients anyway.
>>>
>>>
>>> Le 10/19/2016 à 12:55 PM, Udo Kohlmeyer a écrit :
>>>
>>> Hi there Guys,
>>>>
>>>> I've created https://issues.apache.org/jira/browse/GEODE-2017 to track
>>>> the removal of the nonSingleHopCount stat from the client, as it is
>>>> potentially a redundant stat.
>>>>
>>>> From the implementation it only increments on "singleHop" enabled pools
>>>> when an operation requires more than one hop to complete. This exact
>>>> same
>>>> metric is tracked in "metaDataRefreshCount", which tracks the amount of
>>>> meta data refreshes on the client. Which is automatically refreshed
>>>> when
>>>> an operation requires more than one hop.
>>>>
>>>> Does anyone have any objection in the removal of this stat?
>>>>
>>>> --Udo
>>>>
>>>>
>>>>
>
Re: Removal of nonSingleHopCount stat from client
Posted by Udo Kohlmeyer <uk...@pivotal.io>.
Given the feedback received it seems we can remove this stat without
fear of retribution.
--Udo
On 19/10/16 3:11 pm, Kirk Lund wrote:
> +1
>
> FYI: I know of one customer that uses the old "gemfire stats" command,
> polling repeatedly for certain stat values written to a gfs file from a
> native client as a crude form of monitoring, so some folks do make use of
> client stats (we should give them a better way to monitor clients tho)
>
>
> On Wed, Oct 19, 2016 at 2:56 PM, Bruce Schuchardt <bs...@pivotal.io>
> wrote:
>
>> +1 for removing it
>>
>> It's redundant, we've rarely used client statistics and I hear that people
>> generally have stats turned off in clients anyway.
>>
>>
>> Le 10/19/2016 � 12:55 PM, Udo Kohlmeyer a �crit :
>>
>>> Hi there Guys,
>>>
>>> I've created https://issues.apache.org/jira/browse/GEODE-2017 to track
>>> the removal of the nonSingleHopCount stat from the client, as it is
>>> potentially a redundant stat.
>>>
>>> From the implementation it only increments on "singleHop" enabled pools
>>> when an operation requires more than one hop to complete. This exact same
>>> metric is tracked in "metaDataRefreshCount", which tracks the amount of
>>> meta data refreshes on the client. Which is automatically refreshed when
>>> an operation requires more than one hop.
>>>
>>> Does anyone have any objection in the removal of this stat?
>>>
>>> --Udo
>>>
>>>
Re: Removal of nonSingleHopCount stat from client
Posted by Kirk Lund <kl...@pivotal.io>.
+1
FYI: I know of one customer that uses the old "gemfire stats" command,
polling repeatedly for certain stat values written to a gfs file from a
native client as a crude form of monitoring, so some folks do make use of
client stats (we should give them a better way to monitor clients tho)
On Wed, Oct 19, 2016 at 2:56 PM, Bruce Schuchardt <bs...@pivotal.io>
wrote:
> +1 for removing it
>
> It's redundant, we've rarely used client statistics and I hear that people
> generally have stats turned off in clients anyway.
>
>
> Le 10/19/2016 à 12:55 PM, Udo Kohlmeyer a écrit :
>
>> Hi there Guys,
>>
>> I've created https://issues.apache.org/jira/browse/GEODE-2017 to track
>> the removal of the nonSingleHopCount stat from the client, as it is
>> potentially a redundant stat.
>>
>> From the implementation it only increments on "singleHop" enabled pools
>> when an operation requires more than one hop to complete. This exact same
>> metric is tracked in "metaDataRefreshCount", which tracks the amount of
>> meta data refreshes on the client. Which is automatically refreshed when
>> an operation requires more than one hop.
>>
>> Does anyone have any objection in the removal of this stat?
>>
>> --Udo
>>
>>
>
Re: Removal of nonSingleHopCount stat from client
Posted by Bruce Schuchardt <bs...@pivotal.io>.
+1 for removing it
It's redundant, we've rarely used client statistics and I hear that
people generally have stats turned off in clients anyway.
Le 10/19/2016 � 12:55 PM, Udo Kohlmeyer a �crit :
> Hi there Guys,
>
> I've created https://issues.apache.org/jira/browse/GEODE-2017 to track
> the removal of the nonSingleHopCount stat from the client, as it is
> potentially a redundant stat.
>
> From the implementation it only increments on "singleHop" enabled
> pools when an operation requires more than one hop to complete. This
> exact same metric is tracked in "metaDataRefreshCount", which tracks
> the amount of meta data refreshes on the client. Which is
> automatically refreshed when an operation requires more than one hop.
>
> Does anyone have any objection in the removal of this stat?
>
> --Udo
>