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 <ukohlme...@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 <bschucha...@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 >>>> >>>> >>>> >
