[jira] [Commented] (GEODE-7001) Add a gauge to track region entry count
[ https://issues.apache.org/jira/browse/GEODE-7001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899312#comment-16899312 ] ASF subversion and git services commented on GEODE-7001: Commit f5a3c9871c27d51bbcd9da7113206a4d27e38522 in geode's branch refs/heads/release/1.10.0 from Aaron Lindsey [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f5a3c98 ] GEODE-7001: Rename LocalRegionTest to LocalRegionPartialMockTest Co-authored-by: Aaron Lindsey Co-authored-by: Kirk Lund (cherry picked from commit 81f8f9c1ca1ec9a591287905e559051284117057) > Add a gauge to track region entry count > --- > > Key: GEODE-7001 > URL: https://issues.apache.org/jira/browse/GEODE-7001 > Project: Geode > Issue Type: New Feature > Components: statistics >Reporter: Dale Emery >Priority: Major > Labels: observability > Time Spent: 8h 20m > Remaining Estimate: 0h > > Add a gauge to RegionPerfStats to track the entry count. > As part of understanding system state and health, knowing what regions exist > with how much data in them is an often asked question of a data store. The > underlying metric is the CachePerfStats.entries value. This is only a piece > of the information that customers need as it does not expose the region or > region type to the users which is critical to understanding how things are > setup. > Scenario: REPLICATE region > Given a cluster with the following servers: > - server1 > - server2 > And the cluster has a "REPLICATE" region named X > And the user has put 10 entries with distinct keys into region X > Then server1's meter registry has the following meter > - meter name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = REPLICATE > - value: 10 > Then server2's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = REPLICATE > - value: 10 > Scenario: PARTITION region with no redundancy > Given a cluster with the following servers: > - server1 > - server2 > And the cluster has a "PARTITION" region named X > And the user has put 10 entries with distinct keys into region X > Then server1's meter registry has the following meter > - meter name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > Then server2's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > And the values of those meters add up to 10 > Scenario: PARTITIONED REDUNDANT > Given a cluster with the following servers: > - server1 > - server2 > - server3 > And the cluster has a "PARTITION_REDUNDANT" region named X > And the redundancy level is set to 1 copy (2 total copies of each key should > exist) > And the user has put 10 entries with distinct keys into region X > Then server1's meter registry has the following meter > - meter name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > Then server2's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > Then server3's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > And the values of those meters add up to 20 -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-7001) Add a gauge to track region entry count
[ https://issues.apache.org/jira/browse/GEODE-7001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899313#comment-16899313 ] ASF subversion and git services commented on GEODE-7001: Commit 373aaf00f0522343f9daba355839088bb37b2a3e in geode's branch refs/heads/release/1.10.0 from Aaron Lindsey [ https://gitbox.apache.org/repos/asf?p=geode.git;h=373aaf0 ] GEODE-7001: Prevent potential NPE in LocalRegion Prevent potential NPE during LocalRegion construction when stat sampling is enabled. Specifically, if getLocalSize() is invoked by the callback sampler before the RegionMap inside LocalRegion is created then it will throw an NPE. Co-authored-by: Aaron Lindsey Co-authored-by: Kirk Lund (cherry picked from commit c2ef3c682c885b4d49aad51edc1c11e80553bdfa) > Add a gauge to track region entry count > --- > > Key: GEODE-7001 > URL: https://issues.apache.org/jira/browse/GEODE-7001 > Project: Geode > Issue Type: New Feature > Components: statistics >Reporter: Dale Emery >Priority: Major > Labels: observability > Time Spent: 8h 20m > Remaining Estimate: 0h > > Add a gauge to RegionPerfStats to track the entry count. > As part of understanding system state and health, knowing what regions exist > with how much data in them is an often asked question of a data store. The > underlying metric is the CachePerfStats.entries value. This is only a piece > of the information that customers need as it does not expose the region or > region type to the users which is critical to understanding how things are > setup. > Scenario: REPLICATE region > Given a cluster with the following servers: > - server1 > - server2 > And the cluster has a "REPLICATE" region named X > And the user has put 10 entries with distinct keys into region X > Then server1's meter registry has the following meter > - meter name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = REPLICATE > - value: 10 > Then server2's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = REPLICATE > - value: 10 > Scenario: PARTITION region with no redundancy > Given a cluster with the following servers: > - server1 > - server2 > And the cluster has a "PARTITION" region named X > And the user has put 10 entries with distinct keys into region X > Then server1's meter registry has the following meter > - meter name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > Then server2's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > And the values of those meters add up to 10 > Scenario: PARTITIONED REDUNDANT > Given a cluster with the following servers: > - server1 > - server2 > - server3 > And the cluster has a "PARTITION_REDUNDANT" region named X > And the redundancy level is set to 1 copy (2 total copies of each key should > exist) > And the user has put 10 entries with distinct keys into region X > Then server1's meter registry has the following meter > - meter name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > Then server2's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > Then server3's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > And the values of those meters add up to 20 -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-7001) Add a gauge to track region entry count
[ https://issues.apache.org/jira/browse/GEODE-7001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899241#comment-16899241 ] ASF subversion and git services commented on GEODE-7001: Commit 81f8f9c1ca1ec9a591287905e559051284117057 in geode's branch refs/heads/develop from Aaron Lindsey [ https://gitbox.apache.org/repos/asf?p=geode.git;h=81f8f9c ] GEODE-7001: Rename LocalRegionTest to LocalRegionPartialMockTest Co-authored-by: Aaron Lindsey Co-authored-by: Kirk Lund > Add a gauge to track region entry count > --- > > Key: GEODE-7001 > URL: https://issues.apache.org/jira/browse/GEODE-7001 > Project: Geode > Issue Type: New Feature > Components: statistics >Reporter: Dale Emery >Priority: Major > Labels: observability > Time Spent: 8h 20m > Remaining Estimate: 0h > > Add a gauge to RegionPerfStats to track the entry count. > As part of understanding system state and health, knowing what regions exist > with how much data in them is an often asked question of a data store. The > underlying metric is the CachePerfStats.entries value. This is only a piece > of the information that customers need as it does not expose the region or > region type to the users which is critical to understanding how things are > setup. > Scenario: REPLICATE region > Given a cluster with the following servers: > - server1 > - server2 > And the cluster has a "REPLICATE" region named X > And the user has put 10 entries with distinct keys into region X > Then server1's meter registry has the following meter > - meter name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = REPLICATE > - value: 10 > Then server2's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = REPLICATE > - value: 10 > Scenario: PARTITION region with no redundancy > Given a cluster with the following servers: > - server1 > - server2 > And the cluster has a "PARTITION" region named X > And the user has put 10 entries with distinct keys into region X > Then server1's meter registry has the following meter > - meter name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > Then server2's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > And the values of those meters add up to 10 > Scenario: PARTITIONED REDUNDANT > Given a cluster with the following servers: > - server1 > - server2 > - server3 > And the cluster has a "PARTITION_REDUNDANT" region named X > And the redundancy level is set to 1 copy (2 total copies of each key should > exist) > And the user has put 10 entries with distinct keys into region X > Then server1's meter registry has the following meter > - meter name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > Then server2's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > Then server3's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > And the values of those meters add up to 20 -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-7001) Add a gauge to track region entry count
[ https://issues.apache.org/jira/browse/GEODE-7001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16899242#comment-16899242 ] ASF subversion and git services commented on GEODE-7001: Commit c2ef3c682c885b4d49aad51edc1c11e80553bdfa in geode's branch refs/heads/develop from Aaron Lindsey [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c2ef3c6 ] GEODE-7001: Prevent potential NPE in LocalRegion Prevent potential NPE during LocalRegion construction when stat sampling is enabled. Specifically, if getLocalSize() is invoked by the callback sampler before the RegionMap inside LocalRegion is created then it will throw an NPE. Co-authored-by: Aaron Lindsey Co-authored-by: Kirk Lund > Add a gauge to track region entry count > --- > > Key: GEODE-7001 > URL: https://issues.apache.org/jira/browse/GEODE-7001 > Project: Geode > Issue Type: New Feature > Components: statistics >Reporter: Dale Emery >Priority: Major > Labels: observability > Time Spent: 8h 20m > Remaining Estimate: 0h > > Add a gauge to RegionPerfStats to track the entry count. > As part of understanding system state and health, knowing what regions exist > with how much data in them is an often asked question of a data store. The > underlying metric is the CachePerfStats.entries value. This is only a piece > of the information that customers need as it does not expose the region or > region type to the users which is critical to understanding how things are > setup. > Scenario: REPLICATE region > Given a cluster with the following servers: > - server1 > - server2 > And the cluster has a "REPLICATE" region named X > And the user has put 10 entries with distinct keys into region X > Then server1's meter registry has the following meter > - meter name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = REPLICATE > - value: 10 > Then server2's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = REPLICATE > - value: 10 > Scenario: PARTITION region with no redundancy > Given a cluster with the following servers: > - server1 > - server2 > And the cluster has a "PARTITION" region named X > And the user has put 10 entries with distinct keys into region X > Then server1's meter registry has the following meter > - meter name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > Then server2's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > And the values of those meters add up to 10 > Scenario: PARTITIONED REDUNDANT > Given a cluster with the following servers: > - server1 > - server2 > - server3 > And the cluster has a "PARTITION_REDUNDANT" region named X > And the redundancy level is set to 1 copy (2 total copies of each key should > exist) > And the user has put 10 entries with distinct keys into region X > Then server1's meter registry has the following meter > - meter name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > Then server2's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > Then server3's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > And the values of those meters add up to 20 -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-7001) Add a gauge to track region entry count
[ https://issues.apache.org/jira/browse/GEODE-7001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16897307#comment-16897307 ] ASF subversion and git services commented on GEODE-7001: Commit 279fa0eb007adb789e1fa1a90e310299bc19e0a7 in geode's branch refs/heads/develop from Dale Emery [ https://gitbox.apache.org/repos/asf?p=geode.git;h=279fa0e ] GEODE-7001: Add region entry count gauge (#3850) * GEODE-7001: Add region entry count gauge Add 'member.region.entries' gauge in RegionPerfStats - Add region.name and data.policy tags - Add an AtomicLong to track the entry count - Configure the member.region.entries gauge to fetch from new getLocalSize() method (see below). - Configure the 'entryCount' stat to be supplied by new getLocalSize() method. Add getLocalSize() method to InternalRegion, and implement it in LocalRegion and PartitionedRegion - In LocalRegion, the method returns the region map size minus the number of tombstones. - In PartitionedRegion, the method sums the local sizes of all local bucket regions. Also refactored the following: - Reorganize CachePerfStats/RegionPerfStats constructors - Remove CachePerfStats.getEntries() - Remove use of CachePerfStats.getEntries() from PartitionedRegionStatus. - Add @Override to ValidatingStatisticsType methods in StatisticsTypeImpl - Extracted invokeSuppliers() to new SuppliableStatistics interface and rename as updateSuppliedValues() - Move responsibility to prepend 'RegionStats-' onto region statistics textID into the classes that create RegionPerfStats and CachePerfStats. Co-authored-by: Michael Oleske Co-authored-by: Kirk Lund Co-Authored-By: Mark Hanson Co-Authored-By: Aaron Lindsey * empty commit to trigger precheckin * Remove leftover atMost * Spotless found unused import > Add a gauge to track region entry count > --- > > Key: GEODE-7001 > URL: https://issues.apache.org/jira/browse/GEODE-7001 > Project: Geode > Issue Type: New Feature > Components: statistics >Reporter: Dale Emery >Priority: Major > Time Spent: 7h 50m > Remaining Estimate: 0h > > Add a gauge to RegionPerfStats to track the entry count. > As part of understanding system state and health, knowing what regions exist > with how much data in them is an often asked question of a data store. The > underlying metric is the CachePerfStats.entries value. This is only a piece > of the information that customers need as it does not expose the region or > region type to the users which is critical to understanding how things are > setup. > Scenario: REPLICATE region > Given a cluster with the following servers: > - server1 > - server2 > And the cluster has a "REPLICATE" region named X > And the user has put 10 entries with distinct keys into region X > Then server1's meter registry has the following meter > - meter name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = REPLICATE > - value: 10 > Then server2's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = REPLICATE > - value: 10 > Scenario: PARTITION region with no redundancy > Given a cluster with the following servers: > - server1 > - server2 > And the cluster has a "PARTITION" region named X > And the user has put 10 entries with distinct keys into region X > Then server1's meter registry has the following meter > - meter name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > Then server2's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > And the values of those meters add up to 10 > Scenario: PARTITIONED REDUNDANT > Given a cluster with the following servers: > - server1 > - server2 > - server3 > And the cluster has a "PARTITION_REDUNDANT" region named X > And the redundancy level is set to 1 copy (2 total copies of each key should > exist) > And the user has put 10 entries with distinct keys into region X > Then server1's meter registry has the following meter > - meter name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > Then server2's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > Then server3's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > And the values of those meters add up to 20 -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-7001) Add a gauge to track region entry count
[ https://issues.apache.org/jira/browse/GEODE-7001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16897306#comment-16897306 ] ASF subversion and git services commented on GEODE-7001: Commit 279fa0eb007adb789e1fa1a90e310299bc19e0a7 in geode's branch refs/heads/develop from Dale Emery [ https://gitbox.apache.org/repos/asf?p=geode.git;h=279fa0e ] GEODE-7001: Add region entry count gauge (#3850) * GEODE-7001: Add region entry count gauge Add 'member.region.entries' gauge in RegionPerfStats - Add region.name and data.policy tags - Add an AtomicLong to track the entry count - Configure the member.region.entries gauge to fetch from new getLocalSize() method (see below). - Configure the 'entryCount' stat to be supplied by new getLocalSize() method. Add getLocalSize() method to InternalRegion, and implement it in LocalRegion and PartitionedRegion - In LocalRegion, the method returns the region map size minus the number of tombstones. - In PartitionedRegion, the method sums the local sizes of all local bucket regions. Also refactored the following: - Reorganize CachePerfStats/RegionPerfStats constructors - Remove CachePerfStats.getEntries() - Remove use of CachePerfStats.getEntries() from PartitionedRegionStatus. - Add @Override to ValidatingStatisticsType methods in StatisticsTypeImpl - Extracted invokeSuppliers() to new SuppliableStatistics interface and rename as updateSuppliedValues() - Move responsibility to prepend 'RegionStats-' onto region statistics textID into the classes that create RegionPerfStats and CachePerfStats. Co-authored-by: Michael Oleske Co-authored-by: Kirk Lund Co-Authored-By: Mark Hanson Co-Authored-By: Aaron Lindsey * empty commit to trigger precheckin * Remove leftover atMost * Spotless found unused import > Add a gauge to track region entry count > --- > > Key: GEODE-7001 > URL: https://issues.apache.org/jira/browse/GEODE-7001 > Project: Geode > Issue Type: New Feature > Components: statistics >Reporter: Dale Emery >Priority: Major > Time Spent: 7h 50m > Remaining Estimate: 0h > > Add a gauge to RegionPerfStats to track the entry count. > As part of understanding system state and health, knowing what regions exist > with how much data in them is an often asked question of a data store. The > underlying metric is the CachePerfStats.entries value. This is only a piece > of the information that customers need as it does not expose the region or > region type to the users which is critical to understanding how things are > setup. > Scenario: REPLICATE region > Given a cluster with the following servers: > - server1 > - server2 > And the cluster has a "REPLICATE" region named X > And the user has put 10 entries with distinct keys into region X > Then server1's meter registry has the following meter > - meter name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = REPLICATE > - value: 10 > Then server2's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = REPLICATE > - value: 10 > Scenario: PARTITION region with no redundancy > Given a cluster with the following servers: > - server1 > - server2 > And the cluster has a "PARTITION" region named X > And the user has put 10 entries with distinct keys into region X > Then server1's meter registry has the following meter > - meter name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > Then server2's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > And the values of those meters add up to 10 > Scenario: PARTITIONED REDUNDANT > Given a cluster with the following servers: > - server1 > - server2 > - server3 > And the cluster has a "PARTITION_REDUNDANT" region named X > And the redundancy level is set to 1 copy (2 total copies of each key should > exist) > And the user has put 10 entries with distinct keys into region X > Then server1's meter registry has the following meter > - meter name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > Then server2's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > Then server3's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > And the values of those meters add up to 20 -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-7001) Add a gauge to track region entry count
[ https://issues.apache.org/jira/browse/GEODE-7001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16891204#comment-16891204 ] ASF subversion and git services commented on GEODE-7001: Commit 4e8ce22292c399f2754404eb473bc32dfad4d451 in geode's branch refs/heads/GEODE-7001-region-entry-count from Michael Oleske [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4e8ce22 ] GEODE-7001: Use LongAdder instead of AtomicLong Co-authored-by: Michael Oleske Co-authored-by: Dale Emery > Add a gauge to track region entry count > --- > > Key: GEODE-7001 > URL: https://issues.apache.org/jira/browse/GEODE-7001 > Project: Geode > Issue Type: New Feature > Components: statistics >Reporter: Dale Emery >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Add a gauge to RegionPerfStats to track the entry count. > As part of understanding system state and health, knowing what regions exist > with how much data in them is an often asked question of a data store. The > underlying metric is the CachePerfStats.entries value. This is only a piece > of the information that customers need as it does not expose the region or > region type to the users which is critical to understanding how things are > setup. > Scenario: REPLICATE region > Given a cluster with the following servers: > - server1 > - server2 > And the cluster has a "REPLICATE" region named X > And the user has put 10 entries with distinct keys into region X > Then server1's meter registry has the following meter > - meter name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = REPLICATE > - value: 10 > Then server2's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = REPLICATE > - value: 10 > Scenario: PARTITION region with no redundancy > Given a cluster with the following servers: > - server1 > - server2 > And the cluster has a "PARTITION" region named X > And the user has put 10 entries with distinct keys into region X > Then server1's meter registry has the following meter > - meter name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > Then server2's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > And the values of those meters add up to 10 > Scenario: PARTITIONED REDUNDANT > Given a cluster with the following servers: > - server1 > - server2 > - server3 > And the cluster has a "PARTITION_REDUNDANT" region named X > And the redundancy level is set to 1 copy (2 total copies of each key should > exist) > And the user has put 10 entries with distinct keys into region X > Then server1's meter registry has the following meter > - meter name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > Then server2's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > Then server3's meter registry has the following meter > - name: member.region.entries > - tag: region_name = X > - tag: > - tag: data_policy = PARTITION > - value: between 0 and 10 > And the values of those meters add up to 20 -- This message was sent by Atlassian JIRA (v7.6.14#76016)
