[jira] [Created] (GEODE-7898) error happen when start the second server before restarting the first server, in case of REPLICATE_PERSISTENT data region
Guoxiang Zu created GEODE-7898: -- Summary: error happen when start the second server before restarting the first server, in case of REPLICATE_PERSISTENT data region Key: GEODE-7898 URL: https://issues.apache.org/jira/browse/GEODE-7898 Project: Geode Issue Type: Bug Reporter: Guoxiang Zu Just one step different(the server2 is started before the restarting of server1) with the quick start tutorial [https://geode.apache.org/docs/guide/11/getting_started/15_minute_quickstart_gfsh.html] the steps are as following: " gfsh start locator --name=locator1 start server --name=server1 --server-port=40411 create region --name=regionA --type=REPLICATE_PERSISTENT put --region=regionA --key="1" --value="one" stop server --name=server1 start server --name=server2 --server-port=40412 start server --name=server1 --server-port=40411 " Got the following error: " tarting a Geode Server in /home/ezuxguo/install_geode/my_geode/server1... The Cache Server process terminated unexpectedly with exit status 1. Please refer to the log file in /home/ezuxguo/install_geode/my_geode/server1 for full details. Exception in thread "main" org.apache.geode.cache.persistence.ConflictingPersistentDataException: Region /regionB remote member 192.168.240.1(server2:29316):41001 with persistent data /192.168.240.1:/home/ezuxguo/install_geode/my_geode/server2/. created at timestamp 1584793471853 version 0 diskStoreId 609fc92b54d54334-ae4afa44b63cd641 name server2 was not part of the same distributed system as the local data from /192.168.240.1:/home/ezuxguo/install_geode/my_geode/server1/. created at timestamp 1584792633397 version 0 diskStoreId f1a472367a3141b9-b2c1f9287f14981d name server1 at org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.checkMyStateOnMembers(PersistenceAdvisorImpl.java:526) at org.apache.geode.internal.cache.persistence.PersistenceInitialImageAdvisor.removeReplicatesIfWeAreEqualToAnyOrElseClearEqualMembers(PersistenceInitialImageAdvisor.java:179) at org.apache.geode.internal.cache.persistence.PersistenceInitialImageAdvisor.getAdvice(PersistenceInitialImageAdvisor.java:67) at org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.getInitialImageAdvice(PersistenceAdvisorImpl.java:833) at org.apache.geode.internal.cache.persistence.CreatePersistentRegionProcessor.getInitialImageAdvice(CreatePersistentRegionProcessor.java:52) at org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1195) at org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1080) at org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3040) at org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:2928) at org.apache.geode.internal.cache.xmlcache.RegionCreation.createRoot(RegionCreation.java:237) at org.apache.geode.internal.cache.xmlcache.CacheCreation.initializeRegions(CacheCreation.java:634) at org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:580) at org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:338) at org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4296) at org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:200) at org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1256) at org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1224) at org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191) at org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158) at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142) at org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52) at org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:894) at org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:809) at org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:739) at org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:256) " After this error, then I almost can not do anything, have to "destroy regionA" to solve this problem. In case in the strategy is that server1 should be started before server2, then server2 should wait for the starting of server1. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7898) error happen when start the second server before restarting the first server, in case of REPLICATE_PERSISTENT data region
[ https://issues.apache.org/jira/browse/GEODE-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guoxiang Zu updated GEODE-7898: --- Priority: Critical (was: Major) > error happen when start the second server before restarting the first server, > in case of REPLICATE_PERSISTENT data region > - > > Key: GEODE-7898 > URL: https://issues.apache.org/jira/browse/GEODE-7898 > Project: Geode > Issue Type: Bug >Reporter: Guoxiang Zu >Priority: Critical > > Just one step different(the server2 is started before the restarting of > server1) with the quick start tutorial > [https://geode.apache.org/docs/guide/11/getting_started/15_minute_quickstart_gfsh.html] > the steps are as following: > " > gfsh > start locator --name=locator1 > start server --name=server1 --server-port=40411 > create region --name=regionA --type=REPLICATE_PERSISTENT > put --region=regionA --key="1" --value="one" > stop server --name=server1 > start server --name=server2 --server-port=40412 > start server --name=server1 --server-port=40411 > " > Got the following error: > " > tarting a Geode Server in /home/ezuxguo/install_geode/my_geode/server1... > The Cache Server process terminated unexpectedly with exit status 1. Please > refer to the log file in /home/ezuxguo/install_geode/my_geode/server1 for > full details. > Exception in thread "main" > org.apache.geode.cache.persistence.ConflictingPersistentDataException: Region > /regionB remote member 192.168.240.1(server2:29316):41001 with persistent > data /192.168.240.1:/home/ezuxguo/install_geode/my_geode/server2/. created at > timestamp 1584793471853 version 0 diskStoreId > 609fc92b54d54334-ae4afa44b63cd641 name server2 was not part of the same > distributed system as the local data from > /192.168.240.1:/home/ezuxguo/install_geode/my_geode/server1/. created at > timestamp 1584792633397 version 0 diskStoreId > f1a472367a3141b9-b2c1f9287f14981d name server1 > at > org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.checkMyStateOnMembers(PersistenceAdvisorImpl.java:526) > at > org.apache.geode.internal.cache.persistence.PersistenceInitialImageAdvisor.removeReplicatesIfWeAreEqualToAnyOrElseClearEqualMembers(PersistenceInitialImageAdvisor.java:179) > at > org.apache.geode.internal.cache.persistence.PersistenceInitialImageAdvisor.getAdvice(PersistenceInitialImageAdvisor.java:67) > at > org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.getInitialImageAdvice(PersistenceAdvisorImpl.java:833) > at > org.apache.geode.internal.cache.persistence.CreatePersistentRegionProcessor.getInitialImageAdvice(CreatePersistentRegionProcessor.java:52) > at > org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1195) > at > org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1080) > at > org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3040) > at > org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:2928) > at > org.apache.geode.internal.cache.xmlcache.RegionCreation.createRoot(RegionCreation.java:237) > at > org.apache.geode.internal.cache.xmlcache.CacheCreation.initializeRegions(CacheCreation.java:634) > at > org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:580) > at > org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:338) > at > org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4296) > at > org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:200) > at > org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1256) > at > org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1224) > at > org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191) > at > org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158) > at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142) > at > org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52) > at > org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:894) > at org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:809) > at org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:739) > at org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:256) > " > After this error, then I almost can not do anything, have to "destroy > regionA" to solve this problem. > >
[jira] [Created] (GEODE-7899) stuck when create region with name that already exists before shutdown, with different locator name before and after shutdown
Guoxiang Zu created GEODE-7899: -- Summary: stuck when create region with name that already exists before shutdown, with different locator name before and after shutdown Key: GEODE-7899 URL: https://issues.apache.org/jira/browse/GEODE-7899 Project: Geode Issue Type: Bug Reporter: Guoxiang Zu First, I did the all the steps(until the shutdown step) in the quick start tutorial [https://geode.apache.org/docs/guide/11/getting_started/15_minute_quickstart_gfsh.html], then I did the following steps: " gfsh start locator --name=locator2 start server --name=server1 --server-port=40411 create region --name=regionA --type=REPLICATE_PERSISTENT " then the gfsh terminal is stuck forever, by checking the log of the server1, the following sentence is found: " [warn 2020/03/21 14:19:30.152 CET tid=0x13] There is 1 stuck thread in this node " I have to open another terminal and do the following steps to get rid of the gfsh stuck. " gfsh connect --locator=localhost[10334] shutdown --include-locators=true " -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7898) error happen when start the second server before restarting the first server, in case of REPLICATE_PERSISTENT data region
[ https://issues.apache.org/jira/browse/GEODE-7898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guoxiang Zu updated GEODE-7898: --- Priority: Major (was: Critical) > error happen when start the second server before restarting the first server, > in case of REPLICATE_PERSISTENT data region > - > > Key: GEODE-7898 > URL: https://issues.apache.org/jira/browse/GEODE-7898 > Project: Geode > Issue Type: Bug >Reporter: Guoxiang Zu >Priority: Major > > Just one step different(the server2 is started before the restarting of > server1) with the quick start tutorial > [https://geode.apache.org/docs/guide/11/getting_started/15_minute_quickstart_gfsh.html] > the steps are as following: > " > gfsh > start locator --name=locator1 > start server --name=server1 --server-port=40411 > create region --name=regionA --type=REPLICATE_PERSISTENT > put --region=regionA --key="1" --value="one" > stop server --name=server1 > start server --name=server2 --server-port=40412 > start server --name=server1 --server-port=40411 > " > Got the following error: > " > tarting a Geode Server in /home/ezuxguo/install_geode/my_geode/server1... > The Cache Server process terminated unexpectedly with exit status 1. Please > refer to the log file in /home/ezuxguo/install_geode/my_geode/server1 for > full details. > Exception in thread "main" > org.apache.geode.cache.persistence.ConflictingPersistentDataException: Region > /regionB remote member 192.168.240.1(server2:29316):41001 with persistent > data /192.168.240.1:/home/ezuxguo/install_geode/my_geode/server2/. created at > timestamp 1584793471853 version 0 diskStoreId > 609fc92b54d54334-ae4afa44b63cd641 name server2 was not part of the same > distributed system as the local data from > /192.168.240.1:/home/ezuxguo/install_geode/my_geode/server1/. created at > timestamp 1584792633397 version 0 diskStoreId > f1a472367a3141b9-b2c1f9287f14981d name server1 > at > org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.checkMyStateOnMembers(PersistenceAdvisorImpl.java:526) > at > org.apache.geode.internal.cache.persistence.PersistenceInitialImageAdvisor.removeReplicatesIfWeAreEqualToAnyOrElseClearEqualMembers(PersistenceInitialImageAdvisor.java:179) > at > org.apache.geode.internal.cache.persistence.PersistenceInitialImageAdvisor.getAdvice(PersistenceInitialImageAdvisor.java:67) > at > org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.getInitialImageAdvice(PersistenceAdvisorImpl.java:833) > at > org.apache.geode.internal.cache.persistence.CreatePersistentRegionProcessor.getInitialImageAdvice(CreatePersistentRegionProcessor.java:52) > at > org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1195) > at > org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1080) > at > org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3040) > at > org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:2928) > at > org.apache.geode.internal.cache.xmlcache.RegionCreation.createRoot(RegionCreation.java:237) > at > org.apache.geode.internal.cache.xmlcache.CacheCreation.initializeRegions(CacheCreation.java:634) > at > org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:580) > at > org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:338) > at > org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4296) > at > org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:200) > at > org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1256) > at > org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1224) > at > org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191) > at > org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158) > at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142) > at > org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52) > at > org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:894) > at org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:809) > at org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:739) > at org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:256) > " > After this error, then I almost can not do anything, have to "destroy > regionA" to solve this problem. > > In
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[ https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17063674#comment-17063674 ] Udo Kohlmeyer edited comment on GEODE-7763 at 3/21/20, 5:00 PM: Some benchmark numbers. 1.9.2 vs 1.10.0 org.apache.geode.benchmark.tests.PartitionedWithDeltaAndUniqueObjectReferenceBenchmark average ops/second Baseline: 619.34 Test: 264.12 Difference: -57.4% ops/second standard error Baseline: 6.02 Test: 4.47 Difference: -25.8% ops/second standard deviation Baseline: 104.11 Test:77.25 Difference: -25.8% YS 99th percentile latency Baseline: 20099.00 Test: 20099.00 Difference: +0.0% median latency Baseline: 274464767.00 Test: 573046783.00 Difference: +108.8% 90th percentile latency Baseline: 462159871.00 Test: 1290797055.00 Difference: +179.3% 99th percentile latency Baseline: 673710079.00 Test: 2279604223.00 Difference: +238.4% 99.9th percentile latency Baseline: 924319743.00 Test: 3166699519.00 Difference: +242.6% average latency Baseline: 290824748.99 Test: 682655350.69 Difference: +134.7% latency standard deviation Baseline: 130976085.52 Test: 464068788.07 Difference: +254.3% latency standard error Baseline:304079.59 Test: 1650195.13 Difference: +442.7% 1.9.2 vs 1.11.0 org.apache.geode.benchmark.tests.PartitionedWithDeltaAndUniqueObjectReferenceBenchmark average ops/second Baseline: 619.34 Test: 262.74 Difference: -57.6% ops/second standard error Baseline: 6.02 Test: 3.85 Difference: -36.0% ops/second standard deviation Baseline: 104.11 Test:66.62 Difference: -36.0% YS 99th percentile latency Baseline: 20099.00 Test: 20099.00 Difference: +0.0% median latency Baseline: 274464767.00 Test: 584581119.00 Difference: +113.0% 90th percentile latency Baseline: 462159871.00 Test: 1288699903.00 Difference: +178.8% 99th percentile latency Baseline: 673710079.00 Test: 2181038079.00 Difference: +223.7% 99.9th percentile latency Baseline: 924319743.00 Test: 3114270719.00 Difference: +236.9% average latency Baseline: 290824748.99 Test: 685767812.56 Difference: +135.8% latency standard deviation Baseline: 130976085.52 Test: 453103146.06 Difference: +245.9% latency standard error Baseline:304079.59 Test: 1614994.64 Difference: +431.1% 1.10.0 vs 1.11.0 org.apache.geode.benchmark.tests.PartitionedWithDeltaAndUniqueObjectReferenceBenchmark average ops/second Baseline: 264.12 Test: 262.74 Difference: -0.5% ops/second standard error Baseline: 4.47 Test: 3.85 Difference: -13.8% ops/second standard deviation Baseline:77.25 Test:66.62 Difference: -13.8% YS 99th percentile latency Baseline: 20099.00 Test: 20099.00 Difference: +0.0% median latency Baseline: 573046783.00 Test: 584581119.00 Difference: +2.0% 90th percentile latency Baseline: 1290797055.00 Test: 1288699903.00 Difference: -0.2% 99th percentile latency Baseline: 2279604223.00 Test: 2181038079.00 Difference: -4.3% 99.9th percentile latency Baseline: 3166699519.00 Test: 3114270719.00 Difference: -1.7% average latency Baseline: 682655350.69 Test: 685767812.56 Difference: +0.5% latency standard deviation Baseline: 464068788.07 Test: 453103146.06 Difference: -2.4% latency standard error Baseline: 1650195.13 Test: 1614994.64 Difference: -2.1% 1.9.2 vs 1.12.0 org.apache.geode.benchmark.tests.PartitionedWithDeltaAndUniqueObjectReferenceBenchmark average ops/second Baseline: 619.34 Test: 281.70 Difference: -54.5% ops/second standard error Baseline: 6.02 Test: 4.78 Difference: -20.5% ops/second standard deviation Baseline: 104.11 Test:82.72 Difference: -20.5% YS 99th percentile latency Baseline: 20099.00 Test: 20099.00 Difference: +0.0% median latency Baseline: 274464767.00 Test: 536346623.00 Difference: +95.4% 90th percentile latency Baseline: 462159871.00 Test: 1205862399.00 Difference: +160.9% 99th percentile latency Baseline: 673710079.00 Test: 2118123519.00 Difference: +214.4% 99.9th percentile latency Baseline: 924319743.00 Test: 3072327679.00 Difference: +232.4% average latency Baseline: 290824748.99 Test: 639603850.94 Difference: +119.9% latency standard deviation Baseline: 130976085.52 Test: 434420003.19
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[ https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17063674#comment-17063674 ] Udo Kohlmeyer edited comment on GEODE-7763 at 3/21/20, 5:01 PM: Some benchmark numbers. 1.9.2 vs 1.10.0 org.apache.geode.benchmark.tests.PartitionedWithDeltaAndUniqueObjectReferenceBenchmark average ops/second Baseline: 619.34 Test: 264.12 Difference: -57.4% ops/second standard error Baseline: 6.02 Test: 4.47 Difference: -25.8% ops/second standard deviation Baseline: 104.11 Test:77.25 Difference: -25.8% YS 99th percentile latency Baseline: 20099.00 Test: 20099.00 Difference: +0.0% median latency Baseline: 274464767.00 Test: 573046783.00 Difference: +108.8% 90th percentile latency Baseline: 462159871.00 Test: 1290797055.00 Difference: +179.3% 99th percentile latency Baseline: 673710079.00 Test: 2279604223.00 Difference: +238.4% 99.9th percentile latency Baseline: 924319743.00 Test: 3166699519.00 Difference: +242.6% average latency Baseline: 290824748.99 Test: 682655350.69 Difference: +134.7% latency standard deviation Baseline: 130976085.52 Test: 464068788.07 Difference: +254.3% latency standard error Baseline:304079.59 Test: 1650195.13 Difference: +442.7% 1.9.2 vs 1.11.0 org.apache.geode.benchmark.tests.PartitionedWithDeltaAndUniqueObjectReferenceBenchmark average ops/second Baseline: 619.34 Test: 262.74 Difference: -57.6% ops/second standard error Baseline: 6.02 Test: 3.85 Difference: -36.0% ops/second standard deviation Baseline: 104.11 Test:66.62 Difference: -36.0% YS 99th percentile latency Baseline: 20099.00 Test: 20099.00 Difference: +0.0% median latency Baseline: 274464767.00 Test: 584581119.00 Difference: +113.0% 90th percentile latency Baseline: 462159871.00 Test: 1288699903.00 Difference: +178.8% 99th percentile latency Baseline: 673710079.00 Test: 2181038079.00 Difference: +223.7% 99.9th percentile latency Baseline: 924319743.00 Test: 3114270719.00 Difference: +236.9% average latency Baseline: 290824748.99 Test: 685767812.56 Difference: +135.8% latency standard deviation Baseline: 130976085.52 Test: 453103146.06 Difference: +245.9% latency standard error Baseline:304079.59 Test: 1614994.64 Difference: +431.1% 1.10.0 vs 1.11.0 org.apache.geode.benchmark.tests.PartitionedWithDeltaAndUniqueObjectReferenceBenchmark average ops/second Baseline: 264.12 Test: 262.74 Difference: -0.5% ops/second standard error Baseline: 4.47 Test: 3.85 Difference: -13.8% ops/second standard deviation Baseline:77.25 Test:66.62 Difference: -13.8% YS 99th percentile latency Baseline: 20099.00 Test: 20099.00 Difference: +0.0% median latency Baseline: 573046783.00 Test: 584581119.00 Difference: +2.0% 90th percentile latency Baseline: 1290797055.00 Test: 1288699903.00 Difference: -0.2% 99th percentile latency Baseline: 2279604223.00 Test: 2181038079.00 Difference: -4.3% 99.9th percentile latency Baseline: 3166699519.00 Test: 3114270719.00 Difference: -1.7% average latency Baseline: 682655350.69 Test: 685767812.56 Difference: +0.5% latency standard deviation Baseline: 464068788.07 Test: 453103146.06 Difference: -2.4% latency standard error Baseline: 1650195.13 Test: 1614994.64 Difference: -2.1% 1.9.2 vs 1.12.0 org.apache.geode.benchmark.tests.PartitionedWithDeltaAndUniqueObjectReferenceBenchmark average ops/second Baseline: 619.34 Test: 281.70 Difference: -54.5% ops/second standard error Baseline: 6.02 Test: 4.78 Difference: -20.5% ops/second standard deviation Baseline: 104.11 Test:82.72 Difference: -20.5% YS 99th percentile latency Baseline: 20099.00 Test: 20099.00 Difference: +0.0% median latency Baseline: 274464767.00 Test: 536346623.00 Difference: +95.4% 90th percentile latency Baseline: 462159871.00 Test: 1205862399.00 Difference: +160.9% 99th percentile latency Baseline: 673710079.00 Test: 2118123519.00 Difference: +214.4% 99.9th percentile latency Baseline: 924319743.00 Test: 3072327679.00 Difference: +232.4% average latency Baseline: 290824748.99 Test: 639603850.94 Difference: +119.9% latency standard deviation Baseline: 130976085.52 Test: 434420003.19
[jira] [Commented] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17064038#comment-17064038
]
Jason Huynh commented on GEODE-7763:
@Udo is this test checked into the perf benchmarks to make sure or to catch a
degrade in the future for this "very niche" case? Wouldn't want another
degrade go unnoticed.
> Apache Geode 1.11 severely and negatively impacts performance and resource
> utilization
> --
>
> Key: GEODE-7763
> URL: https://issues.apache.org/jira/browse/GEODE-7763
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.10.0, 1.11.0
>Reporter: John Blum
>Priority: Critical
> Labels: performance
> Fix For: 1.12.0
>
> Attachments: 1.11-client-stats.gfs, 1.11-server-stats.gfs,
> 1.11_thread_dumps.rtf, 1.9-client-stats.gfs, 1.9-server-stats.gfs, 1.9.log,
> apache-geode-1.10-client-server-interaction-output.txt,
> apache-geode-1.10-client-server-startup-output.txt,
> apache-geode-1.11-client-server-interaction-output.txt,
> apache-geode-1.11-client-server-startup-output.txt,
> geode-7763-geode-changes.diff, geode-7763-ssdg-changes.diff
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This problem was first observed in Apache Geode 1.11.0. The problem was not
> present in Apache Geode 1.9.2. This problem is an issue for Apache Geode
> 1.10 as well!
> After upgrading _Spring Session for Apache Geode_ (SSDG) 2.3 to _Spring Data
> for Apache Geode_ (SDG) Neumann/2.3, which is based on Apache Geode 1.11,
> this problem with SSDG's test suite started occurring.
> _Spring Session for Apache Geode_ (SSDG) 2.2, which is based on _Spring Data
> for Apache Geode_ (SDG) Moore/2.2, pulls in Apache Geode 1.9.2. This problem
> did not occur in SSDG 2.2. with Apache Geode 1.9.2.
> Out of curiosity, I wondered whether this problem affects (i.e. was actually
> introduced in) Apache Geode 1.10.0. So, I configured SSDG 2.3 to pull in SDG
> Moore/2.2 but run with Apache Geode 1.10. The problem occurred with Apache
> Geode 1.10 as well!
> The SSDG test class in question, affected by Geode's deficiencies, is the
> [MultiThreadedHighlyConcurrentClientServerSessionOperationsIntegrationTests|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java].
> The test class was modeled after a customer UC, who were using Spring Session
> and Apache Geode/Pivotal GemFire as the HTTP Session state management
> provider, therefore it simulates their highly concurrent environment.
> The test class has 2 primary parameters: [Thread
> Count|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90]
> and the [Workload
> Size|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L91].
> The "_Workload Size_" should not be confused with the "_Payload Size_" of the
> individual objects passed to the Geode data access operations (i.e. {{gets}},
> {{puts}}, {{removes}}). The "_Workload Size_" merely determines the number
> of {{get}}, {{put}} or {{remove}} operations performed on the (Session)
> Region over the duration of the test run. Certain operations are "favored"
> over others, therefore the number of {{gets}}, {{puts}} and {{removes}} is
> weighted.
> The "_Payload_" in this case is a (HTTP) {{Session}} object and the "size" is
> directly proportional to the number of Session attributes stored in the
> Session.
> As you can see from the [test class
> configuration|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90-L91]
> in *SSDG* {{2.2}}, the *Thread Count* was set to *180* and the *Workload
> Size* (or number of Region operations) was set to *10,000*.
> This had to be significantly adjusted in SSDG 2.3 using Apache Geode 1.11
> (and, as it turns out, Apache Geode 1.10 as well), as can be seen in the
> {{2.3.0.M1}} release bits source,
> [here|https://github.com/spring-projects/spring-session-data-geode/blob/2.3.0.M1/spring-session-data-geode/src/inte
[jira] [Issue Comment Deleted] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Huynh updated GEODE-7763:
---
Comment: was deleted
(was: @Udo is this test checked into the perf benchmarks to make sure or to
catch a degrade in the future for this "very niche" case? Wouldn't want
another degrade go unnoticed.
)
> Apache Geode 1.11 severely and negatively impacts performance and resource
> utilization
> --
>
> Key: GEODE-7763
> URL: https://issues.apache.org/jira/browse/GEODE-7763
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.10.0, 1.11.0
>Reporter: John Blum
>Priority: Critical
> Labels: performance
> Fix For: 1.12.0
>
> Attachments: 1.11-client-stats.gfs, 1.11-server-stats.gfs,
> 1.11_thread_dumps.rtf, 1.9-client-stats.gfs, 1.9-server-stats.gfs, 1.9.log,
> apache-geode-1.10-client-server-interaction-output.txt,
> apache-geode-1.10-client-server-startup-output.txt,
> apache-geode-1.11-client-server-interaction-output.txt,
> apache-geode-1.11-client-server-startup-output.txt,
> geode-7763-geode-changes.diff, geode-7763-ssdg-changes.diff
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This problem was first observed in Apache Geode 1.11.0. The problem was not
> present in Apache Geode 1.9.2. This problem is an issue for Apache Geode
> 1.10 as well!
> After upgrading _Spring Session for Apache Geode_ (SSDG) 2.3 to _Spring Data
> for Apache Geode_ (SDG) Neumann/2.3, which is based on Apache Geode 1.11,
> this problem with SSDG's test suite started occurring.
> _Spring Session for Apache Geode_ (SSDG) 2.2, which is based on _Spring Data
> for Apache Geode_ (SDG) Moore/2.2, pulls in Apache Geode 1.9.2. This problem
> did not occur in SSDG 2.2. with Apache Geode 1.9.2.
> Out of curiosity, I wondered whether this problem affects (i.e. was actually
> introduced in) Apache Geode 1.10.0. So, I configured SSDG 2.3 to pull in SDG
> Moore/2.2 but run with Apache Geode 1.10. The problem occurred with Apache
> Geode 1.10 as well!
> The SSDG test class in question, affected by Geode's deficiencies, is the
> [MultiThreadedHighlyConcurrentClientServerSessionOperationsIntegrationTests|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java].
> The test class was modeled after a customer UC, who were using Spring Session
> and Apache Geode/Pivotal GemFire as the HTTP Session state management
> provider, therefore it simulates their highly concurrent environment.
> The test class has 2 primary parameters: [Thread
> Count|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90]
> and the [Workload
> Size|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L91].
> The "_Workload Size_" should not be confused with the "_Payload Size_" of the
> individual objects passed to the Geode data access operations (i.e. {{gets}},
> {{puts}}, {{removes}}). The "_Workload Size_" merely determines the number
> of {{get}}, {{put}} or {{remove}} operations performed on the (Session)
> Region over the duration of the test run. Certain operations are "favored"
> over others, therefore the number of {{gets}}, {{puts}} and {{removes}} is
> weighted.
> The "_Payload_" in this case is a (HTTP) {{Session}} object and the "size" is
> directly proportional to the number of Session attributes stored in the
> Session.
> As you can see from the [test class
> configuration|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90-L91]
> in *SSDG* {{2.2}}, the *Thread Count* was set to *180* and the *Workload
> Size* (or number of Region operations) was set to *10,000*.
> This had to be significantly adjusted in SSDG 2.3 using Apache Geode 1.11
> (and, as it turns out, Apache Geode 1.10 as well), as can be seen in the
> {{2.3.0.M1}} release bits source,
> [here|https://github.com/spring-projects/spring-session-data-geode/blob/2.3.0.M1/spring-session-data-geode/src/integration-test/java/org/spr
[jira] [Commented] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17064039#comment-17064039
]
Jason Huynh commented on GEODE-7763:
[~ukohlmeyer] is this test checked into the perf benchmarks to make sure or to
catch a degrade in the future for this "very niche" case? Wouldn't want
another degrade go unnoticed. Then again, I don't know if the perf benchmarks
are being used/monitored these days.
> Apache Geode 1.11 severely and negatively impacts performance and resource
> utilization
> --
>
> Key: GEODE-7763
> URL: https://issues.apache.org/jira/browse/GEODE-7763
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.10.0, 1.11.0
>Reporter: John Blum
>Priority: Critical
> Labels: performance
> Fix For: 1.12.0
>
> Attachments: 1.11-client-stats.gfs, 1.11-server-stats.gfs,
> 1.11_thread_dumps.rtf, 1.9-client-stats.gfs, 1.9-server-stats.gfs, 1.9.log,
> apache-geode-1.10-client-server-interaction-output.txt,
> apache-geode-1.10-client-server-startup-output.txt,
> apache-geode-1.11-client-server-interaction-output.txt,
> apache-geode-1.11-client-server-startup-output.txt,
> geode-7763-geode-changes.diff, geode-7763-ssdg-changes.diff
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This problem was first observed in Apache Geode 1.11.0. The problem was not
> present in Apache Geode 1.9.2. This problem is an issue for Apache Geode
> 1.10 as well!
> After upgrading _Spring Session for Apache Geode_ (SSDG) 2.3 to _Spring Data
> for Apache Geode_ (SDG) Neumann/2.3, which is based on Apache Geode 1.11,
> this problem with SSDG's test suite started occurring.
> _Spring Session for Apache Geode_ (SSDG) 2.2, which is based on _Spring Data
> for Apache Geode_ (SDG) Moore/2.2, pulls in Apache Geode 1.9.2. This problem
> did not occur in SSDG 2.2. with Apache Geode 1.9.2.
> Out of curiosity, I wondered whether this problem affects (i.e. was actually
> introduced in) Apache Geode 1.10.0. So, I configured SSDG 2.3 to pull in SDG
> Moore/2.2 but run with Apache Geode 1.10. The problem occurred with Apache
> Geode 1.10 as well!
> The SSDG test class in question, affected by Geode's deficiencies, is the
> [MultiThreadedHighlyConcurrentClientServerSessionOperationsIntegrationTests|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java].
> The test class was modeled after a customer UC, who were using Spring Session
> and Apache Geode/Pivotal GemFire as the HTTP Session state management
> provider, therefore it simulates their highly concurrent environment.
> The test class has 2 primary parameters: [Thread
> Count|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90]
> and the [Workload
> Size|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L91].
> The "_Workload Size_" should not be confused with the "_Payload Size_" of the
> individual objects passed to the Geode data access operations (i.e. {{gets}},
> {{puts}}, {{removes}}). The "_Workload Size_" merely determines the number
> of {{get}}, {{put}} or {{remove}} operations performed on the (Session)
> Region over the duration of the test run. Certain operations are "favored"
> over others, therefore the number of {{gets}}, {{puts}} and {{removes}} is
> weighted.
> The "_Payload_" in this case is a (HTTP) {{Session}} object and the "size" is
> directly proportional to the number of Session attributes stored in the
> Session.
> As you can see from the [test class
> configuration|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90-L91]
> in *SSDG* {{2.2}}, the *Thread Count* was set to *180* and the *Workload
> Size* (or number of Region operations) was set to *10,000*.
> This had to be significantly adjusted in SSDG 2.3 using Apache Geode 1.11
> (and, as it turns out, Apache Geode 1.10 as well), as can be seen in the
> {{2.3.0.M1}} release bits source,
> [here|https://github.c
[jira] [Commented] (GEODE-7604) QueryConfigurationServiceConstraintsDistributedTest
[
https://issues.apache.org/jira/browse/GEODE-7604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17064084#comment-17064084
]
ASF subversion and git services commented on GEODE-7604:
Commit 0dfff8cf5415e64577b728098adbd77c5ba07a9c in geode's branch
refs/heads/mass-test-run from Juan José Ramos
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0dfff8c ]
GEODE-7604: Fix Test Flakiness (#4825)
Make sure the CQ is effectively running on the server before
continuing with the test execution to avoid races.
> QueryConfigurationServiceConstraintsDistributedTest
> ---
>
> Key: GEODE-7604
> URL: https://issues.apache.org/jira/browse/GEODE-7604
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Assignee: Juan Ramos
>Priority: Major
> Labels: GeodeCommons
> Fix For: 1.13.0
>
> Time Spent: 3h
> Remaining Estimate: 0h
>
> QueryConfigurationServiceConstraintsDistributedTest had two failures in the
> mass test run...
> [2]
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2252
> [6]
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/2211]
>
> {noformat}
> 01:28:56org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest
> > [2]
> cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer(RegionType:REPLICATE;Operation:CREATE,ExecuteWithInitialResults:true)
> FAILED
> 01:28:56org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest$$Lambda$57/2082907347.run
> in VM 2 running on Host 8cbcba2ac2b2 with 4 VMs
> 01:28:56at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> 01:28:56at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> 01:28:56at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> 01:28:56at
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer(QueryConfigurationServiceConstraintsDistributedTest.java:260)
> 01:28:56
> 01:28:56Caused by:
> 01:28:56org.awaitility.core.ConditionTimeoutException: Assertion
> condition defined as a
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest
> expected:<[7]> but was:<[4]> within 300 seconds.
> 01:28:56at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> 01:28:56at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
> 01:28:56at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> 01:28:56at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> 01:28:56at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> 01:28:56at
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.lambda$cqsShouldSucceedDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsAllowedByTheNewAuthorizer$868d1d80$1(QueryConfigurationServiceConstraintsDistributedTest.java:264)
> 01:28:56
> 01:28:56Caused by:
> 01:28:56org.junit.ComparisonFailure: expected:<[7]> but was:<[4]>
> 01:28:56at
> sun.reflect.GeneratedConstructorAccessor207.newInstance(Unknown Source)
> 01:28:56at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 01:28:56at
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest.lambda$null$13(QueryConfigurationServiceConstraintsDistributedTest.java:266)
> 02:03:51
> 02:03:51679 tests completed, 1 failed, 39 skipped {noformat}
>
>
> {noformat}
> 07:59:46org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest
> > [6]
> cqsShouldFailDuringEventProcessingAfterRegionOperationWhenMethodAuthorizerIsChangedAndQueryContainsMethodsNotAllowedByTheNewAuthorizer(RegionType:REPLICATE;Operation:DESTROY,ExecuteWithInitialResults:true)
> FAILED
> 07:59:46org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.internal.QueryConfigurationServiceConstraintsDistributedTest$$Lambda$33/1244479648.run
> in VM 2 running
[jira] [Commented] (GEODE-7893) geode-lucene POM dependencies are not correct
[ https://issues.apache.org/jira/browse/GEODE-7893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17064086#comment-17064086 ] ASF subversion and git services commented on GEODE-7893: Commit 9cddaec75a2cdfbc01d01cac26c9cb46a61e4692 in geode's branch refs/heads/mass-test-run from Robert Houghton [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9cddaec ] GEODE-7893: Fix Analyzer dependency in geode-lucene (#4829) * GEODE-7893: Fix Analyzer dependency in geode-lucene lucene-core and geode-core are `api` not `implementation` dependencies. > geode-lucene POM dependencies are not correct > - > > Key: GEODE-7893 > URL: https://issues.apache.org/jira/browse/GEODE-7893 > Project: Geode > Issue Type: Bug > Components: build, lucene >Reporter: Robert Houghton >Assignee: Robert Houghton >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The LuceneIndexFactoryBean configures Lucene Analyser, which is not 'api' > dependency in geode-lucene -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7869) Cleanup and enforce Java compiler warnings.
[ https://issues.apache.org/jira/browse/GEODE-7869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17064085#comment-17064085 ] ASF subversion and git services commented on GEODE-7869: Commit a627cb7cc5d01d146e760cdd1d6f53c22a560531 in geode's branch refs/heads/mass-test-run from Jacob Barrett [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a627cb7 ] GEODE-7869: Revert content type changes. Older tests struggle with the deprecated symbols being replaced. Should be revisited later as a wider effort to cleanup deprecated usage. This ticket is focused on not making deprecated usage worse. > Cleanup and enforce Java compiler warnings. > --- > > Key: GEODE-7869 > URL: https://issues.apache.org/jira/browse/GEODE-7869 > Project: Geode > Issue Type: Improvement >Reporter: Jacob Barrett >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > Almost every target completes with warnings and this is noise we don't need. > Currently the compiler is configured to warn on deprecation and unchecked > types. Update the compiler flags to treat those as errors. Update the code to > fix the warnings or suppress where it make sense. > This ticket will be a long running ticket to attach all related changes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7884) server hangs due to IllegalStateException
[
https://issues.apache.org/jira/browse/GEODE-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17064089#comment-17064089
]
ASF subversion and git services commented on GEODE-7884:
Commit 2d2a3f80bd5053749963889c1898df48e9aa0be7 in geode's branch
refs/heads/mass-test-run from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=2d2a3f8 ]
GEODE-7884: server hangs due to IllegalStateException (#4822)
* GEODE-7884: server hangs due to IllegalStateException
Added cancellation check before scheduling an idle-timeout or
ack-wait-threshold timer task. I had to add a new method to
SystemTimerTask and then noticed there were no tests for SystemTimer, so
I cleaned up that class and added tests.
* adding missing copyright header to new test
* fixing LGTM issues
* reinstating 'continue' when encountering a null timer during a sweep
* addressing Bill's comments
renamed swarm everwhere
made the collection of timers associated with a DistributedSystem into a Set
made timer task variables in Connection volatile
added checks in tasks to cancel themselves if their Connection is closed
> server hangs due to IllegalStateException
> -
>
> Key: GEODE-7884
> URL: https://issues.apache.org/jira/browse/GEODE-7884
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.13.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> An application hung on a cache operation:
> {noformat}
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xf61617b8> (a
> java.util.concurrent.CountDownLatch$Sync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:731)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:802)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:779)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:865)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.waitForAckIfNeeded(DistributedCacheOperation.java:779)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation._distribute(DistributedCacheOperation.java:676)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.startOperation(DistributedCacheOperation.java:277)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.distribute(DistributedCacheOperation.java:318)
> at
> org.apache.geode.internal.cache.DistributedRegion.distributeUpdate(DistributedRegion.java:514)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicPutPart3(DistributedRegion.java:492)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.doAfterCompletionActions(RegionMapPut.java:307)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPut(AbstractRegionMapPut.java:185)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut$$Lambda$243/1152982325.run(Unknown
> Source)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.runWhileLockedForCacheModification(AbstractRegionMapPut.java:119)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.runWhileLockedForCacheModification(RegionMapPut.java:161)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.put(AbstractRegionMapPut.java:169)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2044)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5602)
> at
> org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:387)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5580)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:156)
> at
> org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5038)
> at
>
[jira] [Commented] (GEODE-7895) Create integration tests for Expire Command in Redis Adapter
[ https://issues.apache.org/jira/browse/GEODE-7895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17064088#comment-17064088 ] ASF subversion and git services commented on GEODE-7895: Commit f84d3e645d2b67e362534a01bacf31337896d186 in geode's branch refs/heads/mass-test-run from John Hutchison [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f84d3e6 ] GEODE-7895:Create integration tests for EXPIRE command in Redis Adapter (#4831) Co-authored-by: John Hutchison > Create integration tests for Expire Command in Redis Adapter > > > Key: GEODE-7895 > URL: https://issues.apache.org/jira/browse/GEODE-7895 > Project: Geode > Issue Type: Test > Components: redis >Reporter: John Hutchison >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7884) server hangs due to IllegalStateException
[
https://issues.apache.org/jira/browse/GEODE-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17064090#comment-17064090
]
ASF subversion and git services commented on GEODE-7884:
Commit 2d2a3f80bd5053749963889c1898df48e9aa0be7 in geode's branch
refs/heads/mass-test-run from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=2d2a3f8 ]
GEODE-7884: server hangs due to IllegalStateException (#4822)
* GEODE-7884: server hangs due to IllegalStateException
Added cancellation check before scheduling an idle-timeout or
ack-wait-threshold timer task. I had to add a new method to
SystemTimerTask and then noticed there were no tests for SystemTimer, so
I cleaned up that class and added tests.
* adding missing copyright header to new test
* fixing LGTM issues
* reinstating 'continue' when encountering a null timer during a sweep
* addressing Bill's comments
renamed swarm everwhere
made the collection of timers associated with a DistributedSystem into a Set
made timer task variables in Connection volatile
added checks in tasks to cancel themselves if their Connection is closed
> server hangs due to IllegalStateException
> -
>
> Key: GEODE-7884
> URL: https://issues.apache.org/jira/browse/GEODE-7884
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.13.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> An application hung on a cache operation:
> {noformat}
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xf61617b8> (a
> java.util.concurrent.CountDownLatch$Sync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:731)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:802)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:779)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:865)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.waitForAckIfNeeded(DistributedCacheOperation.java:779)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation._distribute(DistributedCacheOperation.java:676)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.startOperation(DistributedCacheOperation.java:277)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.distribute(DistributedCacheOperation.java:318)
> at
> org.apache.geode.internal.cache.DistributedRegion.distributeUpdate(DistributedRegion.java:514)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicPutPart3(DistributedRegion.java:492)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.doAfterCompletionActions(RegionMapPut.java:307)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPut(AbstractRegionMapPut.java:185)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut$$Lambda$243/1152982325.run(Unknown
> Source)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.runWhileLockedForCacheModification(AbstractRegionMapPut.java:119)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.runWhileLockedForCacheModification(RegionMapPut.java:161)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.put(AbstractRegionMapPut.java:169)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2044)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5602)
> at
> org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:387)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5580)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:156)
> at
> org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5038)
> at
>
[jira] [Commented] (GEODE-7886) Update strings tests to cover sad as well as happy paths
[ https://issues.apache.org/jira/browse/GEODE-7886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17064091#comment-17064091 ] ASF subversion and git services commented on GEODE-7886: Commit 39a8eaa76e7910f18a735342c34fdb82b7362ca2 in geode's branch refs/heads/mass-test-run from Ray Ingles [ https://gitbox.apache.org/repos/asf?p=geode.git;h=39a8eaa ] GEODE-7886 Update strings tests to cover sad as well as happy paths (#4821) Co-authored-by: Sarah Abbey > Update strings tests to cover sad as well as happy paths > > > Key: GEODE-7886 > URL: https://issues.apache.org/jira/browse/GEODE-7886 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Raymond Ingles >Priority: Major > Fix For: 1.13.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > This patch updates the tests for the Redis String commands to cover error > conditions and edge cases, as well as concurrent executions. It updates the > command executor unit tests to cover low-level API errors (incorrect > arguments, etc.). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7893) geode-lucene POM dependencies are not correct
[ https://issues.apache.org/jira/browse/GEODE-7893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17064087#comment-17064087 ] ASF subversion and git services commented on GEODE-7893: Commit 9cddaec75a2cdfbc01d01cac26c9cb46a61e4692 in geode's branch refs/heads/mass-test-run from Robert Houghton [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9cddaec ] GEODE-7893: Fix Analyzer dependency in geode-lucene (#4829) * GEODE-7893: Fix Analyzer dependency in geode-lucene lucene-core and geode-core are `api` not `implementation` dependencies. > geode-lucene POM dependencies are not correct > - > > Key: GEODE-7893 > URL: https://issues.apache.org/jira/browse/GEODE-7893 > Project: Geode > Issue Type: Bug > Components: build, lucene >Reporter: Robert Houghton >Assignee: Robert Houghton >Priority: Major > Fix For: 1.13.0 > > Time Spent: 20m > Remaining Estimate: 0h > > The LuceneIndexFactoryBean configures Lucene Analyser, which is not 'api' > dependency in geode-lucene -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7852) Add client side configuration option to support a SNI proxy
[ https://issues.apache.org/jira/browse/GEODE-7852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17064092#comment-17064092 ] ASF subversion and git services commented on GEODE-7852: Commit 53f1e1a81c3b58989a835d37f94466eb3dfc752f in geode's branch refs/heads/mass-test-run from Dan Smith [ https://gitbox.apache.org/repos/asf?p=geode.git;h=53f1e1a ] GEODE-7852: Adding a SocketFactory configuration for client Pools (#4830) Adding the ability to provide a SocketFactory to a client pool for use in creating sockets. Adding an implementation of this SocketFactory that configures the pool to use an SNI proxy. Adding an automated test of the SniSocketFactory that uses docker compose to use a real SNI proxy and geode servers that are not reachable without going through the proxy. Co-authored-by: Bill Burcham > Add client side configuration option to support a SNI proxy > --- > > Key: GEODE-7852 > URL: https://issues.apache.org/jira/browse/GEODE-7852 > Project: Geode > Issue Type: Improvement > Components: client/server, membership >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Fix For: 1.13.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Add an option to the client side configuration to support a the use of a [SNI > proxy|https://www.bamsoftware.com/computers/sniproxy/]. > See also GEODE-7837, which adds a system property to support a SNI proxy. -- This message was sent by Atlassian Jira (v8.3.4#803005)
