I would have some concerns with reducing the availability of stats or
devaluing the tooling for analysis. Although exposing more stats via JMX is
a great idea, most of the third party tooling I have seen is best for
monitoring and not post analysis. Not investing in jVSD seems like it would
make th
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 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, maki
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 wrote:
> Thanks for the clarification Jake. So yes, I'm i
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 wrote:
> To clarify, the goal here is to remove access from the public API to inject
> custom stats i
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
+1
On Thu, Nov 16, 2017 at 12:46 PM, Jacob Barrett 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 pl
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
On Mon, Nov 20, 2017 at 11:42 AM, Bruce Schuchardt
Great idea!
> On Nov 20, 2017, at 8:42 AM, Bruce Schuchardt 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
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 Burghard
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
wrote:
> +1 for removal
>
> On Thu, Nov 16, 2017 at 1:46 PM, Jacob Barrett wrote:
>
>> I wa
+1 for removal
On Thu, Nov 16, 2017 at 1:46 PM, Jacob Barrett 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. The
11 matches
Mail list logo
