[jira] [Resolved] (GEODE-9780) Remove tests for removed internal commands from AbstractUnknownIntegrationTest
[ https://issues.apache.org/jira/browse/GEODE-9780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-9780. Fix Version/s: 1.15.0 Resolution: Fixed > Remove tests for removed internal commands from AbstractUnknownIntegrationTest > -- > > Key: GEODE-9780 > URL: https://issues.apache.org/jira/browse/GEODE-9780 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The AbstractUnknownIntegrationTest class contains tests that assert that the > commands INTERNALSMEMBERS, INTERNALPTTL and INTERNALTYPE return an "unknown > command" response to a Redis client. These commands no longer exist as custom > internal commands, so these tests are redundant and should be removed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9780) Remove tests for removed internal commands from AbstractUnknownIntegrationTest
[ https://issues.apache.org/jira/browse/GEODE-9780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435422#comment-17435422 ] ASF subversion and git services commented on GEODE-9780: Commit 5f9cbc2c85eae1f5eb01e424a5783a4b0bd4491d in geode's branch refs/heads/develop from Donal Evans [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5f9cbc2 ] GEODE-9780: Remove tests for nonexistent internal Redis commands (#7056) Authored-by: Donal Evans > Remove tests for removed internal commands from AbstractUnknownIntegrationTest > -- > > Key: GEODE-9780 > URL: https://issues.apache.org/jira/browse/GEODE-9780 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The AbstractUnknownIntegrationTest class contains tests that assert that the > commands INTERNALSMEMBERS, INTERNALPTTL and INTERNALTYPE return an "unknown > command" response to a Redis client. These commands no longer exist as custom > internal commands, so these tests are redundant and should be removed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9683) Improve Test Coverage for RedisMemberInfo
[ https://issues.apache.org/jira/browse/GEODE-9683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-9683. Fix Version/s: 1.15.0 Resolution: Fixed > Improve Test Coverage for RedisMemberInfo > - > > Key: GEODE-9683 > URL: https://issues.apache.org/jira/browse/GEODE-9683 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The test coverage for org.apache.geode.redis.internal.cluster.RedisMemberInfo > needs improvement. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9683) Improve Test Coverage for RedisMemberInfo
[ https://issues.apache.org/jira/browse/GEODE-9683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435425#comment-17435425 ] ASF subversion and git services commented on GEODE-9683: Commit c6bee7a44addee0009cc5c6a5d9da1476b4dccee in geode's branch refs/heads/develop from Donal Evans [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c6bee7a ] GEODE-9683: Add unit test coverage for RedisMemberInfo (#7054) Authored-by: Donal Evans > Improve Test Coverage for RedisMemberInfo > - > > Key: GEODE-9683 > URL: https://issues.apache.org/jira/browse/GEODE-9683 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The test coverage for org.apache.geode.redis.internal.cluster.RedisMemberInfo > needs improvement. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8950) Benchmark failure - P2pPartitionedPutLongBenchmark
[ https://issues.apache.org/jira/browse/GEODE-8950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-8950: --- Labels: (was: blocks-1.15.0) > Benchmark failure - P2pPartitionedPutLongBenchmark > -- > > Key: GEODE-8950 > URL: https://issues.apache.org/jira/browse/GEODE-8950 > Project: Geode > Issue Type: Bug > Components: benchmarks >Affects Versions: 1.15.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Fix For: 1.14.0, 1.15.0 > > Attachments: GEODE-8950-before-after-histogram-chart.png, > GEODE-8950-performance degradation vs 1.13.png > > > Multiple benchmark failures due to P2pPartitionedPutLongBenchmark have been > seen recently. > This run saw 3 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/16|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/16#L601ed52d:5552] > This run saw 1 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/20] > This run saw 4 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/27] > In all the above benchmarks, the other failed runs were due to EOFExceptions > rather than flagged degradations. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9684) Improve Test Coverage for RedisMemberInfoRetrievalFunction
[ https://issues.apache.org/jira/browse/GEODE-9684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435574#comment-17435574 ] ASF subversion and git services commented on GEODE-9684: Commit dae7b820812632854f634d4a2c62bd84ed6c6a6c in geode's branch refs/heads/develop from Donal Evans [ https://gitbox.apache.org/repos/asf?p=geode.git;h=dae7b82 ] GEODE-9684: Add unit test coverage for RedisMemberInfoRetrievalFunction (#7053) Authored-by: Donal Evans > Improve Test Coverage for RedisMemberInfoRetrievalFunction > -- > > Key: GEODE-9684 > URL: https://issues.apache.org/jira/browse/GEODE-9684 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > > The class > org.apache.geode.redis.internal.cluster.RedisMemberInfoRetrievalFunction > needs improvement in test coverage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9684) Improve Test Coverage for RedisMemberInfoRetrievalFunction
[ https://issues.apache.org/jira/browse/GEODE-9684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-9684. Fix Version/s: 1.15.0 Resolution: Fixed > Improve Test Coverage for RedisMemberInfoRetrievalFunction > -- > > Key: GEODE-9684 > URL: https://issues.apache.org/jira/browse/GEODE-9684 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The class > org.apache.geode.redis.internal.cluster.RedisMemberInfoRetrievalFunction > needs improvement in test coverage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-694) CI failure: ReliableMessagingDUnitTest.testPeriodicAckSendByClientPrimaryFailover
[
https://issues.apache.org/jira/browse/GEODE-694?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435593#comment-17435593
]
Geode Integration commented on GEODE-694:
-
Seen on support/1.12 in [distributed-test-openjdk8
#57|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main/jobs/distributed-test-openjdk8/builds/57]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.6-build.0296/test-results/distributedTest/1635400557/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.6-build.0296/test-artifacts/1635400557/distributedtestfiles-openjdk8-1.12.6-build.0296.tgz].
> CI failure:
> ReliableMessagingDUnitTest.testPeriodicAckSendByClientPrimaryFailover
> -
>
> Key: GEODE-694
> URL: https://issues.apache.org/jira/browse/GEODE-694
> Project: Geode
> Issue Type: Bug
> Components: client queues
>Affects Versions: 1.0.0-incubating
>Reporter: Jens Deppe
>Priority: Major
> Labels: CI, Flaky
>
> https://builds.apache.org/job/Geode-nightly/313/testReport/junit/com.gemstone.gemfire.internal.cache.tier.sockets/ReliableMessagingDUnitTest/testPeriodicAckSendByClientPrimaryFailover/
> git rev ec9d16a3130e33ee53d837301dc35c3a8bf0e99d build #313
> {noformat}
> Error Message
> junit.framework.AssertionFailedError: Creation time 1450161450166 supposed to
> be same as seo 1450161454951
> Stacktrace
> junit.framework.AssertionFailedError: Creation time 1450161450166 supposed to
> be same as seo 1450161454951
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.TestCase.assertTrue(TestCase.java:192)
> at
> com.gemstone.gemfire.internal.cache.tier.sockets.ReliableMessagingDUnitTest.waitForClientAck(ReliableMessagingDUnitTest.java:150)
> at
> com.gemstone.gemfire.internal.cache.tier.sockets.ReliableMessagingDUnitTest.testPeriodicAckSendByClientPrimaryFailover(ReliableMessagingDUnitTest.java:120)
> 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:497)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
> 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:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:106)
> 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:49
[jira] [Commented] (GEODE-9752) Limit Memory Consumption for Read Operation
[ https://issues.apache.org/jira/browse/GEODE-9752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435605#comment-17435605 ] Darrel Schneider commented on GEODE-9752: - It looks to me like Anthony's ChunkedWriteHandler would solve Dan's big problem of serializing the whole response into one ByteBuf. But it does require that the whole result is known to the ChunkedInput we implement. And because of concurrency issues the ChunkedInput we implement will need to have a stable view of all the values being returned. So in Dan's example of zrange it will need to create a new ArrayList and we keep it alive until netty has written all the chunks back to the client. So the ArrayList can end up getting promoted and cause a more expensive gc in the server's future. I agree that it could be worse (we could also have to copy all the elements in the ArrayList) but it also seems like it could be better if as we iterate over data structure we start writing the result. In some cases this might not be efficient because we need to finish the iteration before we know the size of the result and we need to write the size first. But in other cases it seems best to "cut out the middle man" and write the result data directly to a netty ByteBuf. > Limit Memory Consumption for Read Operation > --- > > Key: GEODE-9752 > URL: https://issues.apache.org/jira/browse/GEODE-9752 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Priority: Major > > The "read" commands can be made more memory friendly by streaming back their > result to netty a "batch" at a time. They can get the netty ByteBuf and write > the result directly to it. Once the buffer contains a certain number of bytes > (say 4k) it do a write and flush. Once that completes it can then use the > same buffer to send the next 4k bytes to the client. Writing the response > directly to the netty ByteBuf will also produce less garbage. The only > downside to it is that the writing will be done while holding the stripe > lock. This probably will not be any slower unless the buffer fills up while > we still hold the lock. The last buffer (the one that is not full) can be > done after the lock is released just as we currently do by returning a > RedisResponse outside the lock and then asking it to write itself to netty. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435611#comment-17435611 ] Geode Integration commented on GEODE-7739: -- Seen on support/1.14 in [distributed-test-openjdk11 #62|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-14-main/jobs/distributed-test-openjdk11/builds/62] ... see [test results|http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.1-build.0878/test-results/distributedTest/1635418161/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.1-build.0878/test-artifacts/1635418161/distributedtestfiles-openjdk11-1.14.1-build.0878.tgz]. > JMX managers may fail to federate mbeans for other members > -- > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > JMX Manager may fail to federate one or more MXBeans for other members > because of a race condition during startup. When ManagementCacheListener is > first constructed, it is in a state that will ignore all callbacks because > the field readyForEvents is false. > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. > > Studying the JMX code also reveals the existence of *GEODE-8012*. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9778) Benchmark degradation in RedisHsetBenchmark since netty bump
[
https://issues.apache.org/jira/browse/GEODE-9778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435616#comment-17435616
]
Geode Integration commented on GEODE-9778:
--
Seen in [benchmark-radish
#183|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-radish/builds/183].
> Benchmark degradation in RedisHsetBenchmark since netty bump
>
>
> Key: GEODE-9778
> URL: https://issues.apache.org/jira/browse/GEODE-9778
> Project: Geode
> Issue Type: Bug
> Components: benchmarks, redis
>Affects Versions: 1.15.0
>Reporter: Owen Nichols
>Assignee: Jens Deppe
>Priority: Major
> Labels: needsTriage
>
> examples:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-radish/builds/179]
> #179 seems to show a consistent 10-15% degradation in only in the Hset
> benchmark
> {noformat}
> ...
> This is ITERATION 3 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:234210.78 Test:207591.61 Difference: -11.4%
> avg latency
> Baseline: 3070166.30 Test: 3468289.49 Difference: +13.0%
> This is ITERATION 4 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:238884.30 Test:216618.91 Difference: -9.3%
> avg latency
> Baseline: 3016750.52 Test: 3319615.79 Difference: +10.0%
> This is ITERATION 5 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:248656.29 Test:211220.74 Difference: -15.1%
> avg latency
> Baseline: 2894368.00 Test: 3405200.04 Difference: +17.6% {noformat}
>
> Also
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-radish/builds/180]
> shows similar results:
> {noformat}
> This is ITERATION 2 of benchmarking against baseline.
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:146409.80 Test:134019.47 Difference: -8.5%
> avg latency
> Baseline: 4914049.28 Test: 5365514.18 Difference: +9.2%
> RedisHsetBenchmark avg ops/sec
> Baseline:217729.26 Test:191512.40 Difference: -12.0%
> avg latency
> Baseline: 3302672.13 Test: 3750731.05 Difference: +13.6%
> This is ITERATION 3 of benchmarking against baseline.
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:141960.20 Test:129616.40 Difference: -8.7%
> avg latency
> Baseline: 5065570.96 Test: 5554949.31 Difference: +9.7%
> RedisHsetBenchmark avg ops/sec
> Baseline:219985.85 Test:199572.01 Difference: -9.3%
> avg latency
> Baseline: 3268138.34 Test: 3603197.51 Difference: +10.3%
> This is ITERATION 4 of benchmarking against baseline.
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:140404.88 Test:134341.05 Difference: -4.3%
> avg latency
> Baseline: 5127629.59 Test: 5354599.94 Difference: +4.4%
> RedisHsetBenchmark avg ops/sec
> Baseline:224728.82 Test:194024.96 Difference: -13.7%
> avg latency
> Baseline: 3205365.68 Test: 3706058.86 Difference: +15.6%
> This is ITERATION 5 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:220019.47 Test:192107.91 Difference: -12.7%
> avg latency
> Baseline: 3268273.76 Test: 3744842.51 Difference: +14.6%
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9785) CI Failure: RedundancyLevelPart2DUnitTest.testRedundancySpecifiedEPFails FAILED
[
https://issues.apache.org/jira/browse/GEODE-9785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-9785:
-
Labels: needsTriage (was: )
> CI Failure: RedundancyLevelPart2DUnitTest.testRedundancySpecifiedEPFails
> FAILED
> ---
>
> Key: GEODE-9785
> URL: https://issues.apache.org/jira/browse/GEODE-9785
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Eric Shu
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> org.junit.ComparisonFailure: expected:<[2]> but was:<[0]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart2DUnitTest.testRedundancySpecifiedEPFails(RedundancyLevelPart2DUnitTest.java:215)
> 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.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.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 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.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> 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.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
> 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.inte
[jira] [Created] (GEODE-9785) CI Failure: RedundancyLevelPart2DUnitTest.testRedundancySpecifiedEPFails FAILED
Eric Shu created GEODE-9785:
---
Summary: CI Failure:
RedundancyLevelPart2DUnitTest.testRedundancySpecifiedEPFails FAILED
Key: GEODE-9785
URL: https://issues.apache.org/jira/browse/GEODE-9785
Project: Geode
Issue Type: Bug
Components: regions
Reporter: Eric Shu
{noformat}
org.junit.ComparisonFailure: expected:<[2]> but was:<[0]>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart2DUnitTest.testRedundancySpecifiedEPFails(RedundancyLevelPart2DUnitTest.java:215)
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.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.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
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.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
at
org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
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.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at
org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
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.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:175)
at
org.gradle.internal.remote.internal.hub.Mes
[jira] [Commented] (GEODE-9785) CI Failure: RedundancyLevelPart2DUnitTest.testRedundancySpecifiedEPFails FAILED
[
https://issues.apache.org/jira/browse/GEODE-9785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435622#comment-17435622
]
Geode Integration commented on GEODE-9785:
--
Seen on support/1.12 in [distributed-test-openjdk8
#57|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main/jobs/distributed-test-openjdk8/builds/57]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.6-build.0296/test-results/distributedTest/1635400557/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.6-build.0296/test-artifacts/1635400557/distributedtestfiles-openjdk8-1.12.6-build.0296.tgz].
> CI Failure: RedundancyLevelPart2DUnitTest.testRedundancySpecifiedEPFails
> FAILED
> ---
>
> Key: GEODE-9785
> URL: https://issues.apache.org/jira/browse/GEODE-9785
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Eric Shu
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> org.junit.ComparisonFailure: expected:<[2]> but was:<[0]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart2DUnitTest.testRedundancySpecifiedEPFails(RedundancyLevelPart2DUnitTest.java:215)
> 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.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.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 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.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> 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.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatc
[jira] [Updated] (GEODE-9767) bump netty to recommended version
[ https://issues.apache.org/jira/browse/GEODE-9767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-9767: Fix Version/s: (was: 1.15.0) > bump netty to recommended version > - > > Key: GEODE-9767 > URL: https://issues.apache.org/jira/browse/GEODE-9767 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.12.5, 1.13.4, 1.14.0, 1.15.0 >Reporter: Owen Nichols >Priority: Major > Labels: needsTriage, pull-request-available > > latest is 4.1.69, we should be using 4.1.68 or 4.1.69 on all branches if > possible -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9786) remove IndexibleTreeSet and associated tests
Darrel Schneider created GEODE-9786: --- Summary: remove IndexibleTreeSet and associated tests Key: GEODE-9786 URL: https://issues.apache.org/jira/browse/GEODE-9786 Project: Geode Issue Type: Improvement Components: redis Reporter: Darrel Schneider IndexibleTreeSet is unused by geode-for-redis. It was added to compare its performance to OrderStatisticsTree and a decision was made to use OrderStatisticsTree. So to simplify the code and testing it should be removed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9787) Cascade deprecation of symbols to dependent symbols.
Jacob Barrett created GEODE-9787:
Summary: Cascade deprecation of symbols to dependent symbols.
Key: GEODE-9787
URL: https://issues.apache.org/jira/browse/GEODE-9787
Project: Geode
Issue Type: Task
Reporter: Jacob Barrett
When deprecated some symbols require that other symbols be modified to match
types or or other changes. The original versions of these symbols should be
deprecated in favor of the new. This is a long running ticket to collect all
those changes.
For example, when replacing deprecated usage of {{Statistics.getInt()}} with
{{Statistics.getLong()}} a public API method may need to change to return the
{{long}} value.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9291) Develop Benchmarking Tests for Leaderboard API
[ https://issues.apache.org/jira/browse/GEODE-9291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435632#comment-17435632 ] ASF GitHub Bot commented on GEODE-9291: --- ezoerner commented on pull request #159: URL: https://github.com/apache/geode-benchmarks/pull/159#issuecomment-954125324 Looks like I need to clean up some code for spotlessJava... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Develop Benchmarking Tests for Leaderboard API > -- > > Key: GEODE-9291 > URL: https://issues.apache.org/jira/browse/GEODE-9291 > Project: Geode > Issue Type: Test > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Assignee: Eric Zoerner >Priority: Major > Labels: pull-request-available, redis > > Develop a suite of benchmarking tests for the Leaderboard API that benchmark > the comparison between native Redis and the compatibility with Redis layer. > +Acceptance Criteria+ > A benchmark should be developed that provides acceptable coverage (TBD) of > the Leaderboard API that allows us to monitor the performance over time and > compared to native Redis. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9291) Develop Benchmarking Tests for Leaderboard API
[ https://issues.apache.org/jira/browse/GEODE-9291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435634#comment-17435634 ] ASF GitHub Bot commented on GEODE-9291: --- ezoerner removed a comment on pull request #159: URL: https://github.com/apache/geode-benchmarks/pull/159#issuecomment-954125324 Looks like I need to clean up some code for spotlessJava... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Develop Benchmarking Tests for Leaderboard API > -- > > Key: GEODE-9291 > URL: https://issues.apache.org/jira/browse/GEODE-9291 > Project: Geode > Issue Type: Test > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Assignee: Eric Zoerner >Priority: Major > Labels: pull-request-available, redis > > Develop a suite of benchmarking tests for the Leaderboard API that benchmark > the comparison between native Redis and the compatibility with Redis layer. > +Acceptance Criteria+ > A benchmark should be developed that provides acceptable coverage (TBD) of > the Leaderboard API that allows us to monitor the performance over time and > compared to native Redis. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9291) Develop Benchmarking Tests for Leaderboard API
[
https://issues.apache.org/jira/browse/GEODE-9291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435645#comment-17435645
]
ASF GitHub Bot commented on GEODE-9291:
---
DonalEvans commented on a change in pull request #159:
URL: https://github.com/apache/geode-benchmarks/pull/159#discussion_r738705681
##
File path:
geode-benchmarks/src/main/java/org/apache/geode/benchmark/redis/tests/RedisWeightedZaddAndZrangeBenchmark.java
##
@@ -0,0 +1,45 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.geode.benchmark.redis.tests;
+
+import static org.apache.geode.benchmark.Config.before;
+import static org.apache.geode.benchmark.Config.workload;
+import static org.apache.geode.benchmark.topology.Roles.CLIENT;
+
+import org.apache.geode.benchmark.redis.tasks.PrePopulateRedisHash;
+import org.apache.geode.benchmark.redis.tasks.ZaddRedisTask;
+import org.apache.geode.benchmark.redis.tasks.ZrangeRedisTask;
+import org.apache.geode.benchmark.tasks.WeightedTasks;
+import org.apache.geode.benchmark.tasks.WeightedTasks.WeightedTask;
+import org.apache.geode.perftest.TestConfig;
+
+public class RedisWeightedZaddAndZrangeBenchmark extends RedisBenchmark {
+
+ @Override
+ public TestConfig configure() {
+final TestConfig config = super.configure();
+
+before(config, new PrePopulateRedisHash(redisClientManager, keyRange),
CLIENT);
Review comment:
I think this should be `PrePopulateRedisSortedSet()`
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Develop Benchmarking Tests for Leaderboard API
> --
>
> Key: GEODE-9291
> URL: https://issues.apache.org/jira/browse/GEODE-9291
> Project: Geode
> Issue Type: Test
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Wayne
>Assignee: Eric Zoerner
>Priority: Major
> Labels: pull-request-available, redis
>
> Develop a suite of benchmarking tests for the Leaderboard API that benchmark
> the comparison between native Redis and the compatibility with Redis layer.
> +Acceptance Criteria+
> A benchmark should be developed that provides acceptable coverage (TBD) of
> the Leaderboard API that allows us to monitor the performance over time and
> compared to native Redis.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9788) Develop PubSub Benchmark Tests
Wayne created GEODE-9788: Summary: Develop PubSub Benchmark Tests Key: GEODE-9788 URL: https://issues.apache.org/jira/browse/GEODE-9788 Project: Geode Issue Type: Test Components: redis Reporter: Wayne Develop a suite of benchmarking tests for the pubsub API that benchmark the comparison between native Redis and the compatibility with Redis layer. +Acceptance Criteria+ A benchmark should be developed that provides acceptable coverage (TBD) of the pubsub that allows us to monitor the performance over time and compared to native Redis. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9767) bump netty to recommended version
[ https://issues.apache.org/jira/browse/GEODE-9767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435667#comment-17435667 ] ASF subversion and git services commented on GEODE-9767: Commit b4deab0715dc461c8965f1601ce5994688382d0e in geode's branch refs/heads/develop from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b4deab0 ] Revert "GEODE-9767: Bump netty from 4.1.67.Final to 4.1.69.Final (#7031)" (#7061) - Reverting because of suspected performance degradation. This reverts commit d759a52007409ddb38969917f5ee381ad4db6e5e. > bump netty to recommended version > - > > Key: GEODE-9767 > URL: https://issues.apache.org/jira/browse/GEODE-9767 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.12.5, 1.13.4, 1.14.0, 1.15.0 >Reporter: Owen Nichols >Priority: Major > Labels: needsTriage, pull-request-available > > latest is 4.1.69, we should be using 4.1.68 or 4.1.69 on all branches if > possible -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9656) User guide: Document Async disk writer exit behavior
[ https://issues.apache.org/jira/browse/GEODE-9656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9656: -- Labels: pull-request-available (was: ) > User guide: Document Async disk writer exit behavior > > > Key: GEODE-9656 > URL: https://issues.apache.org/jira/browse/GEODE-9656 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.12.4 >Reporter: Dave Barnes >Priority: Major > Labels: pull-request-available > > Request from community member Barry Oglesby: > Can the geode docs be updated to document the behavior in the case where the > Async disk writer thread exits? This thread exists in the case where > disk-synchronous=false. If it exits for any reason, the member shuts down if > an operation attempts to update the disk store. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9656) User guide: Document Async disk writer exit behavior
[ https://issues.apache.org/jira/browse/GEODE-9656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435710#comment-17435710 ] ASF subversion and git services commented on GEODE-9656: Commit ec9fd00e3ccefd3425bc8dd4cbe42302bedbf754 in geode's branch refs/heads/develop from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ec9fd00 ] GEODE-9656: Document Async disk writer exit behavior (#7062) > User guide: Document Async disk writer exit behavior > > > Key: GEODE-9656 > URL: https://issues.apache.org/jira/browse/GEODE-9656 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.12.4 >Reporter: Dave Barnes >Priority: Major > Labels: pull-request-available > > Request from community member Barry Oglesby: > Can the geode docs be updated to document the behavior in the case where the > Async disk writer thread exits? This thread exists in the case where > disk-synchronous=false. If it exits for any reason, the member shuts down if > an operation attempts to update the disk store. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9656) User guide: Document Async disk writer exit behavior
[ https://issues.apache.org/jira/browse/GEODE-9656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435711#comment-17435711 ] ASF subversion and git services commented on GEODE-9656: Commit 433b13a20476e246ca3186220446de85f5fcf209 in geode's branch refs/heads/support/1.14 from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=433b13a ] GEODE-9656: Document Async disk writer exit behavior (#7062) > User guide: Document Async disk writer exit behavior > > > Key: GEODE-9656 > URL: https://issues.apache.org/jira/browse/GEODE-9656 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.12.4 >Reporter: Dave Barnes >Priority: Major > Labels: pull-request-available > > Request from community member Barry Oglesby: > Can the geode docs be updated to document the behavior in the case where the > Async disk writer thread exits? This thread exists in the case where > disk-synchronous=false. If it exits for any reason, the member shuts down if > an operation attempts to update the disk store. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9656) User guide: Document Async disk writer exit behavior
[ https://issues.apache.org/jira/browse/GEODE-9656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435712#comment-17435712 ] ASF subversion and git services commented on GEODE-9656: Commit 6d8d26795d8f4d7090a3ce20196797b005e13a37 in geode's branch refs/heads/support/1.13 from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6d8d267 ] GEODE-9656: Document Async disk writer exit behavior (#7062) > User guide: Document Async disk writer exit behavior > > > Key: GEODE-9656 > URL: https://issues.apache.org/jira/browse/GEODE-9656 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.12.4 >Reporter: Dave Barnes >Priority: Major > Labels: pull-request-available > > Request from community member Barry Oglesby: > Can the geode docs be updated to document the behavior in the case where the > Async disk writer thread exits? This thread exists in the case where > disk-synchronous=false. If it exits for any reason, the member shuts down if > an operation attempts to update the disk store. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9656) User guide: Document Async disk writer exit behavior
[ https://issues.apache.org/jira/browse/GEODE-9656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes reassigned GEODE-9656: -- Assignee: Dave Barnes > User guide: Document Async disk writer exit behavior > > > Key: GEODE-9656 > URL: https://issues.apache.org/jira/browse/GEODE-9656 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.12.4 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > > Request from community member Barry Oglesby: > Can the geode docs be updated to document the behavior in the case where the > Async disk writer thread exits? This thread exists in the case where > disk-synchronous=false. If it exits for any reason, the member shuts down if > an operation attempts to update the disk store. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9656) User guide: Document Async disk writer exit behavior
[ https://issues.apache.org/jira/browse/GEODE-9656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435714#comment-17435714 ] ASF subversion and git services commented on GEODE-9656: Commit fcc0fca6d6137290870fd12a1249ebf77c229d04 in geode's branch refs/heads/support/1.12 from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=fcc0fca ] GEODE-9656: Document Async disk writer exit behavior (#7062) > User guide: Document Async disk writer exit behavior > > > Key: GEODE-9656 > URL: https://issues.apache.org/jira/browse/GEODE-9656 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.12.4 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > Fix For: 1.12.6, 1.13.5, 1.14.1, 1.15.0 > > > Request from community member Barry Oglesby: > Can the geode docs be updated to document the behavior in the case where the > Async disk writer thread exits? This thread exists in the case where > disk-synchronous=false. If it exits for any reason, the member shuts down if > an operation attempts to update the disk store. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9656) User guide: Document Async disk writer exit behavior
[ https://issues.apache.org/jira/browse/GEODE-9656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes resolved GEODE-9656. Fix Version/s: 1.15.0 1.14.1 1.13.5 1.12.6 Resolution: Fixed > User guide: Document Async disk writer exit behavior > > > Key: GEODE-9656 > URL: https://issues.apache.org/jira/browse/GEODE-9656 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.12.4 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > Fix For: 1.12.6, 1.13.5, 1.14.1, 1.15.0 > > > Request from community member Barry Oglesby: > Can the geode docs be updated to document the behavior in the case where the > Async disk writer thread exits? This thread exists in the case where > disk-synchronous=false. If it exits for any reason, the member shuts down if > an operation attempts to update the disk store. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9778) Benchmark degradation in RedisHsetBenchmark since netty bump
[
https://issues.apache.org/jira/browse/GEODE-9778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435717#comment-17435717
]
Geode Integration commented on GEODE-9778:
--
Seen in [benchmark-radish
#185|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-radish/builds/185].
> Benchmark degradation in RedisHsetBenchmark since netty bump
>
>
> Key: GEODE-9778
> URL: https://issues.apache.org/jira/browse/GEODE-9778
> Project: Geode
> Issue Type: Bug
> Components: benchmarks, redis
>Affects Versions: 1.15.0
>Reporter: Owen Nichols
>Assignee: Jens Deppe
>Priority: Major
> Labels: needsTriage
>
> examples:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-radish/builds/179]
> #179 seems to show a consistent 10-15% degradation in only in the Hset
> benchmark
> {noformat}
> ...
> This is ITERATION 3 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:234210.78 Test:207591.61 Difference: -11.4%
> avg latency
> Baseline: 3070166.30 Test: 3468289.49 Difference: +13.0%
> This is ITERATION 4 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:238884.30 Test:216618.91 Difference: -9.3%
> avg latency
> Baseline: 3016750.52 Test: 3319615.79 Difference: +10.0%
> This is ITERATION 5 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:248656.29 Test:211220.74 Difference: -15.1%
> avg latency
> Baseline: 2894368.00 Test: 3405200.04 Difference: +17.6% {noformat}
>
> Also
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-radish/builds/180]
> shows similar results:
> {noformat}
> This is ITERATION 2 of benchmarking against baseline.
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:146409.80 Test:134019.47 Difference: -8.5%
> avg latency
> Baseline: 4914049.28 Test: 5365514.18 Difference: +9.2%
> RedisHsetBenchmark avg ops/sec
> Baseline:217729.26 Test:191512.40 Difference: -12.0%
> avg latency
> Baseline: 3302672.13 Test: 3750731.05 Difference: +13.6%
> This is ITERATION 3 of benchmarking against baseline.
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:141960.20 Test:129616.40 Difference: -8.7%
> avg latency
> Baseline: 5065570.96 Test: 5554949.31 Difference: +9.7%
> RedisHsetBenchmark avg ops/sec
> Baseline:219985.85 Test:199572.01 Difference: -9.3%
> avg latency
> Baseline: 3268138.34 Test: 3603197.51 Difference: +10.3%
> This is ITERATION 4 of benchmarking against baseline.
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:140404.88 Test:134341.05 Difference: -4.3%
> avg latency
> Baseline: 5127629.59 Test: 5354599.94 Difference: +4.4%
> RedisHsetBenchmark avg ops/sec
> Baseline:224728.82 Test:194024.96 Difference: -13.7%
> avg latency
> Baseline: 3205365.68 Test: 3706058.86 Difference: +15.6%
> This is ITERATION 5 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:220019.47 Test:192107.91 Difference: -12.7%
> avg latency
> Baseline: 3268273.76 Test: 3744842.51 Difference: +14.6%
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9778) Benchmark degradation in RedisHsetBenchmark since netty bump
[
https://issues.apache.org/jira/browse/GEODE-9778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435716#comment-17435716
]
Geode Integration commented on GEODE-9778:
--
Seen in [benchmark-radish
#184|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-radish/builds/184].
> Benchmark degradation in RedisHsetBenchmark since netty bump
>
>
> Key: GEODE-9778
> URL: https://issues.apache.org/jira/browse/GEODE-9778
> Project: Geode
> Issue Type: Bug
> Components: benchmarks, redis
>Affects Versions: 1.15.0
>Reporter: Owen Nichols
>Assignee: Jens Deppe
>Priority: Major
> Labels: needsTriage
>
> examples:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-radish/builds/179]
> #179 seems to show a consistent 10-15% degradation in only in the Hset
> benchmark
> {noformat}
> ...
> This is ITERATION 3 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:234210.78 Test:207591.61 Difference: -11.4%
> avg latency
> Baseline: 3070166.30 Test: 3468289.49 Difference: +13.0%
> This is ITERATION 4 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:238884.30 Test:216618.91 Difference: -9.3%
> avg latency
> Baseline: 3016750.52 Test: 3319615.79 Difference: +10.0%
> This is ITERATION 5 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:248656.29 Test:211220.74 Difference: -15.1%
> avg latency
> Baseline: 2894368.00 Test: 3405200.04 Difference: +17.6% {noformat}
>
> Also
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-radish/builds/180]
> shows similar results:
> {noformat}
> This is ITERATION 2 of benchmarking against baseline.
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:146409.80 Test:134019.47 Difference: -8.5%
> avg latency
> Baseline: 4914049.28 Test: 5365514.18 Difference: +9.2%
> RedisHsetBenchmark avg ops/sec
> Baseline:217729.26 Test:191512.40 Difference: -12.0%
> avg latency
> Baseline: 3302672.13 Test: 3750731.05 Difference: +13.6%
> This is ITERATION 3 of benchmarking against baseline.
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:141960.20 Test:129616.40 Difference: -8.7%
> avg latency
> Baseline: 5065570.96 Test: 5554949.31 Difference: +9.7%
> RedisHsetBenchmark avg ops/sec
> Baseline:219985.85 Test:199572.01 Difference: -9.3%
> avg latency
> Baseline: 3268138.34 Test: 3603197.51 Difference: +10.3%
> This is ITERATION 4 of benchmarking against baseline.
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:140404.88 Test:134341.05 Difference: -4.3%
> avg latency
> Baseline: 5127629.59 Test: 5354599.94 Difference: +4.4%
> RedisHsetBenchmark avg ops/sec
> Baseline:224728.82 Test:194024.96 Difference: -13.7%
> avg latency
> Baseline: 3205365.68 Test: 3706058.86 Difference: +15.6%
> This is ITERATION 5 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:220019.47 Test:192107.91 Difference: -12.7%
> avg latency
> Baseline: 3268273.76 Test: 3744842.51 Difference: +14.6%
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9675) CI: ClusterDistributionManagerDUnitTest > testConnectAfterBeingShunned FAILED
[
https://issues.apache.org/jira/browse/GEODE-9675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-9675:
Attachment: screenshot-1.png
> CI: ClusterDistributionManagerDUnitTest > testConnectAfterBeingShunned FAILED
> -
>
> Key: GEODE-9675
> URL: https://issues.apache.org/jira/browse/GEODE-9675
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.15.0
>Reporter: Xiaojian Zhou
>Priority: Major
> Labels: needsTriage
> Attachments: screenshot-1.png
>
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1983
> {code:java}
> ClusterDistributionManagerDUnitTest > testConnectAfterBeingShunned FAILED
> org.apache.geode.SystemConnectException: Problem starting up membership
> services
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:186)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:466)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:499)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:328)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:757)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:133)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3013)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:283)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:209)
> at
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:159)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.getSystem(JUnit4DistributedTestCase.java:180)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.getSystem(JUnit4DistributedTestCase.java:256)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManagerDUnitTest.testConnectAfterBeingShunned(ClusterDistributionManagerDUnitTest.java:170)
> Caused by:
>
> org.apache.geode.distributed.internal.membership.api.MemberStartupException:
> unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.start(JGroupsMessenger.java:401)
> at
> org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:203)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.start(GMSMembership.java:1642)
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:171)
> ... 13 more
> Caused by:
> java.lang.Exception: failed to open a port in range 41003-41003
> at
> org.jgroups.protocols.UDP.createMulticastSocketWithBindPort(UDP.java:503)
> at org.jgroups.protocols.UDP.createSockets(UDP.java:348)
> at org.jgroups.protocols.UDP.start(UDP.java:266)
> at
> org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966)
> at org.jgroups.JChannel.startStack(JChannel.java:889)
> at org.jgroups.JChannel._preConnect(JChannel.java:553)
> at org.jgroups.JChannel.connect(JChannel.java:288)
> at org.jgroups.JChannel.connect(JChannel.java:279)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.start(JGroupsMessenger.java:397)
> ... 16 more
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-9675) CI: ClusterDistributionManagerDUnitTest > testConnectAfterBeingShunned FAILED
[
https://issues.apache.org/jira/browse/GEODE-9675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham reassigned GEODE-9675:
---
Assignee: Bill Burcham
> CI: ClusterDistributionManagerDUnitTest > testConnectAfterBeingShunned FAILED
> -
>
> Key: GEODE-9675
> URL: https://issues.apache.org/jira/browse/GEODE-9675
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.15.0
>Reporter: Xiaojian Zhou
>Assignee: Bill Burcham
>Priority: Major
> Labels: needsTriage
> Attachments: screenshot-1.png
>
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1983
> {code:java}
> ClusterDistributionManagerDUnitTest > testConnectAfterBeingShunned FAILED
> org.apache.geode.SystemConnectException: Problem starting up membership
> services
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:186)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:466)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:499)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:328)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:757)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:133)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3013)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:283)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:209)
> at
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:159)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.getSystem(JUnit4DistributedTestCase.java:180)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.getSystem(JUnit4DistributedTestCase.java:256)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManagerDUnitTest.testConnectAfterBeingShunned(ClusterDistributionManagerDUnitTest.java:170)
> Caused by:
>
> org.apache.geode.distributed.internal.membership.api.MemberStartupException:
> unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.start(JGroupsMessenger.java:401)
> at
> org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:203)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.start(GMSMembership.java:1642)
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:171)
> ... 13 more
> Caused by:
> java.lang.Exception: failed to open a port in range 41003-41003
> at
> org.jgroups.protocols.UDP.createMulticastSocketWithBindPort(UDP.java:503)
> at org.jgroups.protocols.UDP.createSockets(UDP.java:348)
> at org.jgroups.protocols.UDP.start(UDP.java:266)
> at
> org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966)
> at org.jgroups.JChannel.startStack(JChannel.java:889)
> at org.jgroups.JChannel._preConnect(JChannel.java:553)
> at org.jgroups.JChannel.connect(JChannel.java:288)
> at org.jgroups.JChannel.connect(JChannel.java:279)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.start(JGroupsMessenger.java:397)
> ... 16 more
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9675) CI: ClusterDistributionManagerDUnitTest > testConnectAfterBeingShunned FAILED
[
https://issues.apache.org/jira/browse/GEODE-9675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435719#comment-17435719
]
Bill Burcham commented on GEODE-9675:
-
Looking at the offending test method (included below) I see a few things wrong:
# The comment “Demonstrate that a new UDP port is used…” is at odds with the
assertion at the end of the method (which asserts that the same port is used).
# Contrary to the comment, GMSMembership doesn’t “shun” members when they are
shutting down, rather it keeps them in a shutdownMembers set so as to attenuate
failure detection signals from them. Perhaps in the dim past these members were
actually “shunned”?
# I have no idea why the test disconnect()s, then re-acquires system and
membership and then disconnect()s again before calling getLocalMember() on the
membership acquired before the second disconnect!
# The TODO at line 167 seems superfluous since we proceed to set just such a
system property on the very next line
# Whether the property is set or not, on line 168, the test passes! (at least
in manual runs)—implying that setting that system property is superfluous.
Which leads me to believe this test is worthless and the best fix for
GEODE-9675 may be to delete this test.
!screenshot-1.png!
> CI: ClusterDistributionManagerDUnitTest > testConnectAfterBeingShunned FAILED
> -
>
> Key: GEODE-9675
> URL: https://issues.apache.org/jira/browse/GEODE-9675
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.15.0
>Reporter: Xiaojian Zhou
>Priority: Major
> Labels: needsTriage
> Attachments: screenshot-1.png
>
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1983
> {code:java}
> ClusterDistributionManagerDUnitTest > testConnectAfterBeingShunned FAILED
> org.apache.geode.SystemConnectException: Problem starting up membership
> services
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:186)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:466)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:499)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:328)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:757)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:133)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3013)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:283)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:209)
> at
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:159)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.getSystem(JUnit4DistributedTestCase.java:180)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.getSystem(JUnit4DistributedTestCase.java:256)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManagerDUnitTest.testConnectAfterBeingShunned(ClusterDistributionManagerDUnitTest.java:170)
> Caused by:
>
> org.apache.geode.distributed.internal.membership.api.MemberStartupException:
> unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.start(JGroupsMessenger.java:401)
> at
> org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:203)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.start(GMSMembership.java:1642)
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:171)
> ... 13 more
> Caused by:
> java.lang.Exception: failed to open a port in range 41003-41003
> at
> org.jgroups.protocols.UDP.createMulticastSocketWithBindPort(UDP.java:503)
> at org.jgroups.protocols.UDP.createSockets(UDP.java:348)
> at org.jgroups.protocols.UDP.start(UDP.java:266)
> at
> org.jgroups.stack.ProtocolStack.startStack
[jira] [Comment Edited] (GEODE-9675) CI: ClusterDistributionManagerDUnitTest > testConnectAfterBeingShunned FAILED
[
https://issues.apache.org/jira/browse/GEODE-9675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435719#comment-17435719
]
Bill Burcham edited comment on GEODE-9675 at 10/28/21, 11:34 PM:
-
Looking at the offending test method (included below) I see a few things wrong:
# The comment “Demonstrate that a new UDP port is used…” is at odds with the
assertion at the end of the method (which asserts that the same port is used).
# Contrary to the comment, GMSMembership doesn’t “shun” members when they are
shutting down, rather it keeps them in a shutdownMembers set so as to attenuate
failure detection signals from them. Perhaps in the dim past these members were
actually “shunned”?
# I have no idea why the test disconnect()s, then re-acquires system and
membership and then disconnect()s again before calling getLocalMember() on the
membership acquired before the second disconnect!
# The TODO at line 167 seems superfluous since we proceed to set just such a
system property on the very next line
# Whether the property is set or not, on line 168, the test passes! (at least
in manual runs)—implying that setting that system property is superfluous.
Which leads me to believe this test is worthless and the best fix for
GEODE-9675 may be to delete this test.
!screenshot-1.png!
was (Author: bburcham):
Looking at the offending test method (included below) I see a few things wrong:
# The comment “Demonstrate that a new UDP port is used…” is at odds with the
assertion at the end of the method (which asserts that the same port is used).
# Contrary to the comment, GMSMembership doesn’t “shun” members when they are
shutting down, rather it keeps them in a shutdownMembers set so as to attenuate
failure detection signals from them. Perhaps in the dim past these members were
actually “shunned”?
# I have no idea why the test disconnect()s, then re-acquires system and
membership and then disconnect()s again before calling getLocalMember() on the
membership acquired before the second disconnect!
# The TODO at line 167 seems superfluous since we proceed to set just such a
system property on the very next line
# Whether the property is set or not, on line 168, the test passes! (at least
in manual runs)—implying that setting that system property is superfluous.
Which leads me to believe this test is worthless and the best fix for
GEODE-9675 may be to delete this test.
!screenshot-1.png!
> CI: ClusterDistributionManagerDUnitTest > testConnectAfterBeingShunned FAILED
> -
>
> Key: GEODE-9675
> URL: https://issues.apache.org/jira/browse/GEODE-9675
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.15.0
>Reporter: Xiaojian Zhou
>Assignee: Bill Burcham
>Priority: Major
> Labels: needsTriage
> Attachments: screenshot-1.png
>
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1983
> {code:java}
> ClusterDistributionManagerDUnitTest > testConnectAfterBeingShunned FAILED
> org.apache.geode.SystemConnectException: Problem starting up membership
> services
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:186)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:466)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:499)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:328)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:757)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:133)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3013)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:283)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:209)
> at
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:159)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.getSystem(JUnit4DistributedTestCase.java:180)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.getSystem(JUnit4DistributedTestCase.j
[jira] [Updated] (GEODE-9675) CI: ClusterDistributionManagerDUnitTest > testConnectAfterBeingShunned FAILED
[
https://issues.apache.org/jira/browse/GEODE-9675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-9675:
Labels: (was: needsTriage)
> CI: ClusterDistributionManagerDUnitTest > testConnectAfterBeingShunned FAILED
> -
>
> Key: GEODE-9675
> URL: https://issues.apache.org/jira/browse/GEODE-9675
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.15.0
>Reporter: Xiaojian Zhou
>Assignee: Bill Burcham
>Priority: Major
> Attachments: screenshot-1.png
>
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1983
> {code:java}
> ClusterDistributionManagerDUnitTest > testConnectAfterBeingShunned FAILED
> org.apache.geode.SystemConnectException: Problem starting up membership
> services
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:186)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:466)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:499)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:328)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:757)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:133)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3013)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:283)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:209)
> at
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:159)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.getSystem(JUnit4DistributedTestCase.java:180)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.getSystem(JUnit4DistributedTestCase.java:256)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManagerDUnitTest.testConnectAfterBeingShunned(ClusterDistributionManagerDUnitTest.java:170)
> Caused by:
>
> org.apache.geode.distributed.internal.membership.api.MemberStartupException:
> unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.start(JGroupsMessenger.java:401)
> at
> org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:203)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.start(GMSMembership.java:1642)
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:171)
> ... 13 more
> Caused by:
> java.lang.Exception: failed to open a port in range 41003-41003
> at
> org.jgroups.protocols.UDP.createMulticastSocketWithBindPort(UDP.java:503)
> at org.jgroups.protocols.UDP.createSockets(UDP.java:348)
> at org.jgroups.protocols.UDP.start(UDP.java:266)
> at
> org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966)
> at org.jgroups.JChannel.startStack(JChannel.java:889)
> at org.jgroups.JChannel._preConnect(JChannel.java:553)
> at org.jgroups.JChannel.connect(JChannel.java:288)
> at org.jgroups.JChannel.connect(JChannel.java:279)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.start(JGroupsMessenger.java:397)
> ... 16 more
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-9675) CI: ClusterDistributionManagerDUnitTest > testConnectAfterBeingShunned FAILED
[
https://issues.apache.org/jira/browse/GEODE-9675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham reassigned GEODE-9675:
---
Assignee: (was: Bill Burcham)
> CI: ClusterDistributionManagerDUnitTest > testConnectAfterBeingShunned FAILED
> -
>
> Key: GEODE-9675
> URL: https://issues.apache.org/jira/browse/GEODE-9675
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.15.0
>Reporter: Xiaojian Zhou
>Priority: Major
> Attachments: screenshot-1.png
>
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1983
> {code:java}
> ClusterDistributionManagerDUnitTest > testConnectAfterBeingShunned FAILED
> org.apache.geode.SystemConnectException: Problem starting up membership
> services
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:186)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:466)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:499)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:328)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:757)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:133)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3013)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:283)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:209)
> at
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:159)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.getSystem(JUnit4DistributedTestCase.java:180)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.getSystem(JUnit4DistributedTestCase.java:256)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManagerDUnitTest.testConnectAfterBeingShunned(ClusterDistributionManagerDUnitTest.java:170)
> Caused by:
>
> org.apache.geode.distributed.internal.membership.api.MemberStartupException:
> unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.start(JGroupsMessenger.java:401)
> at
> org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:203)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.start(GMSMembership.java:1642)
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:171)
> ... 13 more
> Caused by:
> java.lang.Exception: failed to open a port in range 41003-41003
> at
> org.jgroups.protocols.UDP.createMulticastSocketWithBindPort(UDP.java:503)
> at org.jgroups.protocols.UDP.createSockets(UDP.java:348)
> at org.jgroups.protocols.UDP.start(UDP.java:266)
> at
> org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966)
> at org.jgroups.JChannel.startStack(JChannel.java:889)
> at org.jgroups.JChannel._preConnect(JChannel.java:553)
> at org.jgroups.JChannel.connect(JChannel.java:288)
> at org.jgroups.JChannel.connect(JChannel.java:279)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.start(JGroupsMessenger.java:397)
> ... 16 more
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9784) GFSH connect should have username option
[ https://issues.apache.org/jira/browse/GEODE-9784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435725#comment-17435725 ] Ivan Godwin commented on GEODE-9784: Also adding --username option to start server command so that the two uses are consistent. > GFSH connect should have username option > > > Key: GEODE-9784 > URL: https://issues.apache.org/jira/browse/GEODE-9784 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Ivan Godwin >Assignee: Ivan Godwin >Priority: Major > Labels: pull-request-available > > When connecting to a secured cluster, --user is available to specify the name > of the user for purpose of authentication and authorization. > - Add --username as option to the connect command that aliases --user, > providing a more intuitively named option -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9402) Automatic Reconnect Failure: Address already in use
[
https://issues.apache.org/jira/browse/GEODE-9402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham reassigned GEODE-9402:
---
Assignee: Bill Burcham
> Automatic Reconnect Failure: Address already in use
> ---
>
> Key: GEODE-9402
> URL: https://issues.apache.org/jira/browse/GEODE-9402
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Juan Ramos
>Assignee: Bill Burcham
>Priority: Major
> Attachments: cluster_logs_gke_latest_54.zip, cluster_logs_pks_121.zip
>
>
> There are 2 locators and 4 servers during the test, once they're all up and
> running the test drops the network connectivity between all members to
> generate a full network partition and cause all members to shutdown and go
> into reconnect mode. Upon reaching the mentioned state, the test
> automatically restores the network connectivity and expects all members to
> automatically go up again and re-form the distributed system.
> This works fine most of the time, and we see every member successfully
> reconnecting to the distributed system:
> {noformat}
> [info 2021/06/23 15:58:12.981 GMT gemfire-cluster-locator-0
> tid=0x87] Reconnect completed.
> [info 2021/06/23 15:58:14.726 GMT gemfire-cluster-locator-1
> tid=0x86] Reconnect completed.
> [info 2021/06/23 15:58:46.702 GMT gemfire-cluster-server-0
> tid=0x94] Reconnect completed.
> [info 2021/06/23 15:58:46.485 GMT gemfire-cluster-server-1
> tid=0x96] Reconnect completed.
> [info 2021/06/23 15:58:46.273 GMT gemfire-cluster-server-2
> tid=0x97] Reconnect completed.
> [info 2021/06/23 15:58:46.902 GMT gemfire-cluster-server-3
> tid=0x95] Reconnect completed.
> {noformat}
> In some rare occasions, though, one of the servers fails during the reconnect
> phase with the following exception:
> {noformat}
> [error 2021/06/09 18:48:52.872 GMT gemfire-cluster-server-1
> tid=0x91] Cache initialization for GemFireCache[id = 575310555; isClosing =
> false; isShutDownAll = false; created = Wed Jun 09 18:46:49 GMT 2021; server
> = false; copyOnRead = false; lockLease = 120; lockTimeout = 60] failed
> because:
> org.apache.geode.GemFireIOException: While starting cache server CacheServer
> on port=40404 client subscription config policy=none client subscription
> config capacity=1 client subscription config overflow directory=.
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.startCacheServers(CacheCreation.java:800)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:599)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:339)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4207)
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:197)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1497)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1449)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2668)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2426)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1277)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:2315)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.uncleanShutdown(GMSMembership.java:1183)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.lambda$forceDisconnect$0(GMSMembership.java:1807)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.net.BindException: Address already in use (Bind failed)
> at java.base/java.net.PlainSocketImpl.socketBind(Native Method)
> at
> java.base/java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:436)
> at java.base/java.net.ServerSocket.bind(ServerSocket.java:395)
> at
> org.apache.geode.internal.net.SCClusterSocketCreator.createServerSocket(SCClusterSocketCreator.java:70)
> at
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:529)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.(AcceptorImpl.java:573)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorBuilder.create(AcceptorB
[jira] [Updated] (GEODE-9784) GFSH connect and start server commands should have username option
[ https://issues.apache.org/jira/browse/GEODE-9784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Godwin updated GEODE-9784: --- Description: When connecting to a secured cluster, --user is available to specify the name of the user for purpose of authentication and authorization. - Add --username as option to the connect command that aliases --user, providing a more intuitively named option - Add --username as option to the start server command that aliases --user was: When connecting to a secured cluster, --user is available to specify the name of the user for purpose of authentication and authorization. - Add --username as option to the connect command that aliases --user, providing a more intuitively named option Priority: Minor (was: Major) Summary: GFSH connect and start server commands should have username option (was: GFSH connect should have username option) > GFSH connect and start server commands should have username option > -- > > Key: GEODE-9784 > URL: https://issues.apache.org/jira/browse/GEODE-9784 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Ivan Godwin >Assignee: Ivan Godwin >Priority: Minor > Labels: pull-request-available > > When connecting to a secured cluster, --user is available to specify the name > of the user for purpose of authentication and authorization. > - Add --username as option to the connect command that aliases --user, > providing a more intuitively named option > - Add --username as option to the start server command that aliases --user -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8411) CI Failure: Jetty9CachingClientServerTest. containersShouldShareDataRemovals() fails with comparison failure
[
https://issues.apache.org/jira/browse/GEODE-8411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17435767#comment-17435767
]
Geode Integration commented on GEODE-8411:
--
Seen on support/1.13 in [distributed-test-openjdk11
#65|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/distributed-test-openjdk11/builds/65]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.5-build.0612/test-results/distributedTest/1635478915/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.5-build.0612/test-artifacts/1635478915/distributedtestfiles-openjdk11-1.13.5-build.0612.tgz].
> CI Failure: Jetty9CachingClientServerTest.
> containersShouldShareDataRemovals() fails with comparison failure
>
>
> Key: GEODE-8411
> URL: https://issues.apache.org/jira/browse/GEODE-8411
> Project: Geode
> Issue Type: Bug
>Reporter: Benjamin P Ross
>Assignee: Benjamin P Ross
>Priority: Major
>
> We saw Jetty9CachingClientServerTest fail with a Comparison failure in a CI
> run.
> {code:java}
> org.apache.geode.session.tests.Jetty9CachingClientServerTest >
> containersShouldShareDataRemovals FAILED
> org.junit.ComparisonFailure: expected:<"[]"> but was:<"[Foo]">
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
