[jira] [Commented] (GEODE-6897) Create a REST v2 endpoint to do rebanlance
[ https://issues.apache.org/jira/browse/GEODE-6897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16888418#comment-16888418 ] ASF subversion and git services commented on GEODE-6897: Commit fd2c091497efe29b40e9a4b42831a59767e0dd44 in geode's branch refs/heads/develop from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=fd2c091 ] GEODE-6897: async operation framework for ClusterManagementService (#3801) * GEODE-6897: create async operations framework for commands such as rebalance > Create a REST v2 endpoint to do rebanlance > -- > > Key: GEODE-6897 > URL: https://issues.apache.org/jira/browse/GEODE-6897 > Project: Geode > Issue Type: New Feature > Components: management >Reporter: Jinmei Liao >Priority: Major > Time Spent: 20h 50m > Remaining Estimate: 0h > > For the first iteration, we are: > 1. make it an async request > 2. have an endpoint to check status of this request > 3. keep the rebalance operation status in memory only > 4. Can do one rebalance at a time, ignore the concurrent rebalance request > 5. do not implement cancel operation yet. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-6897) Create a REST v2 endpoint to do rebanlance
[ https://issues.apache.org/jira/browse/GEODE-6897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16888417#comment-16888417 ] ASF subversion and git services commented on GEODE-6897: Commit fd2c091497efe29b40e9a4b42831a59767e0dd44 in geode's branch refs/heads/develop from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=fd2c091 ] GEODE-6897: async operation framework for ClusterManagementService (#3801) * GEODE-6897: create async operations framework for commands such as rebalance > Create a REST v2 endpoint to do rebanlance > -- > > Key: GEODE-6897 > URL: https://issues.apache.org/jira/browse/GEODE-6897 > Project: Geode > Issue Type: New Feature > Components: management >Reporter: Jinmei Liao >Priority: Major > Time Spent: 20h 50m > Remaining Estimate: 0h > > For the first iteration, we are: > 1. make it an async request > 2. have an endpoint to check status of this request > 3. keep the rebalance operation status in memory only > 4. Can do one rebalance at a time, ignore the concurrent rebalance request > 5. do not implement cancel operation yet. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (GEODE-6763) Make Gateway Receiver events received stat visible through Micrometer
[ https://issues.apache.org/jira/browse/GEODE-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery resolved GEODE-6763. --- Resolution: Fixed > Make Gateway Receiver events received stat visible through Micrometer > - > > Key: GEODE-6763 > URL: https://issues.apache.org/jira/browse/GEODE-6763 > Project: Geode > Issue Type: Bug > Components: statistics >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Fix For: 1.10.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Meter name: cache.gatewayreceiver.events.received -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GEODE-6763) Make Gateway Receiver events received stat visible through Micrometer
[ https://issues.apache.org/jira/browse/GEODE-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery updated GEODE-6763: -- Fix Version/s: 1.10.0 > Make Gateway Receiver events received stat visible through Micrometer > - > > Key: GEODE-6763 > URL: https://issues.apache.org/jira/browse/GEODE-6763 > Project: Geode > Issue Type: Bug > Components: statistics >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Fix For: 1.10.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Meter name: cache.gatewayreceiver.events.received -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (GEODE-6972) User Guide - Clarify behavior of gemfire.disk.recoverValues(Sync) and gemfire.disk.recoverLruValues
[ https://issues.apache.org/jira/browse/GEODE-6972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes resolved GEODE-6972. Resolution: Fixed Fix Version/s: 1.10.0 > User Guide - Clarify behavior of gemfire.disk.recoverValues(Sync) and > gemfire.disk.recoverLruValues > --- > > Key: GEODE-6972 > URL: https://issues.apache.org/jira/browse/GEODE-6972 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Properties gemfire.disk.recoverValues and gemfire.disk.recoverValuesSync are > disabled by default. When enabled, they read all the values from disk, even > though a bunch of them might not fit in memory. So the system waits until the > application reads something before recovering data. For the use cases that > have overflow just to prevent running out of memory, but really expect never > to overflow, users can enable the gemfire.disk.recoverLruValues property. > Clarify this in the User Guide. Likely location: > [https://geode.apache.org/docs/guide/19/managing/troubleshooting/system_failure_and_recovery.html] > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-6972) User Guide - Clarify behavior of gemfire.disk.recoverValues(Sync) and gemfire.disk.recoverLruValues
[ https://issues.apache.org/jira/browse/GEODE-6972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16888389#comment-16888389 ] ASF subversion and git services commented on GEODE-6972: Commit 7e62cddea8597ba14e26ff7c81ab66654af22175 in geode's branch refs/heads/develop from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=7e62cdd ] GEODE-6972: User Guide - Clarify behavior of gemfire.disk.recoverValues (#3811) * GEODE-6972: User Guide - Clarify behavior of gemfire.disk.recoverValues(Sync) and gemfire.disk.recoverLruValues. Add reminders that LRU history is not recoverable > User Guide - Clarify behavior of gemfire.disk.recoverValues(Sync) and > gemfire.disk.recoverLruValues > --- > > Key: GEODE-6972 > URL: https://issues.apache.org/jira/browse/GEODE-6972 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Properties gemfire.disk.recoverValues and gemfire.disk.recoverValuesSync are > disabled by default. When enabled, they read all the values from disk, even > though a bunch of them might not fit in memory. So the system waits until the > application reads something before recovering data. For the use cases that > have overflow just to prevent running out of memory, but really expect never > to overflow, users can enable the gemfire.disk.recoverLruValues property. > Clarify this in the User Guide. Likely location: > [https://geode.apache.org/docs/guide/19/managing/troubleshooting/system_failure_and_recovery.html] > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-6972) User Guide - Clarify behavior of gemfire.disk.recoverValues(Sync) and gemfire.disk.recoverLruValues
[ https://issues.apache.org/jira/browse/GEODE-6972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16888388#comment-16888388 ] ASF subversion and git services commented on GEODE-6972: Commit 7e62cddea8597ba14e26ff7c81ab66654af22175 in geode's branch refs/heads/develop from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=7e62cdd ] GEODE-6972: User Guide - Clarify behavior of gemfire.disk.recoverValues (#3811) * GEODE-6972: User Guide - Clarify behavior of gemfire.disk.recoverValues(Sync) and gemfire.disk.recoverLruValues. Add reminders that LRU history is not recoverable > User Guide - Clarify behavior of gemfire.disk.recoverValues(Sync) and > gemfire.disk.recoverLruValues > --- > > Key: GEODE-6972 > URL: https://issues.apache.org/jira/browse/GEODE-6972 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > Properties gemfire.disk.recoverValues and gemfire.disk.recoverValuesSync are > disabled by default. When enabled, they read all the values from disk, even > though a bunch of them might not fit in memory. So the system waits until the > application reads something before recovering data. For the use cases that > have overflow just to prevent running out of memory, but really expect never > to overflow, users can enable the gemfire.disk.recoverLruValues property. > Clarify this in the User Guide. Likely location: > [https://geode.apache.org/docs/guide/19/managing/troubleshooting/system_failure_and_recovery.html] > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GEODE-6973) getExistingIdForType should not compare all entries in idToType region
[ https://issues.apache.org/jira/browse/GEODE-6973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] xiaojian zhou updated GEODE-6973: - Description: We found the PeerTypeRegistration's getExistingIdForType() will iterate through the idToType region's entries to find if the incoming newType is there. If idToType region contains 20K or 100K entries, this will impact the put throughput (customers did notice the performance downgrade when there're many pdxTypes). To make the things worse, the comparison is to compare the whole object, field to field. If the json object (which will be converted to pdxType) contains 30 fields, the comparison will have to compare up to 30 fields. If the idToType region contains 20K entries, A new pdxType will do 20K x 30 string comparisons before register it. We found each server maintained a typeToId map, this map is used to check if the pdxType exists. If exists, it will return the type id without check the IdToType region. The total number of pdxType did not impact the put performance if the pdxTypd exists. The typeToId map is maintained with a d-lock, each time we added a new pdxType, it will update into the map while still holding the d-lok. So we believe that the map should be the same as the region in content. If we cannot find the pdxType in the map, it should not be in the region. We can skip the iteration of region (which is the root cause of the performance issue). Another issue in current code is: when each time a new type come, it will recreate the map. This is unnecessary and contributes to the slowness too. We should only create the map during initialize(). Here are the tests we want to introduce: 1) a junit test to prove that reorder fields in a big JSON file will not cause significant hashcode conflicts (<1%) 2) a junit test to prove that add a index to a field in a big JSON file will hardly cause hashcode conflicts. This 2 tests are to prove that hashcode conflict is not the root cause of linear probing for PDXTypeId. 3) a junit test to prove that for the cases that hashcode conflict caused by reordered fields, there will be no hashcode conflicts if using SORT_JSON_FIELD_NAMES_PROPERTY=true. 4) a dunit test to prove that SORT_JSON_FIELD_NAMES_PROPERTY=true or false did not impact the performance to add a new pdxType. 5) a dunit test to create a new pdxType from 2 peer server at the same time. The test is to prove that the d-lock take effect, one server create the pdxType, and another server should find the pdxType exists. Do this test both from server directly and from clients. 6) Create 2 different objects which ends up with the same hashcode (we can get the 2 objects from test-1), try to put the 2 objects to create new pdxType. The 2nd one should also create a new type. It should not be treated as "found an existing pdxType". was: We found the PeerTypeRegistration's getExistingIdForType() will iterate through the idToType region's entries to find if the incoming newType is there. If idToType region contains 20K or 100K entries, this will impact the put throughput (customers did notice the performance downgrade when there're many pdxTypes). To make the things worse, the comparison is to compare the whole object, field to field. If the json object (which will be converted to pdxType) contains 30 fields, the comparison will have to compare up to 30 fields. If the idToType region contains 20K entries, A new pdxType will do 20K x 30 string comparisons before register it. To speed up, we proposed to add an index hashmap, which used pdxType's hashcode as key, pdxTypeId's arrayList or hashset as value. When a new pdxType arrived, calculate its hashcode, then use the hashcode to find its pdxTypeIds (it could be a list if there're hash conflicts, but in most of case, it should be only one). Then use this small list to find the pdxTypes. Only need to do field-to-filed compare to this small list of pdxType. This algorithm will dramatically speed up. > getExistingIdForType should not compare all entries in idToType region > -- > > Key: GEODE-6973 > URL: https://issues.apache.org/jira/browse/GEODE-6973 > Project: Geode > Issue Type: Bug >Reporter: xiaojian zhou >Priority: Major > > We found the PeerTypeRegistration's getExistingIdForType() will iterate > through the idToType region's entries to find if the incoming newType is > there. > If idToType region contains 20K or 100K entries, this will impact the put > throughput (customers did notice the performance downgrade when there're many > pdxTypes). > To make the things worse, the comparison is to compare the whole object, > field to field. If the json object (which will be converted to pdxType) > contains 30 fields, the
[jira] [Commented] (GEODE-6783) Remove Thread.sleep() from GatewayReceiverMetricsTest @before method
[ https://issues.apache.org/jira/browse/GEODE-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16888365#comment-16888365 ] Aaron Lindsey commented on GEODE-6783: -- Done > Remove Thread.sleep() from GatewayReceiverMetricsTest @before method > > > Key: GEODE-6783 > URL: https://issues.apache.org/jira/browse/GEODE-6783 > Project: Geode > Issue Type: Improvement > Components: statistics >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > Fix For: 1.10.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (GEODE-6783) Remove Thread.sleep() from GatewayReceiverMetricsTest @before method
[ https://issues.apache.org/jira/browse/GEODE-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey resolved GEODE-6783. -- Resolution: Fixed Fix Version/s: 1.10.0 > Remove Thread.sleep() from GatewayReceiverMetricsTest @before method > > > Key: GEODE-6783 > URL: https://issues.apache.org/jira/browse/GEODE-6783 > Project: Geode > Issue Type: Improvement > Components: statistics >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > Fix For: 1.10.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (GEODE-6783) Remove Thread.sleep() from GatewayReceiverMetricsTest @before method
[ https://issues.apache.org/jira/browse/GEODE-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey reassigned GEODE-6783: Assignee: Aaron Lindsey > Remove Thread.sleep() from GatewayReceiverMetricsTest @before method > > > Key: GEODE-6783 > URL: https://issues.apache.org/jira/browse/GEODE-6783 > Project: Geode > Issue Type: Improvement > Components: statistics >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (GEODE-6367) Health Metrics: Members region
[ https://issues.apache.org/jira/browse/GEODE-6367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Vallely resolved GEODE-6367. - Resolution: Won't Do Resolving with 'won't do'. We have broken this down into mutliple different stories to address each metric independently. > Health Metrics: Members region > -- > > Key: GEODE-6367 > URL: https://issues.apache.org/jira/browse/GEODE-6367 > Project: Geode > Issue Type: New Feature > Components: docs, statistics >Reporter: Nick Vallely >Priority: Major > > Expose a subset of existing 1500+ statistics through Micrometer (GEODE-6295). > In order to not inundate users with so many statistics, we should expose > standard Key Health Indicators. > Consider the following values as part of a set of standard health metrics: > |member.GetsAvgLatency| > |member.PutsAvgLatency| > |member.UsedMemory| > |member.MaxMemory| > Instrument them with Micrometer 'meters' with the following names and tags: > |NAME:|TAGS (Dimensions):| > |Cluster.Host.CacheServer.Cache.GetsAvgLatency|ClusterID, HostName, > ServerName, RegionName| > |Cluster.Host.CacheServer.Cache.PutsAvgLatency|ClusterID, HostName, > ServerName, RegionName| > |Cluster.Host.Jvm.UsedMemory|ClusterID, HostName, ServerName, RegionName| > |Cluster.Host.Jvm.MaxMemory|ClusterID, HostName, ServerName, RegionName| -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Closed] (GEODE-6367) Health Metrics: Members region
[ https://issues.apache.org/jira/browse/GEODE-6367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Vallely closed GEODE-6367. --- > Health Metrics: Members region > -- > > Key: GEODE-6367 > URL: https://issues.apache.org/jira/browse/GEODE-6367 > Project: Geode > Issue Type: New Feature > Components: docs, statistics >Reporter: Nick Vallely >Priority: Major > > Expose a subset of existing 1500+ statistics through Micrometer (GEODE-6295). > In order to not inundate users with so many statistics, we should expose > standard Key Health Indicators. > Consider the following values as part of a set of standard health metrics: > |member.GetsAvgLatency| > |member.PutsAvgLatency| > |member.UsedMemory| > |member.MaxMemory| > Instrument them with Micrometer 'meters' with the following names and tags: > |NAME:|TAGS (Dimensions):| > |Cluster.Host.CacheServer.Cache.GetsAvgLatency|ClusterID, HostName, > ServerName, RegionName| > |Cluster.Host.CacheServer.Cache.PutsAvgLatency|ClusterID, HostName, > ServerName, RegionName| > |Cluster.Host.Jvm.UsedMemory|ClusterID, HostName, ServerName, RegionName| > |Cluster.Host.Jvm.MaxMemory|ClusterID, HostName, ServerName, RegionName| -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-6763) Make Gateway Receiver events received stat visible through Micrometer
[ https://issues.apache.org/jira/browse/GEODE-6763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16888359#comment-16888359 ] Nick Vallely commented on GEODE-6763: - [~demery] if this ticket is completed could you please move it to resolved and assign it a 'fix version', I would assume 1.10 for the fix version. > Make Gateway Receiver events received stat visible through Micrometer > - > > Key: GEODE-6763 > URL: https://issues.apache.org/jira/browse/GEODE-6763 > Project: Geode > Issue Type: Bug > Components: statistics >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Time Spent: 1h 20m > Remaining Estimate: 0h > > Meter name: cache.gatewayreceiver.events.received -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-6783) Remove Thread.sleep() from GatewayReceiverMetricsTest @before method
[ https://issues.apache.org/jira/browse/GEODE-6783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16888358#comment-16888358 ] Nick Vallely commented on GEODE-6783: - [~aaronlindsey] based on the commit, this ticket seems to be resolved, could you please confirm and resolve with 'fix version' specified? > Remove Thread.sleep() from GatewayReceiverMetricsTest @before method > > > Key: GEODE-6783 > URL: https://issues.apache.org/jira/browse/GEODE-6783 > Project: Geode > Issue Type: Improvement > Components: statistics >Reporter: Aaron Lindsey >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-6528) Generate Metrics for Memory Usage
[ https://issues.apache.org/jira/browse/GEODE-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16888357#comment-16888357 ] Nick Vallely commented on GEODE-6528: - [~mole...@pivotal.io] could you ensure this made it into 1.9.0 and close if it did, otherwise change fix version as necessary and then close. > Generate Metrics for Memory Usage > - > > Key: GEODE-6528 > URL: https://issues.apache.org/jira/browse/GEODE-6528 > Project: Geode > Issue Type: New Feature > Components: statistics >Reporter: Michael Oleske >Priority: Major > Fix For: 1.9.0 > > Time Spent: 40m > Remaining Estimate: 0h > > As an operator or developer > I want to have the ability to actively monitor my memory used for a JVM on a > host > So that I can establish a baseline and track performance over time. > GIVEN we have a Micrometer supported time series database > AND a data visualization tool attached to that database > WHEN the cache.opeartions to the data visualization tool > THEN they are able to view the sampled values of the average time it takes to > do a put OR get operation in Geode > AND they are able to use the tags/dimensions to differentiate between > Cluster (Distributed System ID), Host (by hostname), and a member (by Member > name for Server or Locator JVM). -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (GEODE-6528) Generate Metrics for Memory Usage
[ https://issues.apache.org/jira/browse/GEODE-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Vallely resolved GEODE-6528. - Resolution: Fixed > Generate Metrics for Memory Usage > - > > Key: GEODE-6528 > URL: https://issues.apache.org/jira/browse/GEODE-6528 > Project: Geode > Issue Type: New Feature > Components: statistics >Reporter: Michael Oleske >Priority: Major > Fix For: 1.9.0 > > Time Spent: 40m > Remaining Estimate: 0h > > As an operator or developer > I want to have the ability to actively monitor my memory used for a JVM on a > host > So that I can establish a baseline and track performance over time. > GIVEN we have a Micrometer supported time series database > AND a data visualization tool attached to that database > WHEN the cache.opeartions to the data visualization tool > THEN they are able to view the sampled values of the average time it takes to > do a put OR get operation in Geode > AND they are able to use the tags/dimensions to differentiate between > Cluster (Distributed System ID), Host (by hostname), and a member (by Member > name for Server or Locator JVM). -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GEODE-6528) Generate Metrics for Memory Usage
[ https://issues.apache.org/jira/browse/GEODE-6528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Vallely updated GEODE-6528: Fix Version/s: 1.9.0 > Generate Metrics for Memory Usage > - > > Key: GEODE-6528 > URL: https://issues.apache.org/jira/browse/GEODE-6528 > Project: Geode > Issue Type: New Feature > Components: statistics >Reporter: Michael Oleske >Priority: Major > Fix For: 1.9.0 > > Time Spent: 40m > Remaining Estimate: 0h > > As an operator or developer > I want to have the ability to actively monitor my memory used for a JVM on a > host > So that I can establish a baseline and track performance over time. > GIVEN we have a Micrometer supported time series database > AND a data visualization tool attached to that database > WHEN the cache.opeartions to the data visualization tool > THEN they are able to view the sampled values of the average time it takes to > do a put OR get operation in Geode > AND they are able to use the tags/dimensions to differentiate between > Cluster (Distributed System ID), Host (by hostname), and a member (by Member > name for Server or Locator JVM). -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-6779) Create disk-store command should only return when DistributedSystemMXBean reflects creation status
[
https://issues.apache.org/jira/browse/GEODE-6779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16888321#comment-16888321
]
ASF subversion and git services commented on GEODE-6779:
Commit da87d6482aa53b7d34473f8d3eb47c4bbd8ab2b8 in geode's branch
refs/heads/develop from Joris Melchior
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=da87d64 ]
GEODE-6779: fix issues with DUnit failures (#3810)
- due to different ways of determining existence of disk stores
- added more protection against NPEs
- Move diskStore presence checking to DiskStoreCommandsUtils
- Move tests to newly created DiskStoreCommandsUtilsTest
> Create disk-store command should only return when DistributedSystemMXBean
> reflects creation status
> --
>
> Key: GEODE-6779
> URL: https://issues.apache.org/jira/browse/GEODE-6779
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Fix For: 1.10.0
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Once fixed, we can remove
> {{MemberVM.waitUntilDiskStoreIsReadyOnExactlyThisManyServers}}.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (GEODE-6982) The statusMessage field in the Cluster Management Service response needs more editing
Jinmei Liao created GEODE-6982: -- Summary: The statusMessage field in the Cluster Management Service response needs more editing Key: GEODE-6982 URL: https://issues.apache.org/jira/browse/GEODE-6982 Project: Geode Issue Type: Improvement Components: management Reporter: Jinmei Liao Per docs feedback, for those statusMessages shown on the twiki page: https://cwiki.apache.org/confluence/display/GEODE/Management+REST+API, these following improvement could be made: 1. start with capital letter, 2 end with a period, 3. spell out configuration. 4. no mention of “Cache Element” in ""cache element Foo already exists.", 5: "Region name is required." instead of "Name of the region has to be specified.", 6: remove hyphen between “double-underscore” 7 "user does not have “DATA:MANAGE” permission" instead of "user not authorized for DATA:MANAGE". 8 The cluster configuration service is not running. instead of "cluster persistence service is not running" 9 region name needs to be consistent use the one without “/”. 10: Failed to delete region /Foo. Reason: ”, instead of "Failed to delete region /Foo because of " 11: include real server name in “server needs to be restarted” -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (GEODE-6981) CF CLI: decouple CF CLI with PCC/Geode - command mapping
[ https://issues.apache.org/jira/browse/GEODE-6981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shelley Lynn Hughes-Godfrey reassigned GEODE-6981: -- Assignee: (was: Shelley Lynn Hughes-Godfrey) > CF CLI: decouple CF CLI with PCC/Geode - command mapping > > > Key: GEODE-6981 > URL: https://issues.apache.org/jira/browse/GEODE-6981 > Project: Geode > Issue Type: New Feature > Components: management >Reporter: Gang Yan >Priority: Major > > things to do: > remove the command mapping component from CF CLI plugin for PCC > add a new general command mapping component on PCC side > this new general command mapping component will do: > # deal with the string input from CF CLI > # find the right endpoint and pass parameters to it > # the endpoint will deal with input and parameters , and return output to > the CF CLI -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Assigned] (GEODE-6981) CF CLI: decouple CF CLI with PCC/Geode - command mapping
[ https://issues.apache.org/jira/browse/GEODE-6981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shelley Lynn Hughes-Godfrey reassigned GEODE-6981: -- Assignee: Shelley Lynn Hughes-Godfrey > CF CLI: decouple CF CLI with PCC/Geode - command mapping > > > Key: GEODE-6981 > URL: https://issues.apache.org/jira/browse/GEODE-6981 > Project: Geode > Issue Type: New Feature > Components: management >Reporter: Gang Yan >Assignee: Shelley Lynn Hughes-Godfrey >Priority: Major > > things to do: > remove the command mapping component from CF CLI plugin for PCC > add a new general command mapping component on PCC side > this new general command mapping component will do: > # deal with the string input from CF CLI > # find the right endpoint and pass parameters to it > # the endpoint will deal with input and parameters , and return output to > the CF CLI -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Resolved] (GEODE-6979) ExportLogsStatsDistributedTestBase not removing generated files
[
https://issues.apache.org/jira/browse/GEODE-6979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella resolved GEODE-6979.
-
Resolution: Fixed
Fix Version/s: 1.10.0
> ExportLogsStatsDistributedTestBase not removing generated files
> ---
>
> Key: GEODE-6979
> URL: https://issues.apache.org/jira/browse/GEODE-6979
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.10.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> When running distributed tests of geode-web I found out that
> ExportLogsOverHttpDistributedTest is failing due to unexpected zip files
> found.
> The test works fine when run alone (`./gradlew geode-web:distributedTest
> --tests=ExportLogsOverHttpDistributedTest`) but
> it fails when it runs with the rest of distributed tests.
> {noformat}
> > Task :geode-web:distributedTest
> org.apache.geode.management.internal.cli.commands.ExportLogsOverHttpDistributedTest
> > withFiles_savedToLocatorSpecifiedRelativeDir FAILED
> java.lang.AssertionError:
> Expecting empty but
> was:<[/home/alb3rtobr/git/geode/geode-web/build/distributedTest/exportedLogs_1563455029358.zip,
>
> /home/alb3rtobr/git/geode/geode-web/build/distributedTest/exportedLogs_1563455029320.zip,
>
> /home/alb3rtobr/git/geode/geode-web/build/distributedTest/exportedLogs_1563455029410.zip]>
> 136 tests completed, 1 failed
> {noformat}
> I found out that ExportLogsStatsOverHttpDistributedTest is creating these
> three zip files which are not deleted.
> This is a fragment of the standard output of
> ExportLogsStatsOverHttpDistributedTest:
> {noformat}
> Command result for :
> Logs exported to:
> /home/alb3rtobr/git/geode/geode-web/build/distributedTest/exportedLogs_1563455029320.zip
> Command result for :
> Logs exported to:
> /home/alb3rtobr/git/geode/geode-web/build/distributedTest/exportedLogs_1563455029358.zip
> Command result for :
> Logs exported to:
> /home/alb3rtobr/git/geode/geode-web/build/distributedTest/exportedLogs_1563455029410.zip
> {noformat}
> ExportLogsStatsOverHttpDistributedTest should delete these files.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Commented] (GEODE-6979) ExportLogsStatsDistributedTestBase not removing generated files
[
https://issues.apache.org/jira/browse/GEODE-6979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16888254#comment-16888254
]
ASF subversion and git services commented on GEODE-6979:
Commit 1d3ae3c46c097948c7e04a1f93793d54e351a376 in geode's branch
refs/heads/develop from Alberto Bustamante Reyes
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=1d3ae3c ]
GEODE-6979: Clean files in ExportLogsStatsDistributedTestBase (#3812)
- Use SerializableTemporaryFolder to clean generated files after tests.
> ExportLogsStatsDistributedTestBase not removing generated files
> ---
>
> Key: GEODE-6979
> URL: https://issues.apache.org/jira/browse/GEODE-6979
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> When running distributed tests of geode-web I found out that
> ExportLogsOverHttpDistributedTest is failing due to unexpected zip files
> found.
> The test works fine when run alone (`./gradlew geode-web:distributedTest
> --tests=ExportLogsOverHttpDistributedTest`) but
> it fails when it runs with the rest of distributed tests.
> {noformat}
> > Task :geode-web:distributedTest
> org.apache.geode.management.internal.cli.commands.ExportLogsOverHttpDistributedTest
> > withFiles_savedToLocatorSpecifiedRelativeDir FAILED
> java.lang.AssertionError:
> Expecting empty but
> was:<[/home/alb3rtobr/git/geode/geode-web/build/distributedTest/exportedLogs_1563455029358.zip,
>
> /home/alb3rtobr/git/geode/geode-web/build/distributedTest/exportedLogs_1563455029320.zip,
>
> /home/alb3rtobr/git/geode/geode-web/build/distributedTest/exportedLogs_1563455029410.zip]>
> 136 tests completed, 1 failed
> {noformat}
> I found out that ExportLogsStatsOverHttpDistributedTest is creating these
> three zip files which are not deleted.
> This is a fragment of the standard output of
> ExportLogsStatsOverHttpDistributedTest:
> {noformat}
> Command result for :
> Logs exported to:
> /home/alb3rtobr/git/geode/geode-web/build/distributedTest/exportedLogs_1563455029320.zip
> Command result for :
> Logs exported to:
> /home/alb3rtobr/git/geode/geode-web/build/distributedTest/exportedLogs_1563455029358.zip
> Command result for :
> Logs exported to:
> /home/alb3rtobr/git/geode/geode-web/build/distributedTest/exportedLogs_1563455029410.zip
> {noformat}
> ExportLogsStatsOverHttpDistributedTest should delete these files.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (GEODE-6981) CF CLI: decouple CF CLI with PCC/Geode - command mapping
Gang Yan created GEODE-6981: --- Summary: CF CLI: decouple CF CLI with PCC/Geode - command mapping Key: GEODE-6981 URL: https://issues.apache.org/jira/browse/GEODE-6981 Project: Geode Issue Type: New Feature Components: management Reporter: Gang Yan things to do: remove the command mapping component from CF CLI plugin for PCC add a new general command mapping component on PCC side this new general command mapping component will do: # deal with the string input from CF CLI # find the right endpoint and pass parameters to it # the endpoint will deal with input and parameters , and return output to the CF CLI -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GEODE-6966) to decouple CF CLI with PCC/Geode - generate table from json based on customer input
[ https://issues.apache.org/jira/browse/GEODE-6966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gang Yan updated GEODE-6966: Summary: to decouple CF CLI with PCC/Geode - generate table from json based on customer input (was: Spike: to decouple CF CLI with PCC/Geode - generate table from json based on customer input) > to decouple CF CLI with PCC/Geode - generate table from json based on > customer input > > > Key: GEODE-6966 > URL: https://issues.apache.org/jira/browse/GEODE-6966 > Project: Geode > Issue Type: New Feature > Components: management >Reporter: Gang Yan >Priority: Major > Labels: management > > two points to spike: > # generate table from json object(1 layer json, multi layer json) > # generate table columns based on customer input (scenarios: input match, > input partly match, input dis-match) -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GEODE-6980) Improve logging when CCS is disabled
[ https://issues.apache.org/jira/browse/GEODE-6980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Boorlagadda updated GEODE-6980: --- Labels: GoodForNewContributors first (was: ) > Improve logging when CCS is disabled > > > Key: GEODE-6980 > URL: https://issues.apache.org/jira/browse/GEODE-6980 > Project: Geode > Issue Type: Improvement > Components: logging >Reporter: Sai Boorlagadda >Priority: Major > Labels: GoodForNewContributors, first > > When cluster configuration service is disabled. Server do log saying no ccs > found > > [info 2019/07/09 12:40:58.057 EDT tid=0x1] No locator(s) found with > cluster configuration service > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GEODE-6980) Improve logging when CCS is disabled
[ https://issues.apache.org/jira/browse/GEODE-6980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sai Boorlagadda updated GEODE-6980: --- Labels: GoodForNewContributors (was: GoodForNewContributors first) > Improve logging when CCS is disabled > > > Key: GEODE-6980 > URL: https://issues.apache.org/jira/browse/GEODE-6980 > Project: Geode > Issue Type: Improvement > Components: logging >Reporter: Sai Boorlagadda >Priority: Major > Labels: GoodForNewContributors > > When cluster configuration service is disabled. Server do log saying no ccs > found > > [info 2019/07/09 12:40:58.057 EDT tid=0x1] No locator(s) found with > cluster configuration service > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (GEODE-6980) Improve logging when CCS is disabled
Sai Boorlagadda created GEODE-6980: -- Summary: Improve logging when CCS is disabled Key: GEODE-6980 URL: https://issues.apache.org/jira/browse/GEODE-6980 Project: Geode Issue Type: Improvement Components: logging Reporter: Sai Boorlagadda When cluster configuration service is disabled. Server do log saying no ccs found [info 2019/07/09 12:40:58.057 EDT tid=0x1] No locator(s) found with cluster configuration service -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-6298) CI Failure: LRUListWithAsyncSortingTest.scanMovesRecentlyUsedNodeToTail
[
https://issues.apache.org/jira/browse/GEODE-6298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16888152#comment-16888152
]
Eric Shu commented on GEODE-6298:
-
Failed again in ci runs:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsUnitTestOpenJDK11/builds/669
> CI Failure: LRUListWithAsyncSortingTest.scanMovesRecentlyUsedNodeToTail
>
>
> Key: GEODE-6298
> URL: https://issues.apache.org/jira/browse/GEODE-6298
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Bruce Schuchardt
>Assignee: Anilkumar Gingade
>Priority: Major
> Labels: CI
>
> Failed in Windows JDK 11 run
> [234|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsUnitTestOpenJDK11/builds/234]
> {noformat}
> org.apache.geode.internal.cache.eviction.LRUListWithAsyncSortingTest >
> scanMovesRecentlyUsedNodeToTail FAILED
> org.junit.ComparisonFailure: expected:<[first]> but was:<[third]>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.eviction.LRUListWithAsyncSortingTest.scanMovesRecentlyUsedNodeToTail(LRUListWithAsyncSortingTest.java:231)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (GEODE-6762) BucketRegion ops do not always need to call createEventForPR
[ https://issues.apache.org/jira/browse/GEODE-6762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund resolved GEODE-6762. -- Resolution: Fixed Fix Version/s: 1.10.0 > BucketRegion ops do not always need to call createEventForPR > > > Key: GEODE-6762 > URL: https://issues.apache.org/jira/browse/GEODE-6762 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: needs-review, performance, pull-request-available > Fix For: 1.10.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > The BucketRegion class has multiple places in the after op event delivery > code that call createEventForPR and then ask that callbacks be invoked for > that event on the partitioned region. > But we will only have callbacks to invoke if we are a cache server that has > clients registered for events or the partitioned region has a cache listener, > We could prevent this optimization by doing some cheap checks to see if any > callbacks are possible before calling createEventForPR. > Some code that does this for BucketRegion put can be found here: > f7a824c62a57a5039b816a4a8b8b4d8c1c1fcb86 and here: > f568960235bda994bd7c6d0c575567ed2ccb10a5 -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-6762) BucketRegion ops do not always need to call createEventForPR
[ https://issues.apache.org/jira/browse/GEODE-6762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16888119#comment-16888119 ] ASF subversion and git services commented on GEODE-6762: Commit 846b9c277e37ae03fe3445c2fdd1a3a43c67e102 in geode's branch refs/heads/develop from mivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=846b9c2 ] GEODE-6762: Prevent unnecessary PartitionedRegion callback events > BucketRegion ops do not always need to call createEventForPR > > > Key: GEODE-6762 > URL: https://issues.apache.org/jira/browse/GEODE-6762 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: needs-review, performance, pull-request-available > Fix For: 1.10.0 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > The BucketRegion class has multiple places in the after op event delivery > code that call createEventForPR and then ask that callbacks be invoked for > that event on the partitioned region. > But we will only have callbacks to invoke if we are a cache server that has > clients registered for events or the partitioned region has a cache listener, > We could prevent this optimization by doing some cheap checks to see if any > callbacks are possible before calling createEventForPR. > Some code that does this for BucketRegion put can be found here: > f7a824c62a57a5039b816a4a8b8b4d8c1c1fcb86 and here: > f568960235bda994bd7c6d0c575567ed2ccb10a5 -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-6947) geode-managment should create its own set of configuration objects for PdxConfiguration
[ https://issues.apache.org/jira/browse/GEODE-6947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16888060#comment-16888060 ] ASF subversion and git services commented on GEODE-6947: Commit 234937aaad59c38a265e15bb64a4aefc061738ee in geode's branch refs/heads/develop from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=234937a ] GEODE-6947: separate Pdx configuration from xml domain object (#3805) > geode-managment should create its own set of configuration objects for > PdxConfiguration > > > Key: GEODE-6947 > URL: https://issues.apache.org/jira/browse/GEODE-6947 > Project: Geode > Issue Type: Sub-task > Components: management >Reporter: Jinmei Liao >Priority: Major > Time Spent: 2.5h > Remaining Estimate: 0h > > PdxConfiguration > only add the supported attributes > modify the implementation of ConfigurationManager to do the bridging between > the configuration objects and xml domain objects -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GEODE-6979) ExportLogsStatsDistributedTestBase not removing generated files
[
https://issues.apache.org/jira/browse/GEODE-6979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Bustamante Reyes updated GEODE-6979:
Labels: pull-request-available (was: )
> ExportLogsStatsDistributedTestBase not removing generated files
> ---
>
> Key: GEODE-6979
> URL: https://issues.apache.org/jira/browse/GEODE-6979
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When running distributed tests of geode-web I found out that
> ExportLogsOverHttpDistributedTest is failing due to unexpected zip files
> found.
> The test works fine when run alone (`./gradlew geode-web:distributedTest
> --tests=ExportLogsOverHttpDistributedTest`) but
> it fails when it runs with the rest of distributed tests.
> {noformat}
> > Task :geode-web:distributedTest
> org.apache.geode.management.internal.cli.commands.ExportLogsOverHttpDistributedTest
> > withFiles_savedToLocatorSpecifiedRelativeDir FAILED
> java.lang.AssertionError:
> Expecting empty but
> was:<[/home/alb3rtobr/git/geode/geode-web/build/distributedTest/exportedLogs_1563455029358.zip,
>
> /home/alb3rtobr/git/geode/geode-web/build/distributedTest/exportedLogs_1563455029320.zip,
>
> /home/alb3rtobr/git/geode/geode-web/build/distributedTest/exportedLogs_1563455029410.zip]>
> 136 tests completed, 1 failed
> {noformat}
> I found out that ExportLogsStatsOverHttpDistributedTest is creating these
> three zip files which are not deleted.
> This is a fragment of the standard output of
> ExportLogsStatsOverHttpDistributedTest:
> {noformat}
> Command result for :
> Logs exported to:
> /home/alb3rtobr/git/geode/geode-web/build/distributedTest/exportedLogs_1563455029320.zip
> Command result for :
> Logs exported to:
> /home/alb3rtobr/git/geode/geode-web/build/distributedTest/exportedLogs_1563455029358.zip
> Command result for :
> Logs exported to:
> /home/alb3rtobr/git/geode/geode-web/build/distributedTest/exportedLogs_1563455029410.zip
> {noformat}
> ExportLogsStatsOverHttpDistributedTest should delete these files.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (GEODE-6979) ExportLogsStatsDistributedTestBase not removing generated files
Alberto Bustamante Reyes created GEODE-6979:
---
Summary: ExportLogsStatsDistributedTestBase not removing generated
files
Key: GEODE-6979
URL: https://issues.apache.org/jira/browse/GEODE-6979
Project: Geode
Issue Type: Bug
Components: tests
Reporter: Alberto Bustamante Reyes
When running distributed tests of geode-web I found out that
ExportLogsOverHttpDistributedTest is failing due to unexpected zip files found.
The test works fine when run alone (`./gradlew geode-web:distributedTest
--tests=ExportLogsOverHttpDistributedTest`) but
it fails when it runs with the rest of distributed tests.
{noformat}
> Task :geode-web:distributedTest
org.apache.geode.management.internal.cli.commands.ExportLogsOverHttpDistributedTest
> withFiles_savedToLocatorSpecifiedRelativeDir FAILED
java.lang.AssertionError:
Expecting empty but
was:<[/home/alb3rtobr/git/geode/geode-web/build/distributedTest/exportedLogs_1563455029358.zip,
/home/alb3rtobr/git/geode/geode-web/build/distributedTest/exportedLogs_1563455029320.zip,
/home/alb3rtobr/git/geode/geode-web/build/distributedTest/exportedLogs_1563455029410.zip]>
136 tests completed, 1 failed
{noformat}
I found out that ExportLogsStatsOverHttpDistributedTest is creating these three
zip files which are not deleted.
This is a fragment of the standard output of
ExportLogsStatsOverHttpDistributedTest:
{noformat}
Command result for :
Logs exported to:
/home/alb3rtobr/git/geode/geode-web/build/distributedTest/exportedLogs_1563455029320.zip
Command result for :
Logs exported to:
/home/alb3rtobr/git/geode/geode-web/build/distributedTest/exportedLogs_1563455029358.zip
Command result for :
Logs exported to:
/home/alb3rtobr/git/geode/geode-web/build/distributedTest/exportedLogs_1563455029410.zip
{noformat}
ExportLogsStatsOverHttpDistributedTest should delete these files.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (GEODE-6979) ExportLogsStatsDistributedTestBase not removing generated files
[
https://issues.apache.org/jira/browse/GEODE-6979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Bustamante Reyes reassigned GEODE-6979:
---
Assignee: Alberto Bustamante Reyes
> ExportLogsStatsDistributedTestBase not removing generated files
> ---
>
> Key: GEODE-6979
> URL: https://issues.apache.org/jira/browse/GEODE-6979
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
>
> When running distributed tests of geode-web I found out that
> ExportLogsOverHttpDistributedTest is failing due to unexpected zip files
> found.
> The test works fine when run alone (`./gradlew geode-web:distributedTest
> --tests=ExportLogsOverHttpDistributedTest`) but
> it fails when it runs with the rest of distributed tests.
> {noformat}
> > Task :geode-web:distributedTest
> org.apache.geode.management.internal.cli.commands.ExportLogsOverHttpDistributedTest
> > withFiles_savedToLocatorSpecifiedRelativeDir FAILED
> java.lang.AssertionError:
> Expecting empty but
> was:<[/home/alb3rtobr/git/geode/geode-web/build/distributedTest/exportedLogs_1563455029358.zip,
>
> /home/alb3rtobr/git/geode/geode-web/build/distributedTest/exportedLogs_1563455029320.zip,
>
> /home/alb3rtobr/git/geode/geode-web/build/distributedTest/exportedLogs_1563455029410.zip]>
> 136 tests completed, 1 failed
> {noformat}
> I found out that ExportLogsStatsOverHttpDistributedTest is creating these
> three zip files which are not deleted.
> This is a fragment of the standard output of
> ExportLogsStatsOverHttpDistributedTest:
> {noformat}
> Command result for :
> Logs exported to:
> /home/alb3rtobr/git/geode/geode-web/build/distributedTest/exportedLogs_1563455029320.zip
> Command result for :
> Logs exported to:
> /home/alb3rtobr/git/geode/geode-web/build/distributedTest/exportedLogs_1563455029358.zip
> Command result for :
> Logs exported to:
> /home/alb3rtobr/git/geode/geode-web/build/distributedTest/exportedLogs_1563455029410.zip
> {noformat}
> ExportLogsStatsOverHttpDistributedTest should delete these files.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (GEODE-4374) ShutdownCommandOverHttpDUnitTest appears to be flaky
[ https://issues.apache.org/jira/browse/GEODE-4374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Bustamante Reyes resolved GEODE-4374. - Resolution: Fixed > ShutdownCommandOverHttpDUnitTest appears to be flaky > > > Key: GEODE-4374 > URL: https://issues.apache.org/jira/browse/GEODE-4374 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Jens Deppe >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > After having some successful runs in precheckin, while adding this test, it > now appears to be intermittently failing. I'm marking it as flaky for now. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-6913) Individual Aggregate Functions Unit Tests
[
https://issues.apache.org/jira/browse/GEODE-6913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16887920#comment-16887920
]
ASF subversion and git services commented on GEODE-6913:
Commit 77b3f0f9b9bd9327a0b3a5be6dc25ae4217a11e4 in geode's branch
refs/heads/develop from Juan José Ramos
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=77b3f0f ]
GEODE-6913: Add Aggregate Functions Unit Tests (#3785)
- Fixed some minor warnings.
- Added Unit tests for all aggregate functions.
> Individual Aggregate Functions Unit Tests
> -
>
> Key: GEODE-6913
> URL: https://issues.apache.org/jira/browse/GEODE-6913
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: GeodeCommons
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Add individual Unit Tests for the following classes:
> * Avg
> * AvgBucketNode
> * AvgDistinct
> * AvgDistinctPRQueryNode
> * AvgPRQueryNode
> * Count
> * CountDistinct
> * CountDistinctPRQueryNode
> * CountPRQueryNode
> * DistinctAggregator
> * MaxMin
> * Sum
> * SumDistinct
> * SumDistinctPRQueryNode
> Some tests already exist in {{AggregatorJUnitTest}}, we need to split them
> into individual Unit Tests and add those that are currently missing.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Resolved] (GEODE-6913) Individual Aggregate Functions Unit Tests
[
https://issues.apache.org/jira/browse/GEODE-6913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan José Ramos Cassella resolved GEODE-6913.
-
Resolution: Fixed
Fix Version/s: 1.10.0
Fixed through
[77b3f0f9b9bd9327a0b3a5be6dc25ae4217a11e4|https://github.com/apache/geode/commit/77b3f0f9b9bd9327a0b3a5be6dc25ae4217a11e4]
> Individual Aggregate Functions Unit Tests
> -
>
> Key: GEODE-6913
> URL: https://issues.apache.org/jira/browse/GEODE-6913
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Labels: GeodeCommons
> Fix For: 1.10.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Add individual Unit Tests for the following classes:
> * Avg
> * AvgBucketNode
> * AvgDistinct
> * AvgDistinctPRQueryNode
> * AvgPRQueryNode
> * Count
> * CountDistinct
> * CountDistinctPRQueryNode
> * CountPRQueryNode
> * DistinctAggregator
> * MaxMin
> * Sum
> * SumDistinct
> * SumDistinctPRQueryNode
> Some tests already exist in {{AggregatorJUnitTest}}, we need to split them
> into individual Unit Tests and add those that are currently missing.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Assigned] (GEODE-6748) Client invalidate operations never use single hop
[
https://issues.apache.org/jira/browse/GEODE-6748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Ivanac reassigned GEODE-6748:
---
Assignee: Mario Ivanac
> Client invalidate operations never use single hop
> -
>
> Key: GEODE-6748
> URL: https://issues.apache.org/jira/browse/GEODE-6748
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.9.0
>Reporter: Barry Oglesby
>Assignee: Mario Ivanac
>Priority: Major
>
> InvalidateOp.execute does:
> {noformat}
> public static void execute(ExecutablePool pool, String region, EntryEventImpl
> event) {
> AbstractOp op = new InvalidateOpImpl(region, event);
> pool.execute(op);
> }{noformat}
> That is the non-single-hop way of executing an operation.
> It should use the single-hop way of executing an operation if
> pr-single-hop-enabled=true.
> The execute methods in PutOp and GetOp show examples of that.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
