[jira] [Commented] (GEODE-10088) Support ServerGroups in new test frameworks
[ https://issues.apache.org/jira/browse/GEODE-10088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500541#comment-17500541 ] ASF GitHub Bot commented on GEODE-10088: mmartell opened a new pull request #941: URL: https://github.com/apache/geode-native/pull/941 Adds serverGroups to new clicache test framework. -- 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 > Support ServerGroups in new test frameworks > --- > > Key: GEODE-10088 > URL: https://issues.apache.org/jira/browse/GEODE-10088 > Project: Geode > Issue Type: Test > Components: native client >Reporter: Michael Martell >Priority: Minor > > The new integration test framewoks for .NET and C++ do not support server > groups. Adding this support will help in creating a protocol document, as > several messages support groups. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10088) Support ServerGroups in new test frameworks
[ https://issues.apache.org/jira/browse/GEODE-10088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10088: --- Labels: pull-request-available (was: ) > Support ServerGroups in new test frameworks > --- > > Key: GEODE-10088 > URL: https://issues.apache.org/jira/browse/GEODE-10088 > Project: Geode > Issue Type: Test > Components: native client >Reporter: Michael Martell >Priority: Minor > Labels: pull-request-available > > The new integration test framewoks for .NET and C++ do not support server > groups. Adding this support will help in creating a protocol document, as > several messages support groups. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10008) Avoid possible EntryDestroyedException error in wan-copy region command when entry destroyed in partitioned region
[ https://issues.apache.org/jira/browse/GEODE-10008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-10008: - Labels: blocks-1.15.0 needsTriage pull-request-available (was: needsTriage pull-request-available) > Avoid possible EntryDestroyedException error in wan-copy region command when > entry destroyed in partitioned region > -- > > Key: GEODE-10008 > URL: https://issues.apache.org/jira/browse/GEODE-10008 > Project: Geode > Issue Type: Bug > Components: gfsh, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: blocks-1.15.0, needsTriage, pull-request-available > Fix For: 1.16.0 > > > When the wan-copy region command is executed over a partitioned region, it is > possible that sometimes an EntryDestroyedException error is found if, while > reading the entries from the region, one of them is destroyed. > The error has been seen sometimes when running the following test: > WanCopyRegionCommandDUnitTest. > testSuccessfulExecutionWhileRunningOpsOnRegion(true, true). > > Log of the error: > Multiple Failures (2 failures) > org.opentest4j.AssertionFailedError: [ Member | > Status | Message > -- | -- | > --- > alberto-dell(421543):41010 | ERROR | Execution failed. Error: > org.apache.geode.cache.EntryDestroyedException: 26 > alberto-dell(421504):41009 | OK | Entries copied: 2,977 > alberto-dell(421598):41011 | OK | Entries copied: 3,042 > ] > expected: OK > but was: ERROR > java.lang.AssertionError: Suspicious strings were written to the log > during this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in 'dunit_suspect-vm6.log' at line 1883 > [error 2022/02/01 08:58:59.046 CET tid=99] > Exception occurred attempting to wan-copy region > java.util.concurrent.ExecutionException: > org.apache.geode.cache.EntryDestroyedException: 26 > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > at java.util.concurrent.FutureTask.get(FutureTask.java:192) > at > org.apache.geode.cache.wan.internal.WanCopyRegionFunctionService.execute(WanCopyRegionFunctionService.java:90) > at > org.apache.geode.management.internal.cli.functions.WanCopyRegionFunction.executeFunctionInService(WanCopyRegionFunction.java:163) > at > org.apache.geode.management.internal.cli.functions.WanCopyRegionFunction.executeFunction(WanCopyRegionFunction.java:157) > at > org.apache.geode.management.cli.CliFunction.execute(CliFunction.java:37) > at > org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:201) > at > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:382) > at > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:447) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:444) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.doFunctionExecutionThread(ClusterOperationExecutors.java:379) > at > org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) > at java.lang.Thread.run(Thread.java:748) > Caused by: org.apache.geode.cache.EntryDestroyedException: 26 > at > org.apache.geode.internal.cache.NonTXEntry.basicGetEntry(NonTXEntry.java:62) > at > org.apache.geode.internal.cache.NonTXEntry.getRegion(NonTXEntry.java:119) > at > org.apache.geode.internal.cache.NonTXEntry.hashCode(NonTXEntry.java:157) > at java.util.HashMap.hash(HashMap.java:340) > at java.util.HashMap.put(HashMap.java:613) > at java.util.HashSet.add(HashSet.java:220) > at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169) > at java.util.Iterator.forEachRemaining(Iterator.java:116) > at > java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) > at > java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:647) > at > java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:272) > at java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1580) > at
[jira] [Commented] (GEODE-10008) Avoid possible EntryDestroyedException error in wan-copy region command when entry destroyed in partitioned region
[ https://issues.apache.org/jira/browse/GEODE-10008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500528#comment-17500528 ] Geode Integration commented on GEODE-10008: --- Seen on support/1.15 in [distributed-test-openjdk11 #23|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-15-main/jobs/distributed-test-openjdk11/builds/23] ... see [test results|http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.0909/test-results/distributedTest/1646250741/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.0909/test-artifacts/1646250741/distributedtestfiles-openjdk11-1.15.0-build.0909.tgz]. > Avoid possible EntryDestroyedException error in wan-copy region command when > entry destroyed in partitioned region > -- > > Key: GEODE-10008 > URL: https://issues.apache.org/jira/browse/GEODE-10008 > Project: Geode > Issue Type: Bug > Components: gfsh, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.16.0 > > > When the wan-copy region command is executed over a partitioned region, it is > possible that sometimes an EntryDestroyedException error is found if, while > reading the entries from the region, one of them is destroyed. > The error has been seen sometimes when running the following test: > WanCopyRegionCommandDUnitTest. > testSuccessfulExecutionWhileRunningOpsOnRegion(true, true). > > Log of the error: > Multiple Failures (2 failures) > org.opentest4j.AssertionFailedError: [ Member | > Status | Message > -- | -- | > --- > alberto-dell(421543):41010 | ERROR | Execution failed. Error: > org.apache.geode.cache.EntryDestroyedException: 26 > alberto-dell(421504):41009 | OK | Entries copied: 2,977 > alberto-dell(421598):41011 | OK | Entries copied: 3,042 > ] > expected: OK > but was: ERROR > java.lang.AssertionError: Suspicious strings were written to the log > during this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in 'dunit_suspect-vm6.log' at line 1883 > [error 2022/02/01 08:58:59.046 CET tid=99] > Exception occurred attempting to wan-copy region > java.util.concurrent.ExecutionException: > org.apache.geode.cache.EntryDestroyedException: 26 > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > at java.util.concurrent.FutureTask.get(FutureTask.java:192) > at > org.apache.geode.cache.wan.internal.WanCopyRegionFunctionService.execute(WanCopyRegionFunctionService.java:90) > at > org.apache.geode.management.internal.cli.functions.WanCopyRegionFunction.executeFunctionInService(WanCopyRegionFunction.java:163) > at > org.apache.geode.management.internal.cli.functions.WanCopyRegionFunction.executeFunction(WanCopyRegionFunction.java:157) > at > org.apache.geode.management.cli.CliFunction.execute(CliFunction.java:37) > at > org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:201) > at > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:382) > at > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:447) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:444) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.doFunctionExecutionThread(ClusterOperationExecutors.java:379) > at > org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) > at java.lang.Thread.run(Thread.java:748) > Caused by: org.apache.geode.cache.EntryDestroyedException: 26 > at > org.apache.geode.internal.cache.NonTXEntry.basicGetEntry(NonTXEntry.java:62) > at > org.apache.geode.internal.cache.NonTXEntry.getRegion(NonTXEntry.java:119) > at > org.apache.geode.internal.cache.NonTXEntry.hashCode(NonTXEntry.java:157) > at java.util.HashMap.hash(HashMap.java:340) > at java.util.HashMap.put(HashMap.java:613) > at java.util.HashSet.add(HashSet.java:220) > at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169) > at
[jira] [Commented] (GEODE-8825) CI failure: GatewayReceiverMBeanDUnitTest > testMBeanAndProxiesForGatewayReceiverAreRemovedOnDestroy
[
https://issues.apache.org/jira/browse/GEODE-8825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500527#comment-17500527
]
Geode Integration commented on GEODE-8825:
--
Seen on support/1.14 in [distributed-test-openjdk11
#34|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-14-main/jobs/distributed-test-openjdk11/builds/34]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.4-build.0932/test-results/distributedTest/1646269341/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.4-build.0932/test-artifacts/1646269341/distributedtestfiles-openjdk11-1.14.4-build.0932.tgz].
> CI failure: GatewayReceiverMBeanDUnitTest >
> testMBeanAndProxiesForGatewayReceiverAreRemovedOnDestroy
>
>
> Key: GEODE-8825
> URL: https://issues.apache.org/jira/browse/GEODE-8825
> Project: Geode
> Issue Type: Bug
> Components: tests, wan
>Reporter: Jianxia Chen
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: GeodeOperationAPI, flaky, pull-request-available
> Fix For: 1.15.0
>
>
> {code:java}
> org.apache.geode.internal.cache.wan.GatewayReceiverMBeanDUnitTest >
> testMBeanAndProxiesForGatewayReceiverAreRemovedOnDestroy FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.GatewayReceiverMBeanDUnitTest$$Lambda$202/0x0001008f0c40.run
> in VM 0 running on Host c3e48bdac460 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:623)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:447)
> at
> org.apache.geode.internal.cache.wan.GatewayReceiverMBeanDUnitTest.testMBeanAndProxiesForGatewayReceiverAreRemovedOnDestroy(GatewayReceiverMBeanDUnitTest.java:76)
> Caused by:
> java.lang.AssertionError: expected null, but was: GemFire:service=GatewayReceiver,type=Member,member=172.17.0.18(183)-41002>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotNull(Assert.java:756)
> at org.junit.Assert.assertNull(Assert.java:738)
> at org.junit.Assert.assertNull(Assert.java:748)
> at
> org.apache.geode.internal.cache.wan.GatewayReceiverMBeanDUnitTest.verifyMBeanProxiesDoesNotExist(GatewayReceiverMBeanDUnitTest.java:106)
> at
> org.apache.geode.internal.cache.wan.GatewayReceiverMBeanDUnitTest.lambda$testMBeanAndProxiesForGatewayReceiverAreRemovedOnDestroy$bb17a952$3(GatewayReceiverMBeanDUnitTest.java:76)
> {code}
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/704
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0601/test-results/distributedTest/1610390301/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0601/test-artifacts/1610390301/distributedtestfiles-OpenJDK11-1.14.0-build.0601.tgz
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-6183) CI Failure: LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed with ConditionTimeoutException
[ https://issues.apache.org/jira/browse/GEODE-6183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500526#comment-17500526 ] Geode Integration commented on GEODE-6183: -- Seen on support/1.13 in [windows-core-integration-test-openjdk11 #28|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/windows-core-integration-test-openjdk11/builds/28] ... see [test results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.8-build.0656/test-results/integrationTest/1646277285/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.8-build.0656/test-artifacts/1646277285/windows-coreintegrationtestfiles-openjdk11-1.13.8-build.0656.tgz]. > CI Failure: > LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed > with ConditionTimeoutException > > > Key: GEODE-6183 > URL: https://issues.apache.org/jira/browse/GEODE-6183 > Project: Geode > Issue Type: Bug > Components: build >Affects Versions: 1.14.0, 1.15.0 >Reporter: Eric Shu >Assignee: Kirk Lund >Priority: Major > Time Spent: 5h 50m > Remaining Estimate: 0h > > Test failed in > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK8/builds/223 > org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest > > startDeletesStaleControlFiles FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase that > uses org.apache.geode.distributed.LocatorLauncher expected:<[online]> but > was:<[not responding]> within 300 seconds. > Caused by: > org.junit.ComparisonFailure: expected:<[online]> but was:<[not > responding]> -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-4926) ClientServerMiscBCDUnitTest > testSubscriptionWithMixedServersAndOldPeerFeed failed
[
https://issues.apache.org/jira/browse/GEODE-4926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500523#comment-17500523
]
Geode Integration commented on GEODE-4926:
--
Seen on support/1.13 in [upgrade-test-openjdk11
#53|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/53]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.8-build.0655/test-results/upgradeTest/1646216335/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.8-build.0655/test-artifacts/1646216335/upgradetestfiles-openjdk11-1.13.8-build.0655.tgz].
> ClientServerMiscBCDUnitTest > testSubscriptionWithMixedServersAndOldPeerFeed
> failed
> ---
>
> Key: GEODE-4926
> URL: https://issues.apache.org/jira/browse/GEODE-4926
> Project: Geode
> Issue Type: Bug
> Components: ci, client queues
>Reporter: Udo Kohlmeyer
>Priority: Major
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/220
> {code:java}
> org.apache.geode.internal.cache.tier.sockets.ClientServerMiscBCDUnitTest >
> testSubscriptionWithMixedServersAndOldPeerFeed[1] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.NamedRunnable.run in VM 0 running on Host
> d7d1dbe8d1e3 with 5 VMs with version 120
> at org.apache.geode.test.dunit.VM.invoke(VM.java:401)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:370)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:301)
> at
> org.apache.geode.internal.cache.tier.sockets.ClientServerMiscBCDUnitTest.doTestSubscriptionWithMixedServersAndPeerFeed(ClientServerMiscBCDUnitTest.java:214)
> at
> org.apache.geode.internal.cache.tier.sockets.ClientServerMiscBCDUnitTest.testSubscriptionWithMixedServersAndOldPeerFeed(ClientServerMiscBCDUnitTest.java:127)
> Caused by:
> java.lang.AssertionError: expected:<4> but was:<3>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.geode.internal.cache.tier.sockets.ClientServerMiscBCDUnitTest.lambda$doTestSubscriptionWithMixedServersAndPeerFeed$60ce2e92$8(ClientServerMiscBCDUnitTest.java:222)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10099) release 1.12.9
[ https://issues.apache.org/jira/browse/GEODE-10099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500450#comment-17500450 ] ASF subversion and git services commented on GEODE-10099: - Commit e21932a5f56703bff893eb689ec1f1dfc93bc522 in geode-examples's branch refs/heads/support/1.12 from Dick Cavender [ https://gitbox.apache.org/repos/asf?p=geode-examples.git;h=e21932a ] GEODE-10099: Set temporary staging repo This serves two purposes: it gives the RC pipeline a way to get the nexus staging repo id needed for various tests, and it gives the Jenkins server a valid configuration during the voting period. > release 1.12.9 > -- > > Key: GEODE-10099 > URL: https://issues.apache.org/jira/browse/GEODE-10099 > Project: Geode > Issue Type: Task > Components: release >Reporter: Dick Cavender >Priority: Major > > Release to incorporate GEODE-10093. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10099) release 1.12.9
[ https://issues.apache.org/jira/browse/GEODE-10099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500451#comment-17500451 ] ASF subversion and git services commented on GEODE-10099: - Commit 59a81fc15a99ea91faad179d2af897b5dea0cee1 in geode-examples's branch refs/heads/support/1.12 from Dick Cavender [ https://gitbox.apache.org/repos/asf?p=geode-examples.git;h=59a81fc ] GEODE-10099: Bump version to 1.12.9 As part of the Geode Release Process, the geode-examples build number must be rolled forward as work begins on the next release > release 1.12.9 > -- > > Key: GEODE-10099 > URL: https://issues.apache.org/jira/browse/GEODE-10099 > Project: Geode > Issue Type: Task > Components: release >Reporter: Dick Cavender >Priority: Major > > Release to incorporate GEODE-10093. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10099) release 1.12.9
[ https://issues.apache.org/jira/browse/GEODE-10099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500449#comment-17500449 ] ASF subversion and git services commented on GEODE-10099: - Commit 156d8370f35558889787567b599c0f9631182719 in geode-examples's branch refs/heads/support/1.12 from Dick Cavender [ https://gitbox.apache.org/repos/asf?p=geode-examples.git;h=156d837 ] GEODE-10099: Bump version to 1.12.9 As part of the Geode Release Process, the geode-examples build number must be rolled forward as work begins on the next release > release 1.12.9 > -- > > Key: GEODE-10099 > URL: https://issues.apache.org/jira/browse/GEODE-10099 > Project: Geode > Issue Type: Task > Components: release >Reporter: Dick Cavender >Priority: Major > > Release to incorporate GEODE-10093. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10039) BucketProfiles can be stale in rare cases.
[ https://issues.apache.org/jira/browse/GEODE-10039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10039: --- Labels: GeodeOperationAPI blocks-1.15.0 pull-request-available (was: GeodeOperationAPI blocks-1.15.0) > BucketProfiles can be stale in rare cases. > -- > > Key: GEODE-10039 > URL: https://issues.apache.org/jira/browse/GEODE-10039 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.15.0 >Reporter: Mark Hanson >Assignee: Jianxia Chen >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available > > In the case when a server is starting as a member of a partitioned region > during a rebalance, it is possible for the the starting server to not get a > profile removal for a bucket that has been relocated. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10039) BucketProfiles can be stale in rare cases.
[ https://issues.apache.org/jira/browse/GEODE-10039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500436#comment-17500436 ] Jianxia Chen commented on GEODE-10039: -- Proposed solution: When sending the DestroyRegionMessage, send the message to all members, including members that do not have the partitioned region. For members that do not have the partitioned region, they do nothing for this message. For members that are in the process of creating the partitioned region or have already created the partitioned region, it will remove the bucket profile. > BucketProfiles can be stale in rare cases. > -- > > Key: GEODE-10039 > URL: https://issues.apache.org/jira/browse/GEODE-10039 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.15.0 >Reporter: Mark Hanson >Assignee: Jianxia Chen >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0 > > In the case when a server is starting as a member of a partitioned region > during a rebalance, it is possible for the the starting server to not get a > profile removal for a bucket that has been relocated. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10101) release 1.14.4
Dick Cavender created GEODE-10101: - Summary: release 1.14.4 Key: GEODE-10101 URL: https://issues.apache.org/jira/browse/GEODE-10101 Project: Geode Issue Type: Task Components: release Reporter: Dick Cavender Release to incorporate GEODE-10093 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10100) release 1.13.8
Dick Cavender created GEODE-10100: - Summary: release 1.13.8 Key: GEODE-10100 URL: https://issues.apache.org/jira/browse/GEODE-10100 Project: Geode Issue Type: Task Components: release Reporter: Dick Cavender Release to incorporate GEODE-10093 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10099) release 1.12.9
Dick Cavender created GEODE-10099: - Summary: release 1.12.9 Key: GEODE-10099 URL: https://issues.apache.org/jira/browse/GEODE-10099 Project: Geode Issue Type: Task Components: release Reporter: Dick Cavender Release to incorporate GEODE-10093. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10039) BucketProfiles can be stale in rare cases.
[ https://issues.apache.org/jira/browse/GEODE-10039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500431#comment-17500431 ] Jianxia Chen commented on GEODE-10039: -- When a member m1 is moving a primary bucket to the other member m2 due to rebalance. m2 will send a RemoveBucketMessage to m1. When m1 is processing the RemoveBucketMessage, it will send a DestroyRegionMessage to all members hosting the partition region. The DestroyRegionMessage will remove the bucket profile related to m1. Because m1 no longer hosts the primary bucket. Note that this DestroyRegionMessage does not destroy any bucket, it only removes the bucket profile from members that host the partitioned region. When a member m3 is in the process of creating a partitioned region, while the primary bucket is being moved from m1 to m2. It is possible that the DestroyRegionMessage is sent to m2 only. Because when sending the DestroyRegionMessage, m1 does not know that m3 also hosts the partitioned region. Therefore m3 will miss the DestroyRegionMessage and have 2 bucket profiles for m1 and m2 respectively. If later after m3 has successfully created the partitioned region, m2 shuts down, then it will remove the bucket profile from m3. At this point, there is no primary bucket. However, m3 has a stale bucket profile, showing m1 is still hosting the bucket. This can be reproduced in distributed test. > BucketProfiles can be stale in rare cases. > -- > > Key: GEODE-10039 > URL: https://issues.apache.org/jira/browse/GEODE-10039 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.15.0 >Reporter: Mark Hanson >Assignee: Jianxia Chen >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0 > > In the case when a server is starting as a member of a partitioned region > during a rebalance, it is possible for the the starting server to not get a > profile removal for a bucket that has been relocated. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10093) DeltaSession getAttribute method logs an NPE and returns unserialized value when called on attribute with null value
[ https://issues.apache.org/jira/browse/GEODE-10093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett resolved GEODE-10093. --- Resolution: Fixed > DeltaSession getAttribute method logs an NPE and returns unserialized value > when called on attribute with null value > > > Key: GEODE-10093 > URL: https://issues.apache.org/jira/browse/GEODE-10093 > Project: Geode > Issue Type: Bug > Components: http session >Affects Versions: 1.12.2, 1.13.3, 1.14.0, 1.15.0, 1.16.0 >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0 > > > Under certain circumstances, a null value can be set for an attribute which > then throws an NPE when trying to add it to the local map during a > getAttribute call on the session. Prior to 1.12.2 we were responding to this > by removing the entry entirely from the local map which is consistent with > what the base Session class for Catalina does, but starting with 1.12.2 > onward this results in an error message being displayed and the serialized > value being returned rather than the unserialized value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10093) DeltaSession getAttribute method logs an NPE and returns unserialized value when called on attribute with null value
[ https://issues.apache.org/jira/browse/GEODE-10093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett updated GEODE-10093: -- Fix Version/s: 1.12.9 1.13.8 1.14.4 > DeltaSession getAttribute method logs an NPE and returns unserialized value > when called on attribute with null value > > > Key: GEODE-10093 > URL: https://issues.apache.org/jira/browse/GEODE-10093 > Project: Geode > Issue Type: Bug > Components: http session >Affects Versions: 1.12.2, 1.13.3, 1.14.0, 1.15.0, 1.16.0 >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0 > > > Under certain circumstances, a null value can be set for an attribute which > then throws an NPE when trying to add it to the local map during a > getAttribute call on the session. Prior to 1.12.2 we were responding to this > by removing the entry entirely from the local map which is consistent with > what the base Session class for Catalina does, but starting with 1.12.2 > onward this results in an error message being displayed and the serialized > value being returned rather than the unserialized value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10093) DeltaSession getAttribute method logs an NPE and returns unserialized value when called on attribute with null value
[ https://issues.apache.org/jira/browse/GEODE-10093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500412#comment-17500412 ] ASF subversion and git services commented on GEODE-10093: - Commit 086885c12125cccf3319f3016a3c8c9050e71783 in geode's branch refs/heads/support/1.12 from BenjaminPerryRoss [ https://gitbox.apache.org/repos/asf?p=geode.git;h=086885c ] GEODE-10093 - Fixed attr issue in Delta Session (#7405) (#7411) * GEODE-10093 - Fixed attr issue in Delta Session (cherry picked from commit e040759cd1e42df377501cd423967d549ce2bfab) > DeltaSession getAttribute method logs an NPE and returns unserialized value > when called on attribute with null value > > > Key: GEODE-10093 > URL: https://issues.apache.org/jira/browse/GEODE-10093 > Project: Geode > Issue Type: Bug > Components: http session >Affects Versions: 1.12.2, 1.13.3, 1.14.0, 1.15.0, 1.16.0 >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > Under certain circumstances, a null value can be set for an attribute which > then throws an NPE when trying to add it to the local map during a > getAttribute call on the session. Prior to 1.12.2 we were responding to this > by removing the entry entirely from the local map which is consistent with > what the base Session class for Catalina does, but starting with 1.12.2 > onward this results in an error message being displayed and the serialized > value being returned rather than the unserialized value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10093) DeltaSession getAttribute method logs an NPE and returns unserialized value when called on attribute with null value
[ https://issues.apache.org/jira/browse/GEODE-10093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500408#comment-17500408 ] ASF subversion and git services commented on GEODE-10093: - Commit 4cae48cbfecdd2086cd658b8243d6dd4e5bf3cd5 in geode's branch refs/heads/support/1.13 from BenjaminPerryRoss [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4cae48cb ] GEODE-10093 - Fixed attr issue in Delta Session (#7405) (#7412) * GEODE-10093 - Fixed attr issue in Delta Session (cherry picked from commit e040759cd1e42df377501cd423967d549ce2bfab) > DeltaSession getAttribute method logs an NPE and returns unserialized value > when called on attribute with null value > > > Key: GEODE-10093 > URL: https://issues.apache.org/jira/browse/GEODE-10093 > Project: Geode > Issue Type: Bug > Components: http session >Affects Versions: 1.12.2, 1.13.3, 1.14.0, 1.15.0, 1.16.0 >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > Under certain circumstances, a null value can be set for an attribute which > then throws an NPE when trying to add it to the local map during a > getAttribute call on the session. Prior to 1.12.2 we were responding to this > by removing the entry entirely from the local map which is consistent with > what the base Session class for Catalina does, but starting with 1.12.2 > onward this results in an error message being displayed and the serialized > value being returned rather than the unserialized value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10093) DeltaSession getAttribute method logs an NPE and returns unserialized value when called on attribute with null value
[ https://issues.apache.org/jira/browse/GEODE-10093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500407#comment-17500407 ] ASF subversion and git services commented on GEODE-10093: - Commit a45cbe90920c5ea9988a1674e729499abb150db1 in geode's branch refs/heads/support/1.14 from BenjaminPerryRoss [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a45cbe9 ] GEODE-10093 - Fixed attr issue in Delta Session (#7405) (#7413) * GEODE-10093 - Fixed attr issue in Delta Session (cherry picked from commit e040759cd1e42df377501cd423967d549ce2bfab) > DeltaSession getAttribute method logs an NPE and returns unserialized value > when called on attribute with null value > > > Key: GEODE-10093 > URL: https://issues.apache.org/jira/browse/GEODE-10093 > Project: Geode > Issue Type: Bug > Components: http session >Affects Versions: 1.12.2, 1.13.3, 1.14.0, 1.15.0, 1.16.0 >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > Under certain circumstances, a null value can be set for an attribute which > then throws an NPE when trying to add it to the local map during a > getAttribute call on the session. Prior to 1.12.2 we were responding to this > by removing the entry entirely from the local map which is consistent with > what the base Session class for Catalina does, but starting with 1.12.2 > onward this results in an error message being displayed and the serialized > value being returned rather than the unserialized value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10093) DeltaSession getAttribute method logs an NPE and returns unserialized value when called on attribute with null value
[ https://issues.apache.org/jira/browse/GEODE-10093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett updated GEODE-10093: -- Fix Version/s: 1.15.0 1.16.0 > DeltaSession getAttribute method logs an NPE and returns unserialized value > when called on attribute with null value > > > Key: GEODE-10093 > URL: https://issues.apache.org/jira/browse/GEODE-10093 > Project: Geode > Issue Type: Bug > Components: http session >Affects Versions: 1.12.2, 1.13.3, 1.14.0, 1.15.0, 1.16.0 >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > Under certain circumstances, a null value can be set for an attribute which > then throws an NPE when trying to add it to the local map during a > getAttribute call on the session. Prior to 1.12.2 we were responding to this > by removing the entry entirely from the local map which is consistent with > what the base Session class for Catalina does, but starting with 1.12.2 > onward this results in an error message being displayed and the serialized > value being returned rather than the unserialized value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10075) Fix support for jacoco code coverage in Geode build
[ https://issues.apache.org/jira/browse/GEODE-10075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-10075: - Fix Version/s: 1.16.0 > Fix support for jacoco code coverage in Geode build > --- > > Key: GEODE-10075 > URL: https://issues.apache.org/jira/browse/GEODE-10075 > Project: Geode > Issue Type: Bug > Components: build >Reporter: Dan Smith >Priority: Major > Labels: pull-request-available > Fix For: 1.16.0 > > > We haven't been maintaining this gradle build support, but it is useful to be > able to get code coverage from distributed test runs, eg. > ./gradlew geode-core:distributedTest -PcodeCoverage --tests XXX > geode-core:jacocoDistributedTestReport > If you pass -PcodeCoverage it's currently failing. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10094) NPE could be encountered when accessing index manager if cache is closing
[ https://issues.apache.org/jira/browse/GEODE-10094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu resolved GEODE-10094. -- Fix Version/s: 1.16.0 Resolution: Fixed > NPE could be encountered when accessing index manager if cache is closing > - > > Key: GEODE-10094 > URL: https://issues.apache.org/jira/browse/GEODE-10094 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.16.0 > > > The following NPE can be seen when creating index on a partitioned region. > java.lang.NullPointerException > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.PartitionedRegion.populateEmptyIndexes(PartitionedRegion.java:8601) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.PartitionedRegion.createIndexes(PartitionedRegion.java:8519) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.operateOnPartitionedRegion(IndexCreationMsg.java:125) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.process(IndexCreationMsg.java:288) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:446) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.ClusterOperationExecutors.doPartitionRegionThread(ClusterOperationExecutors.java:426) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in java.lang.Thread.run(Thread.java:750) > at > org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:86) > at > org.apache.geode.internal.cache.partitioned.PartitionMessage$PartitionResponse.waitForCacheException(PartitionMessage.java:859) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg$IndexCreationResponse.waitForResult(IndexCreationMsg.java:483) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8418) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8335) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:248) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:206) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:277) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:200) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10094) NPE could be encountered when accessing index manager if cache is closing
[ https://issues.apache.org/jira/browse/GEODE-10094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500390#comment-17500390 ] ASF subversion and git services commented on GEODE-10094: - Commit 262dc08901cfe36c95c833f0b4deb317f1546e97 in geode's branch refs/heads/develop from Eric Shu [ https://gitbox.apache.org/repos/asf?p=geode.git;h=262dc08 ] GEODE-10094: Fix NPE when populating index in partitioned region. (#7410) * IndexUtils.getIndexManager can return null if bucket region is destroyed due to cache is closing. Make sure CancelException is thrown in this case. > NPE could be encountered when accessing index manager if cache is closing > - > > Key: GEODE-10094 > URL: https://issues.apache.org/jira/browse/GEODE-10094 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > The following NPE can be seen when creating index on a partitioned region. > java.lang.NullPointerException > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.PartitionedRegion.populateEmptyIndexes(PartitionedRegion.java:8601) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.PartitionedRegion.createIndexes(PartitionedRegion.java:8519) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.operateOnPartitionedRegion(IndexCreationMsg.java:125) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.process(IndexCreationMsg.java:288) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:446) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.ClusterOperationExecutors.doPartitionRegionThread(ClusterOperationExecutors.java:426) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in java.lang.Thread.run(Thread.java:750) > at > org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:86) > at > org.apache.geode.internal.cache.partitioned.PartitionMessage$PartitionResponse.waitForCacheException(PartitionMessage.java:859) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg$IndexCreationResponse.waitForResult(IndexCreationMsg.java:483) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8418) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8335) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:248) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:206) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:277) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:200) -- This message was sent by
[jira] [Commented] (GEODE-10096) Handshake "acceptance codes" should be an enum class
[
https://issues.apache.org/jira/browse/GEODE-10096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500335#comment-17500335
]
ASF GitHub Bot commented on GEODE-10096:
mreddington commented on a change in pull request #938:
URL: https://github.com/apache/geode-native/pull/938#discussion_r817986522
##
File path: cppcache/src/TcrConnection.cpp
##
@@ -380,33 +386,33 @@ bool TcrConnection::initTcrConnection(
}
switch (acceptanceCode[0]) {
- case REPLY_OK:
- case SUCCESSFUL_SERVER_TO_CLIENT:
+ case static_cast(acceptance_codes::REPLY_OK):
Review comment:
At the very least, an enum class doesn't seem appropriate.
--
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
> Handshake "acceptance codes" should be an enum class
>
>
> Key: GEODE-10096
> URL: https://issues.apache.org/jira/browse/GEODE-10096
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> In the method TcrConnection::initTcrConnection, the following block of code
> appears:
> {code:java}
> switch (acceptanceCode[0]) {
> case REPLY_OK:
> case SUCCESSFUL_SERVER_TO_CLIENT:
> LOGFINER("Handshake reply: %u,%u,%u", acceptanceCode[0],
> serverQueueStatus[0], recvMsgLen2);
> if (isClientNotification)
> readHandshakeInstantiatorMsg(connectTimeout);
> break;
> case REPLY_AUTHENTICATION_FAILED: {
> AuthenticationFailedException ex(
> reinterpret_cast(recvMessage.data()));
> m_conn.reset();
> throwException(ex);
> }
> case REPLY_AUTHENTICATION_REQUIRED: {
> AuthenticationRequiredException ex(
> reinterpret_cast(recvMessage.data()));
> m_conn.reset();
> throwException(ex);
> }
> case REPLY_DUPLICATE_DURABLE_CLIENT: {
> DuplicateDurableClientException ex(
> reinterpret_cast(recvMessage.data()));
> m_conn.reset();
> throwException(ex);
> }
> case REPLY_REFUSED:
> case REPLY_INVALID:
> case UNSUCCESSFUL_SERVER_TO_CLIENT: {
> LOGERROR("Handshake rejected by server[%s]: %s",
> m_endpointObj->name().c_str(),
> reinterpret_cast(recvMessage.data()));
> auto message = std::string("TcrConnection::TcrConnection: ") +
>"Handshake rejected by server: " +
>reinterpret_cast(recvMessage.data());
> CacheServerException ex(message);
> m_conn.reset();
> throw ex;
> }
> {code}
> These response codes are unique to the server handshake, and not used
> anywhere else in the code. We need to remove the #defines for them and put
> them in a proper enum class.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10098) TcrConnection::readMessage should not be explicitly allocating memory
Blake Bender created GEODE-10098: Summary: TcrConnection::readMessage should not be explicitly allocating memory Key: GEODE-10098 URL: https://issues.apache.org/jira/browse/GEODE-10098 Project: Geode Issue Type: Improvement Components: native client Reporter: Blake Bender This method calls new to read an array of bytes, then returns it to the caller, whose responsibility is to delete it (what the heck???). Even better, the memory is deleted in a call to TcrMessage::setData, so not even in the same class. If this memory was a std::vector, we could probably take advantage of move semantics and maybe even improve performance a bit, in addition to avoiding potential leaks and weirdness... -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10096) Handshake "acceptance codes" should be an enum class
[
https://issues.apache.org/jira/browse/GEODE-10096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500327#comment-17500327
]
ASF GitHub Bot commented on GEODE-10096:
pdxcodemonkey commented on a change in pull request #938:
URL: https://github.com/apache/geode-native/pull/938#discussion_r817974196
##
File path: cppcache/src/TcrConnection.cpp
##
@@ -380,33 +386,33 @@ bool TcrConnection::initTcrConnection(
}
switch (acceptanceCode[0]) {
- case REPLY_OK:
- case SUCCESSFUL_SERVER_TO_CLIENT:
+ case static_cast(acceptance_codes::REPLY_OK):
Review comment:
Oh right, we could just cast the byte we read rather than cast in every
case statement. That's way better.
--
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
> Handshake "acceptance codes" should be an enum class
>
>
> Key: GEODE-10096
> URL: https://issues.apache.org/jira/browse/GEODE-10096
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> In the method TcrConnection::initTcrConnection, the following block of code
> appears:
> {code:java}
> switch (acceptanceCode[0]) {
> case REPLY_OK:
> case SUCCESSFUL_SERVER_TO_CLIENT:
> LOGFINER("Handshake reply: %u,%u,%u", acceptanceCode[0],
> serverQueueStatus[0], recvMsgLen2);
> if (isClientNotification)
> readHandshakeInstantiatorMsg(connectTimeout);
> break;
> case REPLY_AUTHENTICATION_FAILED: {
> AuthenticationFailedException ex(
> reinterpret_cast(recvMessage.data()));
> m_conn.reset();
> throwException(ex);
> }
> case REPLY_AUTHENTICATION_REQUIRED: {
> AuthenticationRequiredException ex(
> reinterpret_cast(recvMessage.data()));
> m_conn.reset();
> throwException(ex);
> }
> case REPLY_DUPLICATE_DURABLE_CLIENT: {
> DuplicateDurableClientException ex(
> reinterpret_cast(recvMessage.data()));
> m_conn.reset();
> throwException(ex);
> }
> case REPLY_REFUSED:
> case REPLY_INVALID:
> case UNSUCCESSFUL_SERVER_TO_CLIENT: {
> LOGERROR("Handshake rejected by server[%s]: %s",
> m_endpointObj->name().c_str(),
> reinterpret_cast(recvMessage.data()));
> auto message = std::string("TcrConnection::TcrConnection: ") +
>"Handshake rejected by server: " +
>reinterpret_cast(recvMessage.data());
> CacheServerException ex(message);
> m_conn.reset();
> throw ex;
> }
> {code}
> These response codes are unique to the server handshake, and not used
> anywhere else in the code. We need to remove the #defines for them and put
> them in a proper enum class.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10096) Handshake "acceptance codes" should be an enum class
[
https://issues.apache.org/jira/browse/GEODE-10096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500323#comment-17500323
]
ASF GitHub Bot commented on GEODE-10096:
pivotal-jbarrett commented on a change in pull request #938:
URL: https://github.com/apache/geode-native/pull/938#discussion_r817971407
##
File path: cppcache/src/TcrConnection.cpp
##
@@ -380,33 +386,33 @@ bool TcrConnection::initTcrConnection(
}
switch (acceptanceCode[0]) {
- case REPLY_OK:
- case SUCCESSFUL_SERVER_TO_CLIENT:
+ case static_cast(acceptance_codes::REPLY_OK):
Review comment:
If we have to static cast this switch case values than either
`acceptanceCode[0]` is the wrong type or all the values of `acceptanceType[0]`
are not covered by a single `enum` and the use of `enum` probably isn't
appropriate.
--
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
> Handshake "acceptance codes" should be an enum class
>
>
> Key: GEODE-10096
> URL: https://issues.apache.org/jira/browse/GEODE-10096
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> In the method TcrConnection::initTcrConnection, the following block of code
> appears:
> {code:java}
> switch (acceptanceCode[0]) {
> case REPLY_OK:
> case SUCCESSFUL_SERVER_TO_CLIENT:
> LOGFINER("Handshake reply: %u,%u,%u", acceptanceCode[0],
> serverQueueStatus[0], recvMsgLen2);
> if (isClientNotification)
> readHandshakeInstantiatorMsg(connectTimeout);
> break;
> case REPLY_AUTHENTICATION_FAILED: {
> AuthenticationFailedException ex(
> reinterpret_cast(recvMessage.data()));
> m_conn.reset();
> throwException(ex);
> }
> case REPLY_AUTHENTICATION_REQUIRED: {
> AuthenticationRequiredException ex(
> reinterpret_cast(recvMessage.data()));
> m_conn.reset();
> throwException(ex);
> }
> case REPLY_DUPLICATE_DURABLE_CLIENT: {
> DuplicateDurableClientException ex(
> reinterpret_cast(recvMessage.data()));
> m_conn.reset();
> throwException(ex);
> }
> case REPLY_REFUSED:
> case REPLY_INVALID:
> case UNSUCCESSFUL_SERVER_TO_CLIENT: {
> LOGERROR("Handshake rejected by server[%s]: %s",
> m_endpointObj->name().c_str(),
> reinterpret_cast(recvMessage.data()));
> auto message = std::string("TcrConnection::TcrConnection: ") +
>"Handshake rejected by server: " +
>reinterpret_cast(recvMessage.data());
> CacheServerException ex(message);
> m_conn.reset();
> throw ex;
> }
> {code}
> These response codes are unique to the server handshake, and not used
> anywhere else in the code. We need to remove the #defines for them and put
> them in a proper enum class.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10096) Handshake "acceptance codes" should be an enum class
[
https://issues.apache.org/jira/browse/GEODE-10096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500318#comment-17500318
]
ASF GitHub Bot commented on GEODE-10096:
pdxcodemonkey commented on a change in pull request #938:
URL: https://github.com/apache/geode-native/pull/938#discussion_r817965157
##
File path: cppcache/src/TcrConnection.hpp
##
@@ -33,22 +33,28 @@
#include "util/synchronized_set.hpp"
#define DEFAULT_TIMEOUT_RETRIES 12
-#define PRIMARY_SERVER_TO_CLIENT 101
-#define SECONDARY_SERVER_TO_CLIENT 102
-#define SUCCESSFUL_SERVER_TO_CLIENT 105
-#define UNSUCCESSFUL_SERVER_TO_CLIENT 106
-#define CLIENT_TO_SERVER 100
-#define REPLY_OK 59
-#define REPLY_REFUSED 60
-#define REPLY_INVALID 61
-#define REPLY_SSL_ENABLED 21
-#define REPLY_AUTHENTICATION_REQUIRED 62
-#define REPLY_AUTHENTICATION_FAILED 63
-#define REPLY_DUPLICATE_DURABLE_CLIENT 64
-
-#define SECURITY_CREDENTIALS_NONE 0
-#define SECURITY_CREDENTIALS_NORMAL 1
-#define SECURITY_MULTIUSER_NOTIFICATIONCHANNEL 3
+
+enum class acceptor : ::std::int8_t {
+ CLIENT_TO_SERVER = 100,
+ PRIMARY_SERVER_TO_CLIENT = 101,
+ SECONDARY_SERVER_TO_CLIENT = 102
+};
+enum class acceptance_codes : ::std::int8_t {
+ REPLY_SSL_ENABLED = 21,
+ REPLY_OK = 59,
+ REPLY_REFUSED = 60,
+ REPLY_INVALID = 61,
+ REPLY_AUTHENTICATION_REQUIRED = 62,
+ REPLY_AUTHENTICATION_FAILED = 63,
+ REPLY_DUPLICATE_DURABLE_CLIENT = 64,
+ SUCCESSFUL_SERVER_TO_CLIENT = 105,
+ UNSUCCESSFUL_SERVER_TO_CLIENT = 106
+};
+enum class security : ::std::uint8_t {
+ SECURITY_CREDENTIALS_NONE = 0,
+ SECURITY_CREDENTIALS_NORMAL = 1,
+ SECURITY_MULTIUSER_NOTIFICATIONCHANNEL = 3
+};
Review comment:
Ugh, build break - looks like REPLY_SSL_ENABLED is also used in
ThinClientLocatorHelper :|
--
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
> Handshake "acceptance codes" should be an enum class
>
>
> Key: GEODE-10096
> URL: https://issues.apache.org/jira/browse/GEODE-10096
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> In the method TcrConnection::initTcrConnection, the following block of code
> appears:
> {code:java}
> switch (acceptanceCode[0]) {
> case REPLY_OK:
> case SUCCESSFUL_SERVER_TO_CLIENT:
> LOGFINER("Handshake reply: %u,%u,%u", acceptanceCode[0],
> serverQueueStatus[0], recvMsgLen2);
> if (isClientNotification)
> readHandshakeInstantiatorMsg(connectTimeout);
> break;
> case REPLY_AUTHENTICATION_FAILED: {
> AuthenticationFailedException ex(
> reinterpret_cast(recvMessage.data()));
> m_conn.reset();
> throwException(ex);
> }
> case REPLY_AUTHENTICATION_REQUIRED: {
> AuthenticationRequiredException ex(
> reinterpret_cast(recvMessage.data()));
> m_conn.reset();
> throwException(ex);
> }
> case REPLY_DUPLICATE_DURABLE_CLIENT: {
> DuplicateDurableClientException ex(
> reinterpret_cast(recvMessage.data()));
> m_conn.reset();
> throwException(ex);
> }
> case REPLY_REFUSED:
> case REPLY_INVALID:
> case UNSUCCESSFUL_SERVER_TO_CLIENT: {
> LOGERROR("Handshake rejected by server[%s]: %s",
> m_endpointObj->name().c_str(),
> reinterpret_cast(recvMessage.data()));
> auto message = std::string("TcrConnection::TcrConnection: ") +
>"Handshake rejected by server: " +
>reinterpret_cast(recvMessage.data());
> CacheServerException ex(message);
> m_conn.reset();
> throw ex;
> }
> {code}
> These response codes are unique to the server handshake, and not used
> anywhere else in the code. We need to remove the #defines for them and put
> them in a proper enum class.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10096) Handshake "acceptance codes" should be an enum class
[
https://issues.apache.org/jira/browse/GEODE-10096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500319#comment-17500319
]
ASF GitHub Bot commented on GEODE-10096:
pdxcodemonkey commented on a change in pull request #938:
URL: https://github.com/apache/geode-native/pull/938#discussion_r817965157
##
File path: cppcache/src/TcrConnection.hpp
##
@@ -33,22 +33,28 @@
#include "util/synchronized_set.hpp"
#define DEFAULT_TIMEOUT_RETRIES 12
-#define PRIMARY_SERVER_TO_CLIENT 101
-#define SECONDARY_SERVER_TO_CLIENT 102
-#define SUCCESSFUL_SERVER_TO_CLIENT 105
-#define UNSUCCESSFUL_SERVER_TO_CLIENT 106
-#define CLIENT_TO_SERVER 100
-#define REPLY_OK 59
-#define REPLY_REFUSED 60
-#define REPLY_INVALID 61
-#define REPLY_SSL_ENABLED 21
-#define REPLY_AUTHENTICATION_REQUIRED 62
-#define REPLY_AUTHENTICATION_FAILED 63
-#define REPLY_DUPLICATE_DURABLE_CLIENT 64
-
-#define SECURITY_CREDENTIALS_NONE 0
-#define SECURITY_CREDENTIALS_NORMAL 1
-#define SECURITY_MULTIUSER_NOTIFICATIONCHANNEL 3
+
+enum class acceptor : ::std::int8_t {
+ CLIENT_TO_SERVER = 100,
+ PRIMARY_SERVER_TO_CLIENT = 101,
+ SECONDARY_SERVER_TO_CLIENT = 102
+};
+enum class acceptance_codes : ::std::int8_t {
+ REPLY_SSL_ENABLED = 21,
+ REPLY_OK = 59,
+ REPLY_REFUSED = 60,
+ REPLY_INVALID = 61,
+ REPLY_AUTHENTICATION_REQUIRED = 62,
+ REPLY_AUTHENTICATION_FAILED = 63,
+ REPLY_DUPLICATE_DURABLE_CLIENT = 64,
+ SUCCESSFUL_SERVER_TO_CLIENT = 105,
+ UNSUCCESSFUL_SERVER_TO_CLIENT = 106
+};
+enum class security : ::std::uint8_t {
+ SECURITY_CREDENTIALS_NONE = 0,
+ SECURITY_CREDENTIALS_NORMAL = 1,
+ SECURITY_MULTIUSER_NOTIFICATIONCHANNEL = 3
+};
Review comment:
Ugh, build break - looks like REPLY_SSL_ENABLED is also used in
ThinClientLocatorHelper
--
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
> Handshake "acceptance codes" should be an enum class
>
>
> Key: GEODE-10096
> URL: https://issues.apache.org/jira/browse/GEODE-10096
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> In the method TcrConnection::initTcrConnection, the following block of code
> appears:
> {code:java}
> switch (acceptanceCode[0]) {
> case REPLY_OK:
> case SUCCESSFUL_SERVER_TO_CLIENT:
> LOGFINER("Handshake reply: %u,%u,%u", acceptanceCode[0],
> serverQueueStatus[0], recvMsgLen2);
> if (isClientNotification)
> readHandshakeInstantiatorMsg(connectTimeout);
> break;
> case REPLY_AUTHENTICATION_FAILED: {
> AuthenticationFailedException ex(
> reinterpret_cast(recvMessage.data()));
> m_conn.reset();
> throwException(ex);
> }
> case REPLY_AUTHENTICATION_REQUIRED: {
> AuthenticationRequiredException ex(
> reinterpret_cast(recvMessage.data()));
> m_conn.reset();
> throwException(ex);
> }
> case REPLY_DUPLICATE_DURABLE_CLIENT: {
> DuplicateDurableClientException ex(
> reinterpret_cast(recvMessage.data()));
> m_conn.reset();
> throwException(ex);
> }
> case REPLY_REFUSED:
> case REPLY_INVALID:
> case UNSUCCESSFUL_SERVER_TO_CLIENT: {
> LOGERROR("Handshake rejected by server[%s]: %s",
> m_endpointObj->name().c_str(),
> reinterpret_cast(recvMessage.data()));
> auto message = std::string("TcrConnection::TcrConnection: ") +
>"Handshake rejected by server: " +
>reinterpret_cast(recvMessage.data());
> CacheServerException ex(message);
> m_conn.reset();
> throw ex;
> }
> {code}
> These response codes are unique to the server handshake, and not used
> anywhere else in the code. We need to remove the #defines for them and put
> them in a proper enum class.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10096) Handshake "acceptance codes" should be an enum class
[
https://issues.apache.org/jira/browse/GEODE-10096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500316#comment-17500316
]
ASF GitHub Bot commented on GEODE-10096:
pdxcodemonkey commented on a change in pull request #938:
URL: https://github.com/apache/geode-native/pull/938#discussion_r817962442
##
File path: cppcache/src/TcrConnection.hpp
##
@@ -33,22 +33,28 @@
#include "util/synchronized_set.hpp"
#define DEFAULT_TIMEOUT_RETRIES 12
-#define PRIMARY_SERVER_TO_CLIENT 101
-#define SECONDARY_SERVER_TO_CLIENT 102
-#define SUCCESSFUL_SERVER_TO_CLIENT 105
-#define UNSUCCESSFUL_SERVER_TO_CLIENT 106
-#define CLIENT_TO_SERVER 100
-#define REPLY_OK 59
-#define REPLY_REFUSED 60
-#define REPLY_INVALID 61
-#define REPLY_SSL_ENABLED 21
-#define REPLY_AUTHENTICATION_REQUIRED 62
-#define REPLY_AUTHENTICATION_FAILED 63
-#define REPLY_DUPLICATE_DURABLE_CLIENT 64
-
-#define SECURITY_CREDENTIALS_NONE 0
-#define SECURITY_CREDENTIALS_NORMAL 1
-#define SECURITY_MULTIUSER_NOTIFICATIONCHANNEL 3
+
+enum class acceptor : ::std::int8_t {
+ CLIENT_TO_SERVER = 100,
+ PRIMARY_SERVER_TO_CLIENT = 101,
+ SECONDARY_SERVER_TO_CLIENT = 102
+};
+enum class acceptance_codes : ::std::int8_t {
+ REPLY_SSL_ENABLED = 21,
+ REPLY_OK = 59,
+ REPLY_REFUSED = 60,
+ REPLY_INVALID = 61,
+ REPLY_AUTHENTICATION_REQUIRED = 62,
+ REPLY_AUTHENTICATION_FAILED = 63,
+ REPLY_DUPLICATE_DURABLE_CLIENT = 64,
+ SUCCESSFUL_SERVER_TO_CLIENT = 105,
+ UNSUCCESSFUL_SERVER_TO_CLIENT = 106
+};
+enum class security : ::std::uint8_t {
+ SECURITY_CREDENTIALS_NONE = 0,
+ SECURITY_CREDENTIALS_NORMAL = 1,
+ SECURITY_MULTIUSER_NOTIFICATIONCHANNEL = 3
+};
Review comment:
Really love the separation of concerns here, it's much easier now to
tell in the implementation that the switch statements are correct, for
instance. Quick question - do any of these values need to be in the header?
They don't seem to be referenced anywhere outside of TcrConnection code...
--
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
> Handshake "acceptance codes" should be an enum class
>
>
> Key: GEODE-10096
> URL: https://issues.apache.org/jira/browse/GEODE-10096
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Blake Bender
>Priority: Major
>
> In the method TcrConnection::initTcrConnection, the following block of code
> appears:
> {code:java}
> switch (acceptanceCode[0]) {
> case REPLY_OK:
> case SUCCESSFUL_SERVER_TO_CLIENT:
> LOGFINER("Handshake reply: %u,%u,%u", acceptanceCode[0],
> serverQueueStatus[0], recvMsgLen2);
> if (isClientNotification)
> readHandshakeInstantiatorMsg(connectTimeout);
> break;
> case REPLY_AUTHENTICATION_FAILED: {
> AuthenticationFailedException ex(
> reinterpret_cast(recvMessage.data()));
> m_conn.reset();
> throwException(ex);
> }
> case REPLY_AUTHENTICATION_REQUIRED: {
> AuthenticationRequiredException ex(
> reinterpret_cast(recvMessage.data()));
> m_conn.reset();
> throwException(ex);
> }
> case REPLY_DUPLICATE_DURABLE_CLIENT: {
> DuplicateDurableClientException ex(
> reinterpret_cast(recvMessage.data()));
> m_conn.reset();
> throwException(ex);
> }
> case REPLY_REFUSED:
> case REPLY_INVALID:
> case UNSUCCESSFUL_SERVER_TO_CLIENT: {
> LOGERROR("Handshake rejected by server[%s]: %s",
> m_endpointObj->name().c_str(),
> reinterpret_cast(recvMessage.data()));
> auto message = std::string("TcrConnection::TcrConnection: ") +
>"Handshake rejected by server: " +
>reinterpret_cast(recvMessage.data());
> CacheServerException ex(message);
> m_conn.reset();
> throw ex;
> }
> {code}
> These response codes are unique to the server handshake, and not used
> anywhere else in the code. We need to remove the #defines for them and put
> them in a proper enum class.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10096) Handshake "acceptance codes" should be an enum class
[
https://issues.apache.org/jira/browse/GEODE-10096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-10096:
---
Labels: pull-request-available (was: )
> Handshake "acceptance codes" should be an enum class
>
>
> Key: GEODE-10096
> URL: https://issues.apache.org/jira/browse/GEODE-10096
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> In the method TcrConnection::initTcrConnection, the following block of code
> appears:
> {code:java}
> switch (acceptanceCode[0]) {
> case REPLY_OK:
> case SUCCESSFUL_SERVER_TO_CLIENT:
> LOGFINER("Handshake reply: %u,%u,%u", acceptanceCode[0],
> serverQueueStatus[0], recvMsgLen2);
> if (isClientNotification)
> readHandshakeInstantiatorMsg(connectTimeout);
> break;
> case REPLY_AUTHENTICATION_FAILED: {
> AuthenticationFailedException ex(
> reinterpret_cast(recvMessage.data()));
> m_conn.reset();
> throwException(ex);
> }
> case REPLY_AUTHENTICATION_REQUIRED: {
> AuthenticationRequiredException ex(
> reinterpret_cast(recvMessage.data()));
> m_conn.reset();
> throwException(ex);
> }
> case REPLY_DUPLICATE_DURABLE_CLIENT: {
> DuplicateDurableClientException ex(
> reinterpret_cast(recvMessage.data()));
> m_conn.reset();
> throwException(ex);
> }
> case REPLY_REFUSED:
> case REPLY_INVALID:
> case UNSUCCESSFUL_SERVER_TO_CLIENT: {
> LOGERROR("Handshake rejected by server[%s]: %s",
> m_endpointObj->name().c_str(),
> reinterpret_cast(recvMessage.data()));
> auto message = std::string("TcrConnection::TcrConnection: ") +
>"Handshake rejected by server: " +
>reinterpret_cast(recvMessage.data());
> CacheServerException ex(message);
> m_conn.reset();
> throw ex;
> }
> {code}
> These response codes are unique to the server handshake, and not used
> anywhere else in the code. We need to remove the #defines for them and put
> them in a proper enum class.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10012) Avoid retries for non-HA function execution
[
https://issues.apache.org/jira/browse/GEODE-10012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500310#comment-17500310
]
ASF GitHub Bot commented on GEODE-10012:
pivotal-jbarrett commented on a change in pull request #920:
URL: https://github.com/apache/geode-native/pull/920#discussion_r817929905
##
File path: cppcache/src/ExecutionImpl.hpp
##
@@ -78,6 +78,20 @@ class ExecutionImpl {
static void addResults(std::shared_ptr& collector,
const std::shared_ptr& results);
+ protected:
+ std::shared_ptr executeOnPool(
+ const std::string& func, FunctionAttributes funcAttrs, int32_t
retryAttempts,
+ std::chrono::milliseconds timeout = DEFAULT_QUERY_RESPONSE_TIMEOUT);
+
+ void executeOnAllServers(
+ const std::string& func, FunctionAttributes funcAttrs,
+ std::chrono::milliseconds timeout = DEFAULT_QUERY_RESPONSE_TIMEOUT);
+
+ FunctionAttributes getFunctionAttributes(
+ const std::string& func);
Review comment:
Please use full names, like `functionId` here.
##
File path: cppcache/src/ExecutionImpl.hpp
##
@@ -78,6 +78,20 @@ class ExecutionImpl {
static void addResults(std::shared_ptr& collector,
const std::shared_ptr& results);
+ protected:
+ std::shared_ptr executeOnPool(
+ const std::string& func, FunctionAttributes funcAttrs, int32_t
retryAttempts,
+ std::chrono::milliseconds timeout = DEFAULT_QUERY_RESPONSE_TIMEOUT);
+
+ void executeOnAllServers(
+ const std::string& func, FunctionAttributes funcAttrs,
+ std::chrono::milliseconds timeout = DEFAULT_QUERY_RESPONSE_TIMEOUT);
+
+ FunctionAttributes getFunctionAttributes(
+ const std::string& func);
+ FunctionAttributes updateFunctionAttributes(const std::string );
+ GfErrType getFuncAttributes(const std::string& func, FunctionAttributes&
attr);
Review comment:
`functionId` and `functionAttributes` please.
##
File path: cppcache/src/ExecutionImpl.cpp
##
@@ -329,26 +281,23 @@ std::shared_ptr ExecutionImpl::execute(
"Execution::execute: Transaction function execution on pool is not "
"supported");
}
-if (m_allServer == false) {
- executeOnPool(
- func, isHAHasResultOptimizeForWrite,
- (isHAHasResultOptimizeForWrite & 1) ? m_pool->getRetryAttempts() : 0,
- timeout);
- if (serverHasResult == true) {
-// ExecutionImpl::addResults(m_rc, rs);
+if (!m_allServer) {
+ executeOnPool(func, attrs, attrs.isHA() ? m_pool->getRetryAttempts() : 0,
+timeout);
+ if (attrs.hasResult()) {
m_rc->endResults();
}
return m_rc;
}
-executeOnAllServers(func, isHAHasResultOptimizeForWrite, timeout);
+executeOnAllServers(func, attrs, timeout);
} else {
throw IllegalStateException("Execution::execute: should not be here");
}
return m_rc;
}
-GfErrType ExecutionImpl::getFuncAttributes(
-const std::string& func, std::shared_ptr>* attr) {
+GfErrType ExecutionImpl::getFuncAttributes(const std::string& func,
+ FunctionAttributes& attr) {
Review comment:
Does it make more sense to have the function return `FunctionAttributes`
and `throw` exceptions?
##
File path: cppcache/src/ExecutionImpl.cpp
##
@@ -406,24 +355,25 @@ void ExecutionImpl::addResults(
}
void ExecutionImpl::executeOnAllServers(const std::string& func,
-uint8_t getResult,
+FunctionAttributes funcAttrs,
Review comment:
Is the copy construction cheaper or necessary here rather than a `const
&`?
##
File path: cppcache/src/ThinClientRegion.cpp
##
@@ -2907,18 +2911,20 @@ void ThinClientRegion::executeFunction(
rc->clearResults();
failedNodes->clear();
} else if (err == GF_TIMEOUT) {
-LOGINFO("function timeout. Name: %s, timeout: %s, params: %" PRIu8
-", "
-"retryAttempts: %d ",
-func.c_str(), to_string(timeout).c_str(), getResult,
-retryAttempts);
+LOGINFO(
+"function timeout. Name: %s, timeout: %s, FunctionState: %" PRIu8
+", "
+"retryAttempts: %d ",
Review comment:
Cleanup the formatting here.
##
File path: cppcache/src/FunctionExecution.cpp
##
@@ -0,0 +1,162 @@
+/*
+ * 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
[jira] [Assigned] (GEODE-10091) Benchmark instability in RedisZaddAndZremBenchmark
[
https://issues.apache.org/jira/browse/GEODE-10091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Zoerner reassigned GEODE-10091:
Assignee: Eric Zoerner
> Benchmark instability in RedisZaddAndZremBenchmark
> --
>
> Key: GEODE-10091
> URL: https://issues.apache.org/jira/browse/GEODE-10091
> Project: Geode
> Issue Type: Bug
> Components: benchmarks, redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Eric Zoerner
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> This is ITERATION 1 of benchmarking against baseline.
> RedisGetBenchmark avg ops/sec
> Baseline:428358.55 Test:446241.49 Difference: +4.2%
> avg latency
> Baseline: 1678809.55 Test: 1611045.34 Difference: -4.0%
> RedisHgetBenchmark avg ops/sec
> Baseline:438535.25 Test:441078.97 Difference: +0.6%
> avg latency
> Baseline: 1638968.92 Test: 1630999.16 Difference: -0.5%
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:191331.54 Test:186806.37 Difference: -2.4%
> avg latency
> Baseline: 3759694.09 Test: 3850396.04 Difference: +2.4%
> RedisHsetBenchmark avg ops/sec
> Baseline:308079.41 Test:303715.78 Difference: -1.4%
> avg latency
> Baseline: 2332102.91 Test: 2367639.93 Difference: +1.5%
> RedisSetBenchmark avg ops/sec
> Baseline:318147.74 Test:326996.22 Difference: +2.8%
> avg latency
> Baseline: 2263687.57 Test: 2198181.68 Difference: -2.9%
> RedisWeightedHsetAndHgetBenchmark avg ops/sec
> Baseline:390383.79 Test:385565.48 Difference: -1.2%
> avg latency
> Baseline: 1842561.96 Test: 1864716.09 Difference: +1.2%
> RedisWeightedZaddAndZrangeBenchmark avg ops/sec
> Baseline:375078.82 Test:350886.03 Difference: -6.5%
> avg latency
> Baseline: 1917476.15 Test: 2049452.87 Difference: +6.9%
> RedisZaddAndZremBenchmark avg ops/sec
> Baseline:124763.60 Test:118600.72 Difference: -4.9%
> avg latency
> Baseline: 5766048.34 Test: 6065491.13 Difference: +5.2%
> RedisZaddBenchmark avg ops/sec
> Baseline:432494.29 Test:438594.53 Difference: +1.4%
> avg latency
> Baseline: 1662639.09 Test: 1639906.18 Difference: -1.4%
> RedisZrangeBenchmark avg ops/sec
> Baseline:295523.77 Test:340381.87 Difference: +15.2%
> avg latency
> Baseline: 2433250.54 Test: 2112961.66 Difference: -13.2%
> RedisZrangeByScoreBenchmark avg ops/sec
> Baseline:285836.33 Test:356142.91 Difference: +24.6%
> avg latency
> Baseline: 2515708.23 Test: 2019249.68 Difference: -19.7%
> This is ITERATION 2 of benchmarking against baseline.
> RedisWeightedZaddAndZrangeBenchmark avg ops/sec
> Baseline:358570.33 Test:348012.02 Difference: -2.9%
> avg latency
> Baseline: 2005804.05 Test: 2066535.24 Difference: +3.0%
> RedisZaddAndZremBenchmark avg ops/sec
> Baseline:122900.38 Test:115226.22 Difference: -6.2%
> avg latency
> Baseline: 5858357.13 Test: 6243018.38 Difference: +6.6%
> This is ITERATION 3 of benchmarking against baseline.
> RedisZaddAndZremBenchmark avg ops/sec
> Baseline:125677.36 Test:118359.94 Difference: -5.8%
> avg latency
> Baseline: 5721859.26 Test: 6082944.28 Difference: +6.3%
> This is ITERATION 4 of benchmarking against baseline.
>
[jira] [Commented] (GEODE-10093) DeltaSession getAttribute method logs an NPE and returns unserialized value when called on attribute with null value
[ https://issues.apache.org/jira/browse/GEODE-10093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500304#comment-17500304 ] ASF subversion and git services commented on GEODE-10093: - Commit 03134ff8f9ae9088e6ad3d18f60e9e7fbcfcbf23 in geode's branch refs/heads/support/1.15 from BenjaminPerryRoss [ https://gitbox.apache.org/repos/asf?p=geode.git;h=03134ff ] GEODE-10093 - Fixed attr issue in Delta Session (#7405) (#7414) * GEODE-10093 - Fixed attr issue in Delta Session (cherry picked from commit e040759cd1e42df377501cd423967d549ce2bfab) > DeltaSession getAttribute method logs an NPE and returns unserialized value > when called on attribute with null value > > > Key: GEODE-10093 > URL: https://issues.apache.org/jira/browse/GEODE-10093 > Project: Geode > Issue Type: Bug > Components: http session >Affects Versions: 1.12.2, 1.13.3, 1.14.0, 1.15.0, 1.16.0 >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > Labels: needsTriage, pull-request-available > > Under certain circumstances, a null value can be set for an attribute which > then throws an NPE when trying to add it to the local map during a > getAttribute call on the session. Prior to 1.12.2 we were responding to this > by removing the entry entirely from the local map which is consistent with > what the base Session class for Catalina does, but starting with 1.12.2 > onward this results in an error message being displayed and the serialized > value being returned rather than the unserialized value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10097) Do not use Thread.sleep in MessageDispatcher for re-authentication feature
[ https://issues.apache.org/jira/browse/GEODE-10097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-10097: Labels: GeodeOperationAPI (was: ) > Do not use Thread.sleep in MessageDispatcher for re-authentication feature > -- > > Key: GEODE-10097 > URL: https://issues.apache.org/jira/browse/GEODE-10097 > Project: Geode > Issue Type: Improvement > Components: client queues, client/server >Reporter: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI > > MessageDispatcher uses Thread.sleep and wakes up intervals to recheck > authorization to see if new subject has re-logged in or not, if not, it will > call "authorize" again and again till timeout. Suggest using "wait/notify" > mechanism to wait for the subject to be updated, this way we don't use > Thread.sleep and not place unnecessary calls to the security manager. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10012) Avoid retries for non-HA function execution
[
https://issues.apache.org/jira/browse/GEODE-10012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500289#comment-17500289
]
ASF GitHub Bot commented on GEODE-10012:
pdxcodemonkey commented on a change in pull request #920:
URL: https://github.com/apache/geode-native/pull/920#discussion_r803908544
##
File path: cppcache/integration/test/FunctionExecutionTest.cpp
##
@@ -74,6 +99,9 @@ class TestResultCollector : public ResultCollector {
}
virtual void addResult(const std::shared_ptr ) override {
+LOGINFO("Before mutex lock!");
+std::lock_guard lock{mutex_};
+LOGINFO("Adding a new result!");
Review comment:
Do we really wish to log this at INFO level? Looks more like a
DEBUG-level message to me...
##
File path: cppcache/src/ExecutionImpl.hpp
##
@@ -100,29 +114,18 @@ class ExecutionImpl {
m_allServer(allServer),
m_pool(pool),
m_authenticatedView(authenticatedView) {}
+ protected:
+
std::shared_ptr m_routingObj;
Review comment:
You've essentially rewritten the class already, it would be a shame not
to go ahead and properly rename the member variables.
##
File path: cppcache/src/TcrMessage.cpp
##
@@ -1184,12 +1184,11 @@ void TcrMessage::handleByteArrayResponse(
input.readInt32();
input.advanceCursor(1); // ignore byte
-if (!m_functionAttributes) {
- m_functionAttributes = std::make_shared>();
-}
-m_functionAttributes->push_back(input.read());
-m_functionAttributes->push_back(input.read());
-m_functionAttributes->push_back(input.read());
+bool hasResult = input.read() != 0;
+bool isHA = input.read() != 0;
+bool optimizeForWrite = input.read() != 0;
+m_functionAttributes =
+FunctionAttributes{isHA, hasResult, optimizeForWrite};
Review comment:
Just pausing for a minute to think about how hateful it was to have this
encoded as a vector with no indication of meaning whatsoever. This is
a huge improvement in readability, thanks!
##
File path: cppcache/integration/test/FunctionExecutionTest.cpp
##
@@ -74,6 +99,9 @@ class TestResultCollector : public ResultCollector {
}
virtual void addResult(const std::shared_ptr ) override {
+LOGINFO("Before mutex lock!");
+std::lock_guard lock{mutex_};
+LOGINFO("Adding a new result!");
Review comment:
Actually no, we shouldn't be using any of the LOG* macros in integration
test code at all. Please remove.
##
File path: cppcache/src/FunctionAttributes.hpp
##
@@ -0,0 +1,87 @@
+/*
+ * 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.
+ */
+
+#pragma once
+
+#ifndef GEODE_FUNCTIONATTRIBUTES_H_
+#define GEODE_FUNCTIONATTRIBUTES_H_
+
+#include
+
+namespace apache {
+namespace geode {
+namespace client {
+
+class FunctionAttributes {
+ public:
+ enum : uint8_t {
Review comment:
Does this enum need to be public? You have accessors for the individual
values already, it seems like a thing you'd want to hide.
##
File path: cppcache/src/ExecutionImpl.cpp
##
@@ -434,31 +384,15 @@ void ExecutionImpl::executeOnAllServers(const
std::string& func,
}
}
std::shared_ptr ExecutionImpl::executeOnPool(
-const std::string& func, uint8_t getResult, int32_t retryAttempts,
-std::chrono::milliseconds timeout) {
+const std::string& func, FunctionAttributes funcAttrs,
+int32_t retryAttempts, std::chrono::milliseconds timeout) {
ThinClientPoolDM* tcrdm = dynamic_cast(m_pool.get());
if (tcrdm == nullptr) {
throw IllegalArgumentException(
"Execute: pool cast to ThinClientPoolDM failed");
}
int32_t attempt = 0;
- // auto csArray = tcrdm->getServers();
-
- // if (csArray != nullptr && csArray->length() != 0) {
- // for (int i = 0; i < csArray->length(); i++)
- // {
- // auto cs = csArray[i];
- //TcrEndpoint *ep = nullptr;
- ///*
- //std::string endpointStr =
- //Utils::convertHostToCanonicalForm(cs->value().c_str()
- //);
- //*/
- //ep = tcrdm->addEP(cs->value().c_str());
-
[jira] [Created] (GEODE-10097) Do not use Thread.sleep in MessageDispatcher for re-authentication feature
Jinmei Liao created GEODE-10097: --- Summary: Do not use Thread.sleep in MessageDispatcher for re-authentication feature Key: GEODE-10097 URL: https://issues.apache.org/jira/browse/GEODE-10097 Project: Geode Issue Type: Improvement Components: client queues, client/server Reporter: Jinmei Liao MessageDispatcher uses Thread.sleep and wakes up intervals to recheck authorization to see if new subject has re-logged in or not, if not, it will call "authorize" again and again till timeout. Suggest using "wait/notify" mechanism to wait for the subject to be updated, this way we don't use Thread.sleep and not place unnecessary calls to the security manager. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9951) Implement RPOP
[ https://issues.apache.org/jira/browse/GEODE-9951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9951: -- Labels: pull-request-available (was: ) > Implement RPOP > -- > > Key: GEODE-9951 > URL: https://issues.apache.org/jira/browse/GEODE-9951 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Bala Tripura Sundari Kaza Venkata >Priority: Major > Labels: pull-request-available > > Implement the [RPOP|https://redis.io/commands/rpop] command. > > +Acceptance Criteria+ > The command has been implemented along with appropriate unit and system tests. > > The command has been tested using the redis-cli tool and verified against > native redis. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10017) Fix new ITs unstability for TCs that involve members restart
[
https://issues.apache.org/jira/browse/GEODE-10017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500255#comment-17500255
]
ASF GitHub Bot commented on GEODE-10017:
pdxcodemonkey commented on a change in pull request #919:
URL: https://github.com/apache/geode-native/pull/919#discussion_r817836093
##
File path: cppcache/integration/test/FunctionExecutionTest.cpp
##
@@ -324,7 +324,9 @@ TEST(FunctionExecutionTest,
testThatFunctionExecutionThrowsExceptionNonHA) {
.withType("PARTITION")
.execute();
- cluster.getServers()[2].stop();
+ auto = cluster.getServers()[2];
+ targetServer.stop();
+ targetServer.wait();
Review comment:
Why this separation of concerns between stop() and wait()? Is there
ever a circumstance where we call stop() and don't intend for the process to
actually be terminated yet when the function returns?
##
File path: cppcache/integration/test/PdxInstanceTest.cpp
##
@@ -395,9 +395,8 @@ TEST(PdxInstanceTest, testInstancePutAfterRestart) {
cv_status.wait(lock, [] { return !status; });
}
- std::this_thread::sleep_for(std::chrono::seconds{30});
-
for (auto& server : cluster.getServers()) {
+server.wait();
Review comment:
Okay I see this used separately here in several places, but... would it
be necessary to call wait() in the other places if stop() just actually made
sure the process was terminated?
--
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
> Fix new ITs unstability for TCs that involve members restart
>
>
> Key: GEODE-10017
> URL: https://issues.apache.org/jira/browse/GEODE-10017
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> *GIVEN* an integration TC on which a server restart needs to be restarted
> *WHEN* the server is starting up again
> *THEN* +{color:#172b4d}it might{color}+{color:#172b4d} happen that the TC
> gets stuck{color}
>
> *Additional information.* This issue does not always happens, and I've seen
> it happening more frequently with the latest version of Geode server (1.15.0)
> Some examples of this TC are:
> * RegisterKeysTest.RegisterKeySetAndClusterRestart
> * PartitionRegionWithRedundancyTest.putgetWithSingleHop
> * ···
> Also, this is normally the exec flow for the TCs that get stuck:
> # Setup cluster
> # Do TC specific ops
> # Stop server(s)/Cluster shutdown
> # Start server(s)
> In all cases, the server gets stuck at step 4
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10085) Multiple Locators Not Working in New .NET Test Framework
[ https://issues.apache.org/jira/browse/GEODE-10085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500251#comment-17500251 ] ASF GitHub Bot commented on GEODE-10085: mmartell merged pull request #936: URL: https://github.com/apache/geode-native/pull/936 -- 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 > Multiple Locators Not Working in New .NET Test Framework > > > Key: GEODE-10085 > URL: https://issues.apache.org/jira/browse/GEODE-10085 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: needsTriage, pull-request-available > > If a cluster with more than one locator is used in the new .NET test > framework, the test will fail. The failure results from trying to start > JmxManager when it is already running. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10085) Multiple Locators Not Working in New .NET Test Framework
[ https://issues.apache.org/jira/browse/GEODE-10085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17500250#comment-17500250 ] ASF subversion and git services commented on GEODE-10085: - Commit 04d18c380dea2bde30d3876de68f958513902b82 in geode-native's branch refs/heads/develop from Michael Martell [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=04d18c3 ] GEODE-10085: Don't start JmxManager if already running (#936) * Don't start JmxManager if already started * Fix broken StartLocators() and StartServers() > Multiple Locators Not Working in New .NET Test Framework > > > Key: GEODE-10085 > URL: https://issues.apache.org/jira/browse/GEODE-10085 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: needsTriage, pull-request-available > > If a cluster with more than one locator is used in the new .NET test > framework, the test will fail. The failure results from trying to start > JmxManager when it is already running. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9954) Implement RPUSH
[ https://issues.apache.org/jira/browse/GEODE-9954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9954: -- Labels: pull-request-available (was: ) > Implement RPUSH > --- > > Key: GEODE-9954 > URL: https://issues.apache.org/jira/browse/GEODE-9954 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Priority: Major > Labels: pull-request-available > > Implement the [RPUSH|https://redis.io/commands/rpush] command. > > +Acceptance Criteria+ > The command has been implemented along with appropriate unit and system tests. > > The command has been tested using the redis-cli tool and verified against > native redis. -- This message was sent by Atlassian Jira (v8.20.1#820001)
