Hello All,
Since there is no one disagreeing, we are going to start moving forward with
this.
Thanks,
Mark
> On Jul 11, 2019, at 10:33 AM, Darrel Schneider wrote:
>
> Originally we just had a single instance of CachePerfStats per jvm. So all
> the region related stats were always rolled up o
My personal thinking was:
Step 1: fix the object structure this round, and try to keep the data output
the same. The downside here is that a chunk of stuff from CachePerfStats would
then be duplicated into
RegionPerfStats directly where it was there effectively. This also means that
Partitione
Originally we just had a single instance of CachePerfStats per jvm. So all
the region related stats were always rolled up onto the single
CachePerfStats. Later we added RegionPerfStats so that users could see what
was happening on a per region basis. When RegionPerfStats was added it was
made to ex
I would recommend doing a spike for this refactoring before trying to
provide a class diagram -- I would personally learn a lot that would have a
major effect on the resulting class design that I can only guess about up
front.
Another major challenge is in trying to keep the resulting .gfs file
un
See my comments inline..
> On Jul 11, 2019, at 9:36 AM, Darrel Schneider wrote:
>
> Currently we do not make visible per bucket stats. Is the above proposal
> just to change the internal implementation but the stats visible in tools
> like vsd are unchanged?
>
As with my previous e-mail exchang
I accept that point. I would certainly like to minimize the work and per bucket
status would seem undesirable. I can totally agree to back burner that until
some point in the future at which point we agree to move forward on it. I was
just anticipating that would fall out necessarily. That said
Currently we do not make visible per bucket stats. Is the above proposal
just to change the internal implementation but the stats visible in tools
like vsd are unchanged?
Currently we have an internal CachePerfStats which the internal
RegionPerfStats extends. Does your CacheStats replace CachePerf
So is the root of this proposal really about expanding our current stats
collection to include per-bucket stats. If not I would really separate these
two ideas. First focus on refactoring these stats classes to be more manageable
and readable. Then propose adding per-bucket stats as a thing sepa
It depends to be honest. This is just a plan. I would hope to roll them up, but
I can see a case where you have buckets on different servers, that would seem
to necessitate that.
> On Jul 11, 2019, at 9:26 AM, Jacob Barrett wrote:
>
> There isn’t currently a partition stat instance per bucket.
There isn’t currently a partition stat instance per bucket. Are you saying
you’re making that a thing now?
> On Jul 11, 2019, at 9:24 AM, Mark Hanson wrote:
>
> Correct.
>
>> On Jul 11, 2019, at 9:23 AM, Darrel Schneider wrote:
>>
>> Why would a PartitionedRegionStatsImpl contain more than o
Correct.
> On Jul 11, 2019, at 9:23 AM, Darrel Schneider wrote:
>
> Why would a PartitionedRegionStatsImpl contain more than one RegionStats?
> Are these representing the local buckets?
>
> On Wed, Jul 10, 2019 at 4:57 PM Mark Hanson wrote:
>
>> PartitionRegionStatsImpl can contain one to man
Why would a PartitionedRegionStatsImpl contain more than one RegionStats?
Are these representing the local buckets?
On Wed, Jul 10, 2019 at 4:57 PM Mark Hanson wrote:
> PartitionRegionStatsImpl can contain one to many RegionStats
>
> > On Jul 10, 2019, at 4:53 PM, Dan Smith wrote:
> >
> > Seems
PartitionRegionStatsImpl can contain one to many RegionStats
> On Jul 10, 2019, at 4:53 PM, Dan Smith wrote:
>
> Seems reasonable. I'm guessing that CachePerfImpl contains many RegionStats.
> Does PartitionRegionStatsImpl just contain a single RegionStats?
>
> On Wed, Jul 10, 2019 at 4:49 PM M
Seems reasonable. I'm guessing that CachePerfImpl contains many
RegionStats. Does PartitionRegionStatsImpl just contain a single
RegionStats?
On Wed, Jul 10, 2019 at 4:49 PM Mark Hanson wrote:
> Hi All,
>
> As many of you may know our structure for our perf stats is not great. I
> would like to
14 matches
Mail list logo
