[jira] [Commented] (GEODE-4794) ConfigurePDXCommand Fails When Using Defaults
[
https://issues.apache.org/jira/browse/GEODE-4794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16723856#comment-16723856
]
Juan José Ramos Cassella commented on GEODE-4794:
-
[~amurmann]: this was fixed several months ago, not sure why it's still open...
{code:java}
jramos@MacBook-Pro-5:~/git/geode (develop): git tag --contains
ee0690097577ac9dbe241b0bb94ca6e8e4ed89fb
rel/v1.7.0
rel/v1.7.0.RC1
rel/v1.7.0.RC2
rel/v1.8.0
rel/v1.8.0.RC1
rel/v1.8.0.RC2
{code}
> ConfigurePDXCommand Fails When Using Defaults
> -
>
> Key: GEODE-4794
> URL: https://issues.apache.org/jira/browse/GEODE-4794
> Project: Geode
> Issue Type: Bug
> Components: docs, gfsh
>Reporter: Juan José Ramos Cassella
>Assignee: Joey McAllister
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> While working on a fix for GEODE-4771 I've came across another bug: the
> {{configure pdx}} command fails when no parameters are specified, even when
> we state in the [User
> Guide|http://geode.apache.org/docs/guide/14/tools_modules/gfsh/command-pages/configure.html]
> that no parameters are mandatory.
> The source code doesn't generate a valid XML fragment when none of the
> parameters are set and, as such, the resulting {{XmlEntity}} ends up being
> empty, so a {{NullPointerException}} is thrown when the command tries to
> persist the changes to the cluster configuration service:
> {code:java}
> [error 2018/03/07 11:07:48.242 GMT locator1
> tid=0x55] error updating cluster configuration for group cluster
> java.lang.NullPointerException
> at java.io.StringReader.(StringReader.java:50)
> at
> org.apache.geode.management.internal.configuration.utils.XmlUtils.createNode(XmlUtils.java:242)
> at
> org.apache.geode.management.internal.configuration.utils.XmlUtils.addNewNode(XmlUtils.java:133)
> at
> org.apache.geode.distributed.internal.ClusterConfigurationService.addXmlEntity(ClusterConfigurationService.java:204)
> at
> org.apache.geode.management.internal.cli.commands.ConfigurePDXCommand.lambda$configurePDX$0(ConfigurePDXCommand.java:131)
> at
> org.apache.geode.management.internal.cli.commands.GfshCommand.persistClusterConfiguration(GfshCommand.java:72)
> at
> org.apache.geode.management.internal.cli.commands.ConfigurePDXCommand.configurePDX(ConfigurePDXCommand.java:130)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:216)
> at
> org.apache.geode.management.internal.cli.remote.CommandExecutor.invokeCommand(CommandExecutor.java:97)
> at
> org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:45)
> at
> org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:39)
> at
> org.apache.geode.management.internal.cli.remote.OnlineCommandProcessor.executeCommand(OnlineCommandProcessor.java:133)
> at
> org.apache.geode.management.internal.beans.MemberMBeanBridge.processCommand(MemberMBeanBridge.java:1579)
> at
> org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:412)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
> at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
> at
> com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:193)
> at
> com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:175)
> at
> com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:117)
> at
> com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:54)
> at
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
> at com.sun.jmx.mbeanserver.PerInterfa
[jira] [Reopened] (GEODE-5231) CI Failure: PersistentRecoveryOrderDUnitTest.testRecoverAfterConflict fails in teardown
[
https://issues.apache.org/jira/browse/GEODE-5231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider reopened GEODE-5231:
-
This just reproduced in a pr precheckin:
[https://concourse.apachegeode-ci.info/builds/25832]
org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderDUnitTest >
testRecoverAfterConflict FAILED
[ |https://concourse.apachegeode-ci.info/builds/25832#L5c02023e:698]
java.io.FileNotFoundException: File does not exist:
/home/geode/geode/geode-core/build/distributedTest481/diskDir-testRecoverAfterConflict/1/DRLK_IFPersistentRecoveryOrderDUnitTest_testRecoverAfterConflictRegion.lk
[ |https://concourse.apachegeode-ci.info/builds/25832#L5c02023e:699]
[ |https://concourse.apachegeode-ci.info/builds/25832#L5c02023e:700]
> CI Failure: PersistentRecoveryOrderDUnitTest.testRecoverAfterConflict fails
> in teardown
> ---
>
> Key: GEODE-5231
> URL: https://issues.apache.org/jira/browse/GEODE-5231
> Project: Geode
> Issue Type: Bug
> Components: persistence
>Reporter: Sai Boorlagadda
>Priority: Major
> Labels: CI, Flaky
>
> {noformat}
> java.io.FileNotFoundException: File does not exist:
> /tmp/build/ae3c03f4/built-geode/test/geode-core/build/distributedTest622/diskDir-testRecoverAfterConflict/1/DRLK_IFPersistentRecoveryOrderDUnitTest_testRecoverAfterConflictRegion.lk
> at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2396)
> at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1721)
> at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1617)
> at org.apache.commons.io.FileUtils.forceDelete(FileUtils.java:2391)
> at org.apache.commons.io.FileUtils.cleanDirectory(FileUtils.java:1721)
> at org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1617)
> at
> org.apache.geode.internal.cache.persistence.PersistentReplicatedTestBase.postTearDownCacheTestCase(PersistentReplicatedTestBase.java:66)
> at
> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase.preTearDown(JUnit4CacheTestCase.java:348)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:495)
> at sun.reflect.GeneratedMethodAccessor10.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch
[jira] [Updated] (GEODE-6191) Investigate scaleability of benchmarks for different numbers of threads
[ https://issues.apache.org/jira/browse/GEODE-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-6191: - Sprint: Current Iteration 5, Current Iteration 6 (was: Current Iteration 5) > Investigate scaleability of benchmarks for different numbers of threads > --- > > Key: GEODE-6191 > URL: https://issues.apache.org/jira/browse/GEODE-6191 > Project: Geode > Issue Type: Task > Components: benchmarks >Reporter: Dan Smith >Assignee: Brian Rowe >Priority: Major > > We should expect to see benchmark throughput scale linearly with the number > of threads, up to the point where we start hitting either CPU or network > limitations. If we do not scale, that indicates that either something in the > benchmark framework or Geode itself is limiting us. > In a couple of runs in google cloud with 48 threads vs 192 threads on 4 96 > CPU instances, we observed almost the same throughput (but which much higher > latency) with 192 threads. CPU and network stats did not indicate full > utilization. > We should check the scaleability of these tests again after GEODE-6172 and > GEODE-6148 are implemented. Try running the tests with increasing numbers of > threads (eg 4,16,32,64,128,256,512, etc.) in AWS on c5.9xlarge instances and > see when we stop scaling linearly and why. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6148) Improve the efficiency of PrePopulateRegion and increase the key range
[ https://issues.apache.org/jira/browse/GEODE-6148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-6148: - Sprint: Current Iteration 5, Current Iteration 6 (was: Current Iteration 5) > Improve the efficiency of PrePopulateRegion and increase the key range > -- > > Key: GEODE-6148 > URL: https://issues.apache.org/jira/browse/GEODE-6148 > Project: Geode > Issue Type: Improvement > Components: benchmarks >Reporter: Dan Smith >Assignee: Helena Bales >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > We are currently running with a keyRange of 1000, which may be skewing our > results. We want to run with a much larger key range, which means > prepopulating more data. > The PrePopulateRegion task could be much faster if we take some of these > steps: > * Stop duplicating work - right now each server will put the entire key > range, resulting in duplicate puts of the same keys > * use multiple threads - each server populating the region could be using > multiple threads to populate it faster. One option would be to use a > parallelStream, there may be better choicse. > * Use putAlls - putAlls in batches require fewer round trips than puts. > Acceptance: > * All benchmarks can finish their prepopulation step in 30 seconds or less on > reasonable hardware. > * We set a fixed key range that is somewhere between 100 thousand and 100 > million, whatever is most reasonable. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6170) Create scripts for launching benchmarks in AWS
[ https://issues.apache.org/jira/browse/GEODE-6170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-6170: - Sprint: Current Iteration 5, Current Iteration 6 (was: Current Iteration 5) > Create scripts for launching benchmarks in AWS > -- > > Key: GEODE-6170 > URL: https://issues.apache.org/jira/browse/GEODE-6170 > Project: Geode > Issue Type: Improvement > Components: benchmarks >Reporter: Dan Smith >Assignee: Sean Goller >Priority: Major > > We have scripts for launching benchmarks in GCP in the geode-benchmarks repo > under infrastructure/google_cloud. We should create scripts to launch > benchmarks in AWS. > These scripts should mirror the google cloud scripts for launching and > destroying clusters. We should refactor out common logic for running tests > and copying results back. > When we launch instances in AWS, we want to use > * Dedicated instances > * Create a new cluster placement group for our nodes and launch them > simultaneously in that group. See > https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html > * Use an instance size that will give us a dedicated 10Gbit pipe in that > group. c5.9xlarge seems like a good option - see the AWS launch instance > wizard for other options say they gaurantee 10 Gbits/sec if placed into a > placement group. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6134) Generate summary of benchmarks result as part of running the benchmarks
[ https://issues.apache.org/jira/browse/GEODE-6134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-6134: - Sprint: Current Iteration 4, Current Iteration 5, Current Iteration 6 (was: Current Iteration 4, Current Iteration 5) > Generate summary of benchmarks result as part of running the benchmarks > --- > > Key: GEODE-6134 > URL: https://issues.apache.org/jira/browse/GEODE-6134 > Project: Geode > Issue Type: Improvement > Components: benchmarks >Reporter: Dan Smith >Assignee: Helena Bales >Priority: Major > > We currently have a separate ./gradlew analyzeRun task. We should generate > the analysis as part of the run_against_baseline.sh script so we don't have > to keep rerunning it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6192) Investigate the effect of GEODE-6166 on benchmarks
[ https://issues.apache.org/jira/browse/GEODE-6192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-6192: - Sprint: Current Iteration 5, Current Iteration 6 (was: Current Iteration 5) > Investigate the effect of GEODE-6166 on benchmarks > -- > > Key: GEODE-6192 > URL: https://issues.apache.org/jira/browse/GEODE-6192 > Project: Geode > Issue Type: Task > Components: benchmarks >Reporter: Dan Smith >Assignee: nabarun >Priority: Major > > GEODE-6166 should have improved the performance of client/server puts. We > should measure how much this change improved the throughput and latency of > the ReplicatedPutBenchmark and PartitionedPutBenchmark. > If the throughput did not improve, we need to investigate why - does the > change not actually help, or are our benchmarks not sensitive enough? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5188) Add benchmark framework
[ https://issues.apache.org/jira/browse/GEODE-5188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16724278#comment-16724278 ] ASF subversion and git services commented on GEODE-5188: Commit e4b2577305e015f38249db70c23b49b2a0523df6 in geode-native's branch refs/heads/develop from Jacob Barrett [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=e4b2577 ] GEODE-5188 - Adds benchmarking framework. (#293) * Prevent optimization of bench. * Adds benchmark framework. * Refactor for shared integration framework. * Adds some get benchmarks. * Fixes Rat checking > Add benchmark framework > --- > > Key: GEODE-5188 > URL: https://issues.apache.org/jira/browse/GEODE-5188 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Jacob S. Barrett >Assignee: Jacob S. Barrett >Priority: Major > Labels: pull-request-available > Time Spent: 2h 40m > Remaining Estimate: 0h > > Add benchmark framework and sample benchmarks to facilitate benchmarking in > the future. Should include unit/micro benchmarks and integration benchmarks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6206) Improve the performance of PartitionedRegion Puts
[ https://issues.apache.org/jira/browse/GEODE-6206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-6206: - Issue Type: Improvement (was: Task) > Improve the performance of PartitionedRegion Puts > - > > Key: GEODE-6206 > URL: https://issues.apache.org/jira/browse/GEODE-6206 > Project: Geode > Issue Type: Improvement > Components: benchmarks >Reporter: Dan Smith >Priority: Major > > Using the PartitionedPutBenchmark, investigate ways to improve the throughput > and scalability of partitioned region puts. > Acceptance: > We can explain why we have the throughput that we do with this benchmark > (what is the bottleneck) and why we cannot improve it further. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6218) Improve hashing performance on utf-8 string.
[
https://issues.apache.org/jira/browse/GEODE-6218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob S. Barrett updated GEODE-6218:
Description: UTF-8 {{std::string}} is converted to UTF-16
{{std::u16string}} before hashing to produce a has consistent with the server
in Java. Avoid the complete conversion to UTF-16 when hashing UTF-8 strings.
> Improve hashing performance on utf-8 string.
>
>
> Key: GEODE-6218
> URL: https://issues.apache.org/jira/browse/GEODE-6218
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Jacob S. Barrett
>Priority: Major
>
> UTF-8 {{std::string}} is converted to UTF-16 {{std::u16string}} before
> hashing to produce a has consistent with the server in Java. Avoid the
> complete conversion to UTF-16 when hashing UTF-8 strings.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6189) Cleanup: remove unused scripts in ci/scripts/windows/
[
https://issues.apache.org/jira/browse/GEODE-6189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg resolved GEODE-6189.
-
Resolution: Fixed
> Cleanup: remove unused scripts in ci/scripts/windows/
> -
>
> Key: GEODE-6189
> URL: https://issues.apache.org/jira/browse/GEODE-6189
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> These scripts have been replaced / unified with {{execute_tests.sh}} and
> {{archive_results.sh}} and are unused anywhere within the codebase.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6100) LogConsumer is creating instability in suspect string detection
[
https://issues.apache.org/jira/browse/GEODE-6100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reassigned GEODE-6100:
---
Assignee: (was: Patrick Rhomberg)
> LogConsumer is creating instability in suspect string detection
> ---
>
> Key: GEODE-6100
> URL: https://issues.apache.org/jira/browse/GEODE-6100
> Project: Geode
> Issue Type: Bug
>Reporter: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> (Original ticket title: CI:
> CacheClientNotifierDUnitTest.testNormalClient2MultipleCacheServer failed with
> suspect strings)
> Failure at:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/163
> Failed with message:
> {noformat}
> org.apache.geode.internal.cache.wan.CacheClientNotifierDUnitTest >
> testNormalClient2MultipleCacheServer FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 3689
> /hom[warn 2018/11/27 21:24:25.124 UTC
> tid=179] Cache Client
> Updater Thread on ef956df2d60b(376):41003 port 28307
> (ef956df2d60b:28307): Caught following exception while attempting to create a
> server-to-client communication socket and will exit:
> org.apache.geode.cache.client.ServerRefusedConnectionException: inet_addr hostname>:28307 refused connection: A previous connection
> attempt from this client is still being processed:
> identity(172.17.0.8(381:loner):47756:85080f57,connection=1
> {noformat}
> Results viewable at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-build.198/test-results/distributedTest/1543356956/
> Artifacts available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-build.198/test-artifacts/1543356956/distributedtestfiles-OpenJDK8-1.9.0-build.198.tgz
> Possibly related to GEODE-5595 per the comment by Ken Howe, insofar as his
> comment also includes the same suspect string. Also quite possibly
> unrelated. You, dear reader, can find out!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6198) Manage dependencies via BOM
[ https://issues.apache.org/jira/browse/GEODE-6198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg resolved GEODE-6198. - Resolution: Fixed > Manage dependencies via BOM > --- > > Key: GEODE-6198 > URL: https://issues.apache.org/jira/browse/GEODE-6198 > Project: Geode > Issue Type: Improvement >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5365) A no-arg ClusterStartupRule constructor encourages bad developer practice
[ https://issues.apache.org/jira/browse/GEODE-5365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg resolved GEODE-5365. - Resolution: Won't Fix > A no-arg ClusterStartupRule constructor encourages bad developer practice > - > > Key: GEODE-5365 > URL: https://issues.apache.org/jira/browse/GEODE-5365 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > > Many tests currently spin up more VMs than the test actually requires. This > is typically due to the ClusterStartupRule being instantiated using the > no-arg constructor. > Using four VMs by default may have once been convenient, but it encourages a > laissez faire attitude in test development. A developer should give due > thought to the number of VMs a test needs to instantiate. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5032) Massage Configuration Objects for Better Intuition.
[ https://issues.apache.org/jira/browse/GEODE-5032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg resolved GEODE-5032. - Resolution: Fixed > Massage Configuration Objects for Better Intuition. > --- > > Key: GEODE-5032 > URL: https://issues.apache.org/jira/browse/GEODE-5032 > Project: Geode > Issue Type: Sub-task > Components: configuration >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Time Spent: 3h 40m > Remaining Estimate: 0h > > For instance, various port fields are declared as Strings where an Integer > makes more sense. This is true for many "count" fields as well. > These may be best resolved via a JAXB bindings file and regenerating the > POJOs from scratch. Additionally if all the minor adjustments that have been > already made (removing the xsd:choice and manually enforcing it, having each > item implement CacheElement and have a getId() method) can also be resolved > via a bindings file, then the POJOs could be removed from the git tree and > generated during the build step, if desired. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6170) Create scripts for launching benchmarks in AWS
[ https://issues.apache.org/jira/browse/GEODE-6170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-6170. -- Resolution: Fixed Fix Version/s: 1.9.0 > Create scripts for launching benchmarks in AWS > -- > > Key: GEODE-6170 > URL: https://issues.apache.org/jira/browse/GEODE-6170 > Project: Geode > Issue Type: Improvement > Components: benchmarks >Reporter: Dan Smith >Assignee: Sean Goller >Priority: Major > Fix For: 1.9.0 > > > We have scripts for launching benchmarks in GCP in the geode-benchmarks repo > under infrastructure/google_cloud. We should create scripts to launch > benchmarks in AWS. > These scripts should mirror the google cloud scripts for launching and > destroying clusters. We should refactor out common logic for running tests > and copying results back. > When we launch instances in AWS, we want to use > * Dedicated instances > * Create a new cluster placement group for our nodes and launch them > simultaneously in that group. See > https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html > * Use an instance size that will give us a dedicated 10Gbit pipe in that > group. c5.9xlarge seems like a good option - see the AWS launch instance > wizard for other options say they gaurantee 10 Gbits/sec if placed into a > placement group. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6135) Add benchmarks to geode CI
[ https://issues.apache.org/jira/browse/GEODE-6135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith reassigned GEODE-6135: Assignee: Sean Goller > Add benchmarks to geode CI > -- > > Key: GEODE-6135 > URL: https://issues.apache.org/jira/browse/GEODE-6135 > Project: Geode > Issue Type: Improvement > Components: benchmarks >Reporter: Dan Smith >Assignee: Sean Goller >Priority: Major > > Add a job to run the benchmarks to https://concourse.apachegeode-ci.info. > Initially this job doesn't need to be on the main tab, it can just output a > comparison of the current develop against a baseline revision of geode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5366) DUnitLauncher does not respect the number of VMs requested in ClusterStartupRule
[
https://issues.apache.org/jira/browse/GEODE-5366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg resolved GEODE-5366.
-
Resolution: Won't Fix
> DUnitLauncher does not respect the number of VMs requested in
> ClusterStartupRule
>
>
> Key: GEODE-5366
> URL: https://issues.apache.org/jira/browse/GEODE-5366
> Project: Geode
> Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
>
> The ClusterStartupRule has the method
> {noformat}
> @Override
> protected void before() throws Throwable {
> DUnitLauncher.launchIfNeeded();
> for (int i = 0; i < vmCount; i++) {
> Host.getHost(0).getVM(i);
> }
> restoreSystemProperties.before();
> occupiedVMs = new HashMap<>();
> }
> {noformat}
> By calling the no-arg {{launchIfNeeded}}, the number of requested VMs is not
> properly passed to the DUnitLauncher. This is not a problem if vmCount > 4,
> since the following loop will instantiate any extra VMs. However, if fewer
> than 4 VMs are requested, the DUnitLauncher will still spin up extra VMs,
> wasting cycles.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-1520) Swagger UI can appear broken depending on the URL used
[
https://issues.apache.org/jira/browse/GEODE-1520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joey McAllister resolved GEODE-1520.
Resolution: Done
It looks like this was fixed in 2017 as part of another effort.
> Swagger UI can appear broken depending on the URL used
> --
>
> Key: GEODE-1520
> URL: https://issues.apache.org/jira/browse/GEODE-1520
> Project: Geode
> Issue Type: Improvement
> Components: docs, rest (dev)
>Reporter: Jens Deppe
>Priority: Major
> Labels: bug-hunt
>
> I'm playing with the Swagger UI and followed the docs here:
> http://gemfire.docs.pivotal.io/docs-gemfire/latest/rest_apps/using_swagger.html
> Specifically I set {{--J=-Dgemfire.http-service-bind-address=localhost}}.
> However, browsing to http://127.0.0.1:8080/gemfire-api/docs/index.html shows
> me a minor error on the page {{Unable to read api 'region' from path
> http://localhost:8080/gemfire-api/api-docs/gemfireApi/region (server returned
> undefined)}} and I cannot interact with it.
> Looking at the browser console I see this error: {{No
> 'Access-Control-Allow-Origin' header is present on the requested resource.}}.
> It turns out you *MUST* use the same, literal value in the URL that you used
> for bind address. If you used an IP then your URL must also use an IP.
> This should be documented and/or fixed if possible.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6218) Improve hashing performance on utf-8 string.
Jacob S. Barrett created GEODE-6218: --- Summary: Improve hashing performance on utf-8 string. Key: GEODE-6218 URL: https://issues.apache.org/jira/browse/GEODE-6218 Project: Geode Issue Type: Improvement Components: native client Reporter: Jacob S. Barrett -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6219) NetstatDUnitTest is not not detecting failures in executing OS netstat command
[
https://issues.apache.org/jira/browse/GEODE-6219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe reassigned GEODE-6219:
---
Assignee: Kenneth Howe
> NetstatDUnitTest is not not detecting failures in executing OS netstat command
> --
>
> Key: GEODE-6219
> URL: https://issues.apache.org/jira/browse/GEODE-6219
> Project: Geode
> Issue Type: Bug
> Components: ci, gfsh, tests
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
>Priority: Major
>
> The tests in {{NetstatDUnitTest}} are all passing in CI. However, the logs
> show that the OS command that is run on the servers in the cluster is failing:
> {code}
> Command result for --file=/tmp/junit5019199898297364101/junit8715261921376128635/command.log.txt>:
>
> Saved netstat output in the file
> /tmp/junit5019199898297364101/junit8715261921376128635/command.log.txt.
> Command result for :
> ##
> Host: 1dcb8055baac
> OS: Linux 4.9.0-8-amd64 amd64
> Member(s):
> server-1, locator-0, server-2
> ##
> Could not execute "netstat". Reason: Cannot run program "netstat": error=2,
> No such file or directory
> {code}
> That {{netstat}} is missing from the CI test workers is being addressed in
> PR#3014.
> The {{netstat}} tests need to verify the the OS commands run, in addition to
> verifying that the gfsh command tried to run on the expected servers.
> Suggest adding a check such as:
> {code}
> @@ -168,20 +187,24 @@ public class NetstatDUnitTest {
>@Test
>public void testConnectToLocatorWithLargeCommandResponse() throws
> Exception {
> gfsh.connect(server0.getEmbeddedLocatorPort(),
> GfshCommandRule.PortType.locator);
> -gfsh.executeAndAssertThat(netStatLsofCommand).statusIsSuccess();
> +gfsh.executeAndAssertThat(netStatLsofCommand).statusIsSuccess()
> +.doesNotContainOutput("Could not execute");
>}
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6219) NetstatDUnitTest is not not detecting failures in executing OS netstat command
Kenneth Howe created GEODE-6219:
---
Summary: NetstatDUnitTest is not not detecting failures in
executing OS netstat command
Key: GEODE-6219
URL: https://issues.apache.org/jira/browse/GEODE-6219
Project: Geode
Issue Type: Bug
Components: ci, gfsh, tests
Reporter: Kenneth Howe
The tests in {{NetstatDUnitTest}} are all passing in CI. However, the logs show
that the OS command that is run on the servers in the cluster is failing:
{code}
Command result for :
Saved netstat output in the file
/tmp/junit5019199898297364101/junit8715261921376128635/command.log.txt.
Command result for :
##
Host: 1dcb8055baac
OS: Linux 4.9.0-8-amd64 amd64
Member(s):
server-1, locator-0, server-2
##
Could not execute "netstat". Reason: Cannot run program "netstat": error=2, No
such file or directory
{code}
That {{netstat}} is missing from the CI test workers is being addressed in
PR#3014.
The {{netstat}} tests need to verify the the OS commands run, in addition to
verifying that the gfsh command tried to run on the expected servers.
Suggest adding a check such as:
{code}
@@ -168,20 +187,24 @@ public class NetstatDUnitTest {
@Test
public void testConnectToLocatorWithLargeCommandResponse() throws Exception {
gfsh.connect(server0.getEmbeddedLocatorPort(),
GfshCommandRule.PortType.locator);
-gfsh.executeAndAssertThat(netStatLsofCommand).statusIsSuccess();
+gfsh.executeAndAssertThat(netStatLsofCommand).statusIsSuccess()
+.doesNotContainOutput("Could not execute");
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6219) NetstatDUnitTest is not not detecting failures in executing OS netstat command
[
https://issues.apache.org/jira/browse/GEODE-6219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe updated GEODE-6219:
Affects Version/s: 1.7.0
> NetstatDUnitTest is not not detecting failures in executing OS netstat command
> --
>
> Key: GEODE-6219
> URL: https://issues.apache.org/jira/browse/GEODE-6219
> Project: Geode
> Issue Type: Bug
> Components: ci, gfsh, tests
>Affects Versions: 1.7.0
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
>Priority: Major
>
> The tests in {{NetstatDUnitTest}} are all passing in CI. However, the logs
> show that the OS command that is run on the servers in the cluster is failing:
> {code}
> Command result for --file=/tmp/junit5019199898297364101/junit8715261921376128635/command.log.txt>:
>
> Saved netstat output in the file
> /tmp/junit5019199898297364101/junit8715261921376128635/command.log.txt.
> Command result for :
> ##
> Host: 1dcb8055baac
> OS: Linux 4.9.0-8-amd64 amd64
> Member(s):
> server-1, locator-0, server-2
> ##
> Could not execute "netstat". Reason: Cannot run program "netstat": error=2,
> No such file or directory
> {code}
> That {{netstat}} is missing from the CI test workers is being addressed in
> PR#3014.
> The {{netstat}} tests need to verify the the OS commands run, in addition to
> verifying that the gfsh command tried to run on the expected servers.
> Suggest adding a check such as:
> {code}
> @@ -168,20 +187,24 @@ public class NetstatDUnitTest {
>@Test
>public void testConnectToLocatorWithLargeCommandResponse() throws
> Exception {
> gfsh.connect(server0.getEmbeddedLocatorPort(),
> GfshCommandRule.PortType.locator);
> -gfsh.executeAndAssertThat(netStatLsofCommand).statusIsSuccess();
> +gfsh.executeAndAssertThat(netStatLsofCommand).statusIsSuccess()
> +.doesNotContainOutput("Could not execute");
>}
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-4811) Add a @Disabled annotation to various endpoints to facilitate feature-flagging.
[
https://issues.apache.org/jira/browse/GEODE-4811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg reassigned GEODE-4811:
---
Assignee: (was: Patrick Rhomberg)
> Add a @Disabled annotation to various endpoints to facilitate
> feature-flagging.
> ---
>
> Key: GEODE-4811
> URL: https://issues.apache.org/jira/browse/GEODE-4811
> Project: Geode
> Issue Type: New Feature
> Components: gfsh
>Reporter: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Many gfsh commands are mutually required by each other for full
> functionality. For instance, {{destroy jndi-binding}} is meaningless without
> the {{create jndi-binding}} command.
> As a developer, I would like to be able to coordinate release of multiple
> related commands at once, across multiple commits. A {{@FeatureFlag}}
> annotation on gfsh command classes would be extremely useful.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6216) add netstat to test environment
[ https://issues.apache.org/jira/browse/GEODE-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16724349#comment-16724349 ] ASF subversion and git services commented on GEODE-6216: Commit f2e8db7a6199aca7314ad8051d7337bf641c0c89 in geode's branch refs/heads/develop from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f2e8db7 ] GEODE-6216 add netstat to images for NetstatDUnitTest (#3014) > add netstat to test environment > --- > > Key: GEODE-6216 > URL: https://issues.apache.org/jira/browse/GEODE-6216 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > tests such as > geode-core/src/distributedTest/java/org/apache/geode/management/internal/cli/NetstatDUnitTest.java > expect netstat utility to be available, but current images do not include it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6219) NetstatDUnitTest is not not detecting failures in executing OS netstat command
[
https://issues.apache.org/jira/browse/GEODE-6219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-6219:
--
Labels: pull-request-available (was: )
> NetstatDUnitTest is not not detecting failures in executing OS netstat command
> --
>
> Key: GEODE-6219
> URL: https://issues.apache.org/jira/browse/GEODE-6219
> Project: Geode
> Issue Type: Bug
> Components: ci, gfsh, tests
>Affects Versions: 1.7.0
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
>Priority: Major
> Labels: pull-request-available
>
> The tests in {{NetstatDUnitTest}} are all passing in CI. However, the logs
> show that the OS command that is run on the servers in the cluster is failing:
> {code}
> Command result for --file=/tmp/junit5019199898297364101/junit8715261921376128635/command.log.txt>:
>
> Saved netstat output in the file
> /tmp/junit5019199898297364101/junit8715261921376128635/command.log.txt.
> Command result for :
> ##
> Host: 1dcb8055baac
> OS: Linux 4.9.0-8-amd64 amd64
> Member(s):
> server-1, locator-0, server-2
> ##
> Could not execute "netstat". Reason: Cannot run program "netstat": error=2,
> No such file or directory
> {code}
> That {{netstat}} is missing from the CI test workers is being addressed in
> PR#3014.
> The {{netstat}} tests need to verify the the OS commands run, in addition to
> verifying that the gfsh command tried to run on the expected servers.
> Suggest adding a check such as:
> {code}
> @@ -168,20 +187,24 @@ public class NetstatDUnitTest {
>@Test
>public void testConnectToLocatorWithLargeCommandResponse() throws
> Exception {
> gfsh.connect(server0.getEmbeddedLocatorPort(),
> GfshCommandRule.PortType.locator);
> -gfsh.executeAndAssertThat(netStatLsofCommand).statusIsSuccess();
> +gfsh.executeAndAssertThat(netStatLsofCommand).statusIsSuccess()
> +.doesNotContainOutput("Could not execute");
>}
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6218) Improve hashing performance on utf-8 string.
[
https://issues.apache.org/jira/browse/GEODE-6218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-6218:
--
Labels: pull-request-available (was: )
> Improve hashing performance on utf-8 string.
>
>
> Key: GEODE-6218
> URL: https://issues.apache.org/jira/browse/GEODE-6218
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Jacob S. Barrett
>Priority: Major
> Labels: pull-request-available
>
> UTF-8 {{std::string}} is converted to UTF-16 {{std::u16string}} before
> hashing to produce a has consistent with the server in Java. Avoid the
> complete conversion to UTF-16 when hashing UTF-8 strings.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6186) Reduce the number of EntryNotFoundExceptions during AsyncEventQueue batch processing with conflation enabled
[
https://issues.apache.org/jira/browse/GEODE-6186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16724414#comment-16724414
]
ASF subversion and git services commented on GEODE-6186:
Commit ebde19f7e1a5839331161976b70c022a595be25c in geode's branch
refs/heads/develop from Barry Oglesby
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ebde19f ]
GEODE-6186: Reduced the number of EntryNotFoundExceptions thrown during wan
conflation
> Reduce the number of EntryNotFoundExceptions during AsyncEventQueue batch
> processing with conflation enabled
>
>
> Key: GEODE-6186
> URL: https://issues.apache.org/jira/browse/GEODE-6186
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barry Oglesby
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Reduce the number of EntryNotFoundExceptions during AsyncEventQueue batch
> processing with conflation enabled
> This test:
> 3000 iterations of putAlls with the same 1500 keys into a partitioned region
> attached to async-event-queue:
> dispatcher-threads="1" parallel="true" enable-batch-conflation="true">
> Produces these numbers in the current code (4 different runs):
> {noformat}
> numBatches=645; numENFEs=8622196; totalPeekTime=178517; averagePeekTime=276;
> totalProcessBatchTime=38936; averageProcessBatchTime=60
> numBatches=660; numENFEs=8467986; totalPeekTime=182985; averagePeekTime=277;
> totalProcessBatchTime=34335; averageProcessBatchTime=52
> numBatches=646; numENFEs=8563364; totalPeekTime=179624; averagePeekTime=278;
> totalProcessBatchTime=37342; averageProcessBatchTime=57
> numBatches=632; numENFEs=8716942; totalPeekTime=175570; averagePeekTime=277;
> totalProcessBatchTime=39732; averageProcessBatchTime=62
> {noformat}
> After some changes mainly in BucketRegionQueue:
> {noformat}
> numBatches=782; numENFEs=3621039; totalPeekTime=195760; averagePeekTime=250;
> totalProcessBatchTime=18724; averageProcessBatchTime=23
> numBatches=791; numENFEs=3604933; totalPeekTime=197980; averagePeekTime=250;
> totalProcessBatchTime=18587; averageProcessBatchTime=23
> numBatches=790; numENFEs=3600038; totalPeekTime=197774; averagePeekTime=250;
> totalProcessBatchTime=18611; averageProcessBatchTime=23
> numBatches=795; numENFEs=3584490; totalPeekTime=199060; averagePeekTime=250;
> totalProcessBatchTime=18063; averageProcessBatchTime=22
> {noformat}
> numBatches is the number of batches peeked
> numENFEs is the number of EntryNotFoundExceptions thrown
> totalPeekTime is the total time to peek all batches
> averagePeekTime is the average time to peek a batch
> totalProcessBatchTime is the total time to process all batches
> averageProcessBatchTime is the average time to process a batch (includes
> listener callback and remove from queue)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6220) Registering Interest on a key, causes the local entry to be invalidated/destroyed
Udo Kohlmeyer created GEODE-6220:
Summary: Registering Interest on a key, causes the local entry to
be invalidated/destroyed
Key: GEODE-6220
URL: https://issues.apache.org/jira/browse/GEODE-6220
Project: Geode
Issue Type: Bug
Components: client/server, regions
Reporter: Udo Kohlmeyer
Using client:
{code:java}
fun main(args: Array) {
val cache = ClientCacheFactory()
.addPoolLocator("localhost", 10334)
.setPoolSubscriptionEnabled(true)
.setPoolSubscriptionRedundancy(0)
.create()
cache.copyOnRead = false
val regionFactory = cache.createClientRegionFactory(ClientRegionShortcut.CACHING_PROXY)
regionFactory.addCacheListener(RegisterInterestCacheListener())
val region = regionFactory.create("TestRegion")
val testObject = TestObject("line1", "line2")
region["key1"] = testObject
println("Contains key locally: ${region.containsKey("key1")} and contains
key on server: ${region.containsKeyOnServer("key1")}")
val testObjectFromCache = region["key1"]
while (testObjectFromCache === region["key1"]) {
Thread.sleep(1000)
println(System.identityHashCode(region["key1"]))
}
println("BROKEN")
}
class RegisterInterestCacheListener : CacheListenerAdapter() {
override fun afterCreate(event: EntryEvent) {
Thread().run { event.region.registerInterest(event.key,
InterestResultPolicy.NONE,false,true)}
}
override fun afterUpdate(event: EntryEvent) {
println("UPDATED: ${event.newValue}")
}
override fun afterInvalidate(event: EntryEvent) {
println("Invalidated: ${event.newValue}")
}
override fun afterDestroy(event: EntryEvent) {
println("Destroy: ${event.newValue}")
}
}
{code}
with server:
{code}
fun main(args: Array) {
val cache = CacheFactory()
.set("start-locator", "localhost[10334]")
.set("mcast-port", "0")
.create()
cache.addCacheServer()?.also{
it.port = 0
it.bindAddress = "localhost"}!!.start()
val region = cache.createRegionFactory(RegionShortcut.REPLICATE).create("TestRegion")
while(true)
{
Thread.sleep(5000)
}
}
{code}
When registering interest on a key, with `InterestResultPolicy` of `NONE`
causes the interest registration to invalidate the local copy of the client.
According to the documentation, `NONE` should just enable/disable the bulk
loading of data from the server when registering interest, NOT invalidate the
data on the client.
in the docs under *Client Interest Registration on the Server* #3 calls out
that `NONE` disables the bulk loading of data from the server
https://geode.apache.org/docs/guide/18/developing/events/how_client_server_distribution_works.html
The javadoc for the class is vague and not helpful
https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/InterestResultPolicy.html
and the `Region Interface` specifies the following:
https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/Region.html#registerInterest-K-org.apache.geode.cache.InterestResultPolicy-boolean-boolean-
{noformat}
policy - The interest result policy. This can be one of:
*InterestResultPolicy.NONE - does not initialize the local cache**
InterestResultPolicy.KEYS - initializes the local cache with the keys
satisfying the request
InterestResultPolicy.KEYS_VALUES - initializes the local cache with the keys
and current values satisfying the request
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6220) Registering Interest on a key, causes the local entry to be invalidated/destroyed
[
https://issues.apache.org/jira/browse/GEODE-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-6220:
-
Affects Version/s: 1.1.0
1.1.1
1.2.0
1.3.0
1.2.1
1.4.0
1.5.0
1.6.0
1.7.0
1.8.0
> Registering Interest on a key, causes the local entry to be
> invalidated/destroyed
> -
>
> Key: GEODE-6220
> URL: https://issues.apache.org/jira/browse/GEODE-6220
> Project: Geode
> Issue Type: Bug
> Components: client/server, regions
>Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1, 1.4.0, 1.5.0, 1.6.0,
> 1.7.0, 1.8.0
>Reporter: Udo Kohlmeyer
>Priority: Major
>
> Using client:
> {code:java}
> fun main(args: Array) {
> val cache = ClientCacheFactory()
> .addPoolLocator("localhost", 10334)
> .setPoolSubscriptionEnabled(true)
> .setPoolSubscriptionRedundancy(0)
> .create()
> cache.copyOnRead = false
> val regionFactory = cache.createClientRegionFactory TestObject>(ClientRegionShortcut.CACHING_PROXY)
> regionFactory.addCacheListener(RegisterInterestCacheListener())
> val region = regionFactory.create("TestRegion")
> val testObject = TestObject("line1", "line2")
> region["key1"] = testObject
> println("Contains key locally: ${region.containsKey("key1")} and contains
> key on server: ${region.containsKeyOnServer("key1")}")
> val testObjectFromCache = region["key1"]
> while (testObjectFromCache === region["key1"]) {
> Thread.sleep(1000)
> println(System.identityHashCode(region["key1"]))
> }
> println("BROKEN")
> }
> class RegisterInterestCacheListener : CacheListenerAdapter TestObject>() {
> override fun afterCreate(event: EntryEvent) {
> Thread().run { event.region.registerInterest(event.key,
> InterestResultPolicy.NONE,false,true)}
> }
> override fun afterUpdate(event: EntryEvent) {
> println("UPDATED: ${event.newValue}")
> }
> override fun afterInvalidate(event: EntryEvent) {
> println("Invalidated: ${event.newValue}")
> }
> override fun afterDestroy(event: EntryEvent) {
> println("Destroy: ${event.newValue}")
> }
> }
> {code}
> with server:
> {code}
> fun main(args: Array) {
> val cache = CacheFactory()
> .set("start-locator", "localhost[10334]")
> .set("mcast-port", "0")
> .create()
> cache.addCacheServer()?.also{
> it.port = 0
> it.bindAddress = "localhost"}!!.start()
> val region = cache.createRegionFactory TestObject>(RegionShortcut.REPLICATE).create("TestRegion")
> while(true)
> {
> Thread.sleep(5000)
> }
> }
> {code}
> When registering interest on a key, with `InterestResultPolicy` of `NONE`
> causes the interest registration to invalidate the local copy of the client.
> According to the documentation, `NONE` should just enable/disable the bulk
> loading of data from the server when registering interest, NOT invalidate the
> data on the client.
> in the docs under *Client Interest Registration on the Server* #3 calls out
> that `NONE` disables the bulk loading of data from the server
> https://geode.apache.org/docs/guide/18/developing/events/how_client_server_distribution_works.html
> The javadoc for the class is vague and not helpful
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/InterestResultPolicy.html
> and the `Region Interface` specifies the following:
> https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/Region.html#registerInterest-K-org.apache.geode.cache.InterestResultPolicy-boolean-boolean-
> {noformat}
> policy - The interest result policy. This can be one of:
> *InterestResultPolicy.NONE - does not initialize the local cache**
> InterestResultPolicy.KEYS - initializes the local cache with the keys
> satisfying the request
> InterestResultPolicy.KEYS_VALUES - initializes the local cache with the keys
> and current values satisfying the request
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6220) Registering Interest on a key, causes the local entry to be invalidated/destroyed
[
https://issues.apache.org/jira/browse/GEODE-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-6220:
-
Description:
Using client:
{code:java}
fun main(args: Array) {
val cache = ClientCacheFactory()
.addPoolLocator("localhost", 10334)
.setPoolSubscriptionEnabled(true)
.setPoolSubscriptionRedundancy(0)
.create()
cache.copyOnRead = false
val regionFactory = cache.createClientRegionFactory(ClientRegionShortcut.CACHING_PROXY)
regionFactory.addCacheListener(RegisterInterestCacheListener())
val region = regionFactory.create("TestRegion")
val testObject = TestObject("line1", "line2")
region["key1"] = testObject
println("Contains key locally: ${region.containsKey("key1")} and contains
key on server: ${region.containsKeyOnServer("key1")}")
val testObjectFromCache = region["key1"]
while (testObjectFromCache === region["key1"]) {
Thread.sleep(1000)
println(System.identityHashCode(region["key1"]))
}
println("BROKEN")
}
class RegisterInterestCacheListener : CacheListenerAdapter() {
override fun afterCreate(event: EntryEvent) {
Thread().run { event.region.registerInterest(event.key,
InterestResultPolicy.NONE,false,true)}
}
override fun afterUpdate(event: EntryEvent) {
println("UPDATED: ${event.newValue}")
}
override fun afterInvalidate(event: EntryEvent) {
println("Invalidated: ${event.newValue}")
}
override fun afterDestroy(event: EntryEvent) {
println("Destroy: ${event.newValue}")
}
}
{code}
with server:
{code}
fun main(args: Array) {
val cache = CacheFactory()
.set("start-locator", "localhost[10334]")
.set("mcast-port", "0")
.create()
cache.addCacheServer()?.also{
it.port = 0
it.bindAddress = "localhost"}!!.start()
val region = cache.createRegionFactory(RegionShortcut.REPLICATE).create("TestRegion")
while(true)
{
Thread.sleep(5000)
}
}
{code}
When registering interest on a key, with `InterestResultPolicy` of `NONE`
causes the interest registration to invalidate the local copy of the client.
According to the documentation, `NONE` should just enable/disable the bulk
loading of data from the server when registering interest, NOT invalidate the
data on the client.
in the docs under *Client Interest Registration on the Server* #3 calls out
that `NONE` disables the bulk loading of data from the server
https://geode.apache.org/docs/guide/18/developing/events/how_client_server_distribution_works.html
The javadoc for the class is vague and not helpful
https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/InterestResultPolicy.html
and the `Region Interface` specifies the following:
https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/Region.html#registerInterest-K-org.apache.geode.cache.InterestResultPolicy-boolean-boolean-
{noformat}
policy - The interest result policy. This can be one of:
*InterestResultPolicy.NONE - does not initialize the local cache**
InterestResultPolicy.KEYS - initializes the local cache with the keys
satisfying the request
InterestResultPolicy.KEYS_VALUES - initializes the local cache with the keys
and current values satisfying the request
{noformat}
The Expectation is that that the client gets stuck in loop printing out the
identity hashcode, because the local client entry is never updated and does not
receive any data from the servers.
{code}
val testObjectFromCache = region["key1"]
while (testObjectFromCache === region["key1"]) {
Thread.sleep(1000)
println(System.identityHashCode(region["key1"]))
}
{code}
was:
Using client:
{code:java}
fun main(args: Array) {
val cache = ClientCacheFactory()
.addPoolLocator("localhost", 10334)
.setPoolSubscriptionEnabled(true)
.setPoolSubscriptionRedundancy(0)
.create()
cache.copyOnRead = false
val regionFactory = cache.createClientRegionFactory(ClientRegionShortcut.CACHING_PROXY)
regionFactory.addCacheListener(RegisterInterestCacheListener())
val region = regionFactory.create("TestRegion")
val testObject = TestObject("line1", "line2")
region["key1"] = testObject
println("Contains key locally: ${region.containsKey("key1")} and contains
key on server: ${region.containsKeyOnServer("key1")}")
val testObjectFromCache = region["key1"]
while (testObjectFromCache === region["key1"]) {
Thread.sleep(1000)
println(System.identityHashCode(region["key1"]))
}
println("BROKEN")
}
class RegisterInterestCacheListener : CacheListenerAdapter() {
override fun afterCreate(event: EntryEvent) {
Thread().run { event.region.registerInterest(event.key,
InterestResultPolicy.NONE,false,true)}
}
override fun afterUpdate(event: EntryEvent) {
[jira] [Updated] (GEODE-6220) Registering Interest on a key, causes the local entry to be invalidated/destroyed
[
https://issues.apache.org/jira/browse/GEODE-6220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-6220:
-
Description:
Using client:
{code:java}
fun main(args: Array) {
val cache = ClientCacheFactory()
.addPoolLocator("localhost", 10334)
.setPoolSubscriptionEnabled(true)
.setPoolSubscriptionRedundancy(0)
.create()
cache.copyOnRead = false
val regionFactory = cache.createClientRegionFactory(ClientRegionShortcut.CACHING_PROXY)
regionFactory.addCacheListener(RegisterInterestCacheListener())
val region = regionFactory.create("TestRegion")
val testObject = TestObject("line1", "line2")
region["key1"] = testObject
println("Contains key locally: ${region.containsKey("key1")} and contains
key on server: ${region.containsKeyOnServer("key1")}")
val testObjectFromCache = region["key1"]
while (testObjectFromCache === region["key1"]) {
Thread.sleep(1000)
println(System.identityHashCode(region["key1"]))
}
println("BROKEN")
}
class RegisterInterestCacheListener : CacheListenerAdapter() {
override fun afterCreate(event: EntryEvent) {
Thread().run { event.region.registerInterest(event.key,
InterestResultPolicy.NONE,false,true)}
}
override fun afterUpdate(event: EntryEvent) {
println("UPDATED: ${event.newValue}")
}
override fun afterInvalidate(event: EntryEvent) {
println("Invalidated: ${event.newValue}")
}
override fun afterDestroy(event: EntryEvent) {
println("Destroy: ${event.newValue}")
}
}
{code}
with server:
{code}
fun main(args: Array) {
val cache = CacheFactory()
.set("start-locator", "localhost[10334]")
.set("mcast-port", "0")
.create()
cache.addCacheServer()?.also{
it.port = 0
it.bindAddress = "localhost"}!!.start()
val region = cache.createRegionFactory(RegionShortcut.REPLICATE).create("TestRegion")
while(true)
{
Thread.sleep(5000)
}
}
{code}
When registering interest on a key, with `InterestResultPolicy` of `NONE`
causes the interest registration to invalidate the local copy of the client.
According to the documentation, `NONE` should just enable/disable the bulk
loading of data from the server when registering interest, NOT invalidate the
data on the client.
in the docs under *Client Interest Registration on the Server* #3 calls out
that `NONE` disables the bulk loading of data from the server
https://geode.apache.org/docs/guide/18/developing/events/how_client_server_distribution_works.html
The javadoc for the class is vague and not helpful
https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/InterestResultPolicy.html
and the `Region Interface` specifies the following:
https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/Region.html#registerInterest-K-org.apache.geode.cache.InterestResultPolicy-boolean-boolean-
{noformat}
policy - The interest result policy. This can be one of:
*InterestResultPolicy.NONE - does not initialize the local cache**
InterestResultPolicy.KEYS - initializes the local cache with the keys
satisfying the request
InterestResultPolicy.KEYS_VALUES - initializes the local cache with the keys
and current values satisfying the request
{noformat}
The *EXPECTATION* is that that the client gets stuck in loop printing out the
identity hashcode, because the local client entry is never updated and does not
receive any data from the servers.
{code}
val testObjectFromCache = region["key1"]
while (testObjectFromCache === region["key1"]) {
Thread.sleep(1000)
println(System.identityHashCode(region["key1"]))
}
{code}
was:
Using client:
{code:java}
fun main(args: Array) {
val cache = ClientCacheFactory()
.addPoolLocator("localhost", 10334)
.setPoolSubscriptionEnabled(true)
.setPoolSubscriptionRedundancy(0)
.create()
cache.copyOnRead = false
val regionFactory = cache.createClientRegionFactory(ClientRegionShortcut.CACHING_PROXY)
regionFactory.addCacheListener(RegisterInterestCacheListener())
val region = regionFactory.create("TestRegion")
val testObject = TestObject("line1", "line2")
region["key1"] = testObject
println("Contains key locally: ${region.containsKey("key1")} and contains
key on server: ${region.containsKeyOnServer("key1")}")
val testObjectFromCache = region["key1"]
while (testObjectFromCache === region["key1"]) {
Thread.sleep(1000)
println(System.identityHashCode(region["key1"]))
}
println("BROKEN")
}
class RegisterInterestCacheListener : CacheListenerAdapter() {
override fun afterCreate(event: EntryEvent) {
Thread().run { event.region.registerInterest(event.key,
InterestResultPolicy.NONE,false,true)}
}
override fun afterUpdate(event: EntryEvent) {
[jira] [Created] (GEODE-6221) CI Failure: LocatorConnectionDUnitTest.testInvalidOperationReturnsFailure statistics verification failed for bytesSent
Kenneth Howe created GEODE-6221: --- Summary: CI Failure: LocatorConnectionDUnitTest.testInvalidOperationReturnsFailure statistics verification failed for bytesSent Key: GEODE-6221 URL: https://issues.apache.org/jira/browse/GEODE-6221 Project: Geode Issue Type: Bug Reporter: Kenneth Howe Test failure found in [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/253] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6221) CI Failure: LocatorConnectionDUnitTest.testInvalidOperationReturnsFailure statistics verification failed for bytesSent
[ https://issues.apache.org/jira/browse/GEODE-6221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenneth Howe updated GEODE-6221: Affects Version/s: 1.9.0 Description: Seen in the most recent CI run, so don't know if this is a nee consistent failure or some previously unseen flaky failure. Test failure found in [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/253] was: Test failure found in [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/253] > CI Failure: LocatorConnectionDUnitTest.testInvalidOperationReturnsFailure > statistics verification failed for bytesSent > -- > > Key: GEODE-6221 > URL: https://issues.apache.org/jira/browse/GEODE-6221 > Project: Geode > Issue Type: Bug >Affects Versions: 1.9.0 >Reporter: Kenneth Howe >Priority: Major > > Seen in the most recent CI run, so don't know if this is a nee consistent > failure or some previously unseen flaky failure. > Test failure found in > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/253] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6222) CI Failure: GemFireDeadlockDetectorDUnitTest
Kenneth Howe created GEODE-6222:
---
Summary: CI Failure: GemFireDeadlockDetectorDUnitTest
Key: GEODE-6222
URL: https://issues.apache.org/jira/browse/GEODE-6222
Project: Geode
Issue Type: Bug
Components: distributed lock service
Reporter: Kenneth Howe
Flaky test failure in
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/247]
{code:java}
org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest
> testDistributedDeadlockWithDLock FAILED
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at
org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock(GemFireDeadlockDetectorDUnitTest.java:199)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6222) CI Failure: GemFireDeadlockDetectorDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe updated GEODE-6222:
Affects Version/s: 1.9.0
> CI Failure: GemFireDeadlockDetectorDUnitTest
>
>
> Key: GEODE-6222
> URL: https://issues.apache.org/jira/browse/GEODE-6222
> Project: Geode
> Issue Type: Bug
> Components: distributed lock service
>Affects Versions: 1.9.0
>Reporter: Kenneth Howe
>Priority: Major
>
> Flaky test failure in
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/247]
> {code:java}
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest
> > testDistributedDeadlockWithDLock FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock(GemFireDeadlockDetectorDUnitTest.java:199)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6143) PowerMock should not be used in Geode tests
[
https://issues.apache.org/jira/browse/GEODE-6143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16724566#comment-16724566
]
ASF subversion and git services commented on GEODE-6143:
Commit e26a1e5244981c20abc1e2b4436770112a921c9b in geode's branch
refs/heads/feature/GEODE-6143-10 from zhouxh
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=e26a1e5 ]
GEODE-6143: remove PowerMock from import
> PowerMock should not be used in Geode tests
> ---
>
> Key: GEODE-6143
> URL: https://issues.apache.org/jira/browse/GEODE-6143
> Project: Geode
> Issue Type: Bug
> Components: build, tests
>Reporter: Kirk Lund
>Assignee: Ryan McMahon
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10h 50m
> Remaining Estimate: 0h
>
> At least one usage of PowerMock in our unit tests is leaking and causing
> other tests to fail with the following stack.
> No further tests should be written using PowerMock and all tests that
> currently use it need to be identified and changed (along with product code
> refactoring) to not use PowerMock.
> We will then remove PowerMock as a dependency from Geode.
> {noformat}
> 2018-12-04 18:11:36,258 Distributed system shutdown hook ERROR Could not
> reconfigure JMX java.lang.LinkageError: loader constraint violation: loader
> (instance of org/powermock/core/classloader/MockClassLoader) previously
> initiated loading for a different type with name
> "javax/management/MBeanServer"
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
> at
> org.powermock.core.classloader.MockClassLoader.loadUnmockedClass(MockClassLoader.java:262)
> at
> org.powermock.core.classloader.MockClassLoader.loadModifiedClass(MockClassLoader.java:206)
> at
> org.powermock.core.classloader.DeferSupportingClassLoader.loadClass1(DeferSupportingClassLoader.java:89)
> at
> org.powermock.core.classloader.DeferSupportingClassLoader.loadClass(DeferSupportingClassLoader.java:79)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at
> org.apache.logging.log4j.core.jmx.Server.unregisterAllMatching(Server.java:337)
> at
> org.apache.logging.log4j.core.jmx.Server.unregisterLoggerContext(Server.java:261)
> at
> org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:165)
> at
> org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:141)
> at
> org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:558)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:619)
> at
> org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:636)
> at
> org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:231)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:243)
> at
> org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
> at org.apache.logging.log4j.LogManager.getContext(LogManager.java:174)
> at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:661)
> at
> org.apache.geode.internal.logging.LogService.getLogger(LogService.java:64)
> at
> org.apache.geode.internal.tcp.ConnectionTable.(ConnectionTable.java:61)
> at
> org.apache.geode.distributed.DistributedSystem.setThreadsSocketPolicy(DistributedSystem.java:263)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.lambda$static$0(InternalDistributedSystem.java:2317)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6223) Build job(s) should include resolveDependencies task
Patrick Rhomberg created GEODE-6223: --- Summary: Build job(s) should include resolveDependencies task Key: GEODE-6223 URL: https://issues.apache.org/jira/browse/GEODE-6223 Project: Geode Issue Type: Improvement Reporter: Patrick Rhomberg The recent BOM changes broke the resolveDependencies task (as the BOM was required but was note declared as a dependency), but this went undetected in both the precheckin and main CI pipelines, as the task is only targeted in the creation of test images. This task should be a part of the Build test job, to prevent image breakage in the future. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6223) Build job(s) should include resolveDependencies task
[ https://issues.apache.org/jira/browse/GEODE-6223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-6223: -- Labels: pull-request-available (was: ) > Build job(s) should include resolveDependencies task > > > Key: GEODE-6223 > URL: https://issues.apache.org/jira/browse/GEODE-6223 > Project: Geode > Issue Type: Improvement >Reporter: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > > The recent BOM changes broke the resolveDependencies task (as the BOM was > required but was note declared as a dependency), but this went undetected in > both the precheckin and main CI pipelines, as the task is only targeted in > the creation of test images. > This task should be a part of the Build test job, to prevent image breakage > in the future. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6177) Gateway senders can shut down due to authentication failures
[ https://issues.apache.org/jira/browse/GEODE-6177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill resolved GEODE-6177. - Resolution: Fixed > Gateway senders can shut down due to authentication failures > > > Key: GEODE-6177 > URL: https://issues.apache.org/jira/browse/GEODE-6177 > Project: Geode > Issue Type: Bug > Components: security, wan >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Labels: pull-request-available > Time Spent: 1h 40m > Remaining Estimate: 0h > > When a gateway sender connects to a gateway receiver and authentication is > used, the receiver first determines if the provided credentials are valid. > If they are valid, then event processing/dispatching is allowed. > However, once the initial authentication is performed, it is possible that > the gateway sender stops processing events if the connection with the > receiver is destroyed and the credentials used are no longer valid > (disallowed, password changed, etc). > This is an edge case where the ack reader thread is the first to attempt to > acquire the connection, rather than the dispatcher thread. The ack reader > thread currently does not have the proper retry logic for authentication > exceptions, while the dispatcher thread does. We should ensure that > connection retries occur regardless of which thread gets the authentication > exception. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6177) Gateway senders can shut down due to authentication failures
[ https://issues.apache.org/jira/browse/GEODE-6177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill updated GEODE-6177: Fix Version/s: 1.9.0 > Gateway senders can shut down due to authentication failures > > > Key: GEODE-6177 > URL: https://issues.apache.org/jira/browse/GEODE-6177 > Project: Geode > Issue Type: Bug > Components: security, wan >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > When a gateway sender connects to a gateway receiver and authentication is > used, the receiver first determines if the provided credentials are valid. > If they are valid, then event processing/dispatching is allowed. > However, once the initial authentication is performed, it is possible that > the gateway sender stops processing events if the connection with the > receiver is destroyed and the credentials used are no longer valid > (disallowed, password changed, etc). > This is an edge case where the ack reader thread is the first to attempt to > acquire the connection, rather than the dispatcher thread. The ack reader > thread currently does not have the proper retry logic for authentication > exceptions, while the dispatcher thread does. We should ensure that > connection retries occur regardless of which thread gets the authentication > exception. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6221) CI Failure: LocatorConnectionDUnitTest.testInvalidOperationReturnsFailure statistics verification failed for bytesSent
[ https://issues.apache.org/jira/browse/GEODE-6221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan updated GEODE-6221: Description: Seen in the most recent CI run, so don't know if this is a consistent failure or some previously unseen flaky failure. Test failure found in [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/253] was: Seen in the most recent CI run, so don't know if this is a nee consistent failure or some previously unseen flaky failure. Test failure found in [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/253] > CI Failure: LocatorConnectionDUnitTest.testInvalidOperationReturnsFailure > statistics verification failed for bytesSent > -- > > Key: GEODE-6221 > URL: https://issues.apache.org/jira/browse/GEODE-6221 > Project: Geode > Issue Type: Bug >Affects Versions: 1.9.0 >Reporter: Kenneth Howe >Priority: Major > > Seen in the most recent CI run, so don't know if this is a consistent failure > or some previously unseen flaky failure. > Test failure found in > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/253] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6221) CI Failure: LocatorConnectionDUnitTest.testInvalidOperationReturnsFailure statistics verification failed for bytesSent
[ https://issues.apache.org/jira/browse/GEODE-6221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16724601#comment-16724601 ] Galen O'Sullivan commented on GEODE-6221: - Looks like this failed on messagesSent from the line number (and that would make sense for the numbers we're seeing). Somehow it picked up an extra message? > CI Failure: LocatorConnectionDUnitTest.testInvalidOperationReturnsFailure > statistics verification failed for bytesSent > -- > > Key: GEODE-6221 > URL: https://issues.apache.org/jira/browse/GEODE-6221 > Project: Geode > Issue Type: Bug >Affects Versions: 1.9.0 >Reporter: Kenneth Howe >Priority: Major > > Seen in the most recent CI run, so don't know if this is a consistent failure > or some previously unseen flaky failure. > Test failure found in > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/253] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
