[jira] [Commented] (GEODE-9340) Benchmark instability in PartitionedPutLongBenchmark
[
https://issues.apache.org/jira/browse/GEODE-9340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418590#comment-17418590
]
Geode Integration commented on GEODE-9340:
--
Seen in [benchmark-base
#205|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/205].
> Benchmark instability in PartitionedPutLongBenchmark
>
>
> Key: GEODE-9340
> URL: https://issues.apache.org/jira/browse/GEODE-9340
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Sarah Abbey
>Assignee: Hale Bales
>Priority: Major
> Labels: pull-request-available
>
> PartitionedPutLongBenchmark failed in CI
> (https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/6):
> {code:java}
> This is ITERATION 1 of benchmarking against baseline.
> P2pPartitionedGetBenchmark avg ops/sec
> Baseline:825011.38 Test:835847.67 Difference: +1.3%
> avg latency
> Baseline:871392.31 Test:859444.66 Difference: -1.4%
> P2pPartitionedPutBenchmark avg ops/sec
> Baseline:123838.43 Test:122686.30 Difference: -0.9%
> avg latency
> Baseline: 6015719.73 Test: 6119472.19 Difference: +1.7%
> P2pPartitionedPutBytesBenchmark avg ops/sec
> Baseline:174887.77 Test:171040.93 Difference: -2.2%
> avg latency
> Baseline: 4145337.60 Test: 4236159.60 Difference: +2.2%
> PartitionedFunctionExecutionBenchmark avg ops/sec
> Baseline:248635.36 Test:261498.94 Difference: +5.2%
> avg latency
> Baseline:867122.63 Test:824550.34 Difference: -4.9%
> PartitionedFunctionExecutionWithArgumentsBenchmark avg ops/sec
> Baseline:280071.19 Test:275305.31 Difference: -1.7%
> avg latency
> Baseline: 1026643.12 Test: 1044307.43 Difference: +1.7%
> PartitionedFunctionExecutionWithFiltersBenchmark avg ops/sec
> Baseline:301416.23 Test:304317.30 Difference: +1.0%
> avg latency
> Baseline: 1908390.88 Test: 1890040.46 Difference: -1.0%
> PartitionedGetBenchmark avg ops/sec
> Baseline:790800.52 Test:784514.74 Difference: -0.8%
> avg latency
> Baseline:908357.58 Test:915790.96 Difference: +0.8%
> PartitionedGetLongBenchmark avg ops/sec
> Baseline: 1020821.32 Test:996529.93 Difference: -2.4%
> avg latency
> Baseline:703761.09 Test:720744.36 Difference: +2.4%
> PartitionedGetStringBenchmark avg ops/sec
> Baseline: 1028992.93 Test: 1010447.47 Difference: -1.8%
> avg latency
> Baseline:698009.55 Test:710765.29 Difference: +1.8%
> PartitionedIndexedQueryBenchmark avg ops/sec
> Baseline: 30868.78 Test: 31478.90 Difference: +2.0%
> avg latency
> Baseline: 18670093.21 Test: 18278083.16 Difference: -2.1%
> PartitionedNonIndexedQueryBenchmark avg ops/sec
> Baseline:99.45 Test: 101.97 Difference: +2.5%
> avg latency
> Baseline: 723415530.75 Test: 705653061.86 Difference: -2.5%
> PartitionedPutAllBenchmark avg ops/sec
> Baseline: 7921.61 Test: 7816.66 Difference: -1.3%
> avg latency
> Baseline: 18172638.37 Test: 18416169.28 Difference: +1.3%
> PartitionedPutAllLongBenchmark avg ops/sec
> Baseline: 1379.53 Test: 1169.16 Difference: -15.2%
> avg latency
> Baseline: 105140260.44 Test: 123722914.94 Difference: +17.7%
> PartitionedPutBenchmark avg ops/sec
> Baseline:474986.11 Test:467924.19 Difference: -1.5%
>
[jira] [Commented] (GEODE-9302) Benchmark instability in PartitionedPutStringBenchmark
[
https://issues.apache.org/jira/browse/GEODE-9302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418589#comment-17418589
]
Geode Integration commented on GEODE-9302:
--
Seen in [benchmark-base
#205|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/205].
> Benchmark instability in PartitionedPutStringBenchmark
> --
>
> Key: GEODE-9302
> URL: https://issues.apache.org/jira/browse/GEODE-9302
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Priority: Major
>
> A benchmark failure due to the recently-introduced
> PartitionedPutStringBenchmark was observed:
> {noformat}
> This is ITERATION 1 of benchmarking against baseline.
> P2pPartitionedGetBenchmark avg ops/sec
> Baseline:853001.60 Test:867151.67 Difference: +1.7%
> avg latency
> Baseline:842007.55 Test:828545.06 Difference: -1.6%
> P2pPartitionedPutBenchmark avg ops/sec
> Baseline:128283.47 Test:126510.92 Difference: -1.4%
> avg latency
> Baseline: 5785619.62 Test: 5915913.49 Difference: +2.3%
> P2pPartitionedPutBytesBenchmark avg ops/sec
> Baseline:175658.08 Test:174865.97 Difference: -0.5%
> avg latency
> Baseline: 4130071.43 Test: 4130753.09 Difference: +0.0%
>PartitionedFunctionExecutionBenchmark avg ops/sec
> Baseline:254788.26 Test:268132.99 Difference: +5.2%
> avg latency
> Baseline:846158.41 Test:804199.42 Difference: -5.0%
> PartitionedFunctionExecutionWithArgumentsBenchmark avg ops/sec
> Baseline:278669.87 Test:281504.58 Difference: +1.0%
> avg latency
> Baseline: 1031826.82 Test: 1021314.54 Difference: -1.0%
> PartitionedFunctionExecutionWithFiltersBenchmark avg ops/sec
> Baseline:372204.82 Test:348815.81 Difference: -6.3%
> avg latency
> Baseline: 1545217.38 Test: 1649706.37 Difference: +6.8%
> PartitionedGetBenchmark avg ops/sec
> Baseline:823740.09 Test:819044.99 Difference: -0.6%
> avg latency
> Baseline:872172.75 Test:877580.02 Difference: +0.6%
> PartitionedGetLongBenchmark avg ops/sec
> Baseline: 1047221.43 Test: 1045565.89 Difference: -0.2%
> avg latency
> Baseline:685757.55 Test:687005.43 Difference: +0.2%
>PartitionedGetStringBenchmark avg ops/sec
> Baseline: 1055904.14 Test: 1045420.73 Difference: -1.0%
> avg latency
> Baseline:680031.44 Test:687045.15 Difference: +1.0%
> PartitionedIndexedQueryBenchmark avg ops/sec
> Baseline: 31596.35 Test: 31653.48 Difference: +0.2%
> avg latency
> Baseline: 18221302.10 Test: 18216097.86 Difference: -0.0%
> PartitionedNonIndexedQueryBenchmark avg ops/sec
> Baseline:95.78 Test: 100.35 Difference: +4.8%
> avg latency
> Baseline: 750871203.78 Test: 716853923.95 Difference: -4.5%
> PartitionedPutAllBenchmark avg ops/sec
> Baseline: 8675.75 Test: 8628.10 Difference: -0.5%
> avg latency
> Baseline: 16595044.73 Test: 16685258.91 Difference: +0.5%
> PartitionedPutAllLongBenchmark avg ops/sec
> Baseline: 1382.38 Test: 1380.50 Difference: -0.1%
> avg latency
> Baseline: 104866853.92 Test: 104775538.34 Difference: -0.1%
> PartitionedPutBenchmark avg ops/sec
> Baseline:491790.40 Test:479926.75 Difference: -2.4%
> avg latency
> Baseline: 1461947.23 Test: 1497519.77 Difference: +2.4%
>
[jira] [Commented] (GEODE-9340) Benchmark instability in PartitionedPutLongBenchmark
[
https://issues.apache.org/jira/browse/GEODE-9340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418592#comment-17418592
]
Geode Integration commented on GEODE-9340:
--
Seen in [benchmark-base
#203|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/203].
> Benchmark instability in PartitionedPutLongBenchmark
>
>
> Key: GEODE-9340
> URL: https://issues.apache.org/jira/browse/GEODE-9340
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Sarah Abbey
>Assignee: Hale Bales
>Priority: Major
> Labels: pull-request-available
>
> PartitionedPutLongBenchmark failed in CI
> (https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/6):
> {code:java}
> This is ITERATION 1 of benchmarking against baseline.
> P2pPartitionedGetBenchmark avg ops/sec
> Baseline:825011.38 Test:835847.67 Difference: +1.3%
> avg latency
> Baseline:871392.31 Test:859444.66 Difference: -1.4%
> P2pPartitionedPutBenchmark avg ops/sec
> Baseline:123838.43 Test:122686.30 Difference: -0.9%
> avg latency
> Baseline: 6015719.73 Test: 6119472.19 Difference: +1.7%
> P2pPartitionedPutBytesBenchmark avg ops/sec
> Baseline:174887.77 Test:171040.93 Difference: -2.2%
> avg latency
> Baseline: 4145337.60 Test: 4236159.60 Difference: +2.2%
> PartitionedFunctionExecutionBenchmark avg ops/sec
> Baseline:248635.36 Test:261498.94 Difference: +5.2%
> avg latency
> Baseline:867122.63 Test:824550.34 Difference: -4.9%
> PartitionedFunctionExecutionWithArgumentsBenchmark avg ops/sec
> Baseline:280071.19 Test:275305.31 Difference: -1.7%
> avg latency
> Baseline: 1026643.12 Test: 1044307.43 Difference: +1.7%
> PartitionedFunctionExecutionWithFiltersBenchmark avg ops/sec
> Baseline:301416.23 Test:304317.30 Difference: +1.0%
> avg latency
> Baseline: 1908390.88 Test: 1890040.46 Difference: -1.0%
> PartitionedGetBenchmark avg ops/sec
> Baseline:790800.52 Test:784514.74 Difference: -0.8%
> avg latency
> Baseline:908357.58 Test:915790.96 Difference: +0.8%
> PartitionedGetLongBenchmark avg ops/sec
> Baseline: 1020821.32 Test:996529.93 Difference: -2.4%
> avg latency
> Baseline:703761.09 Test:720744.36 Difference: +2.4%
> PartitionedGetStringBenchmark avg ops/sec
> Baseline: 1028992.93 Test: 1010447.47 Difference: -1.8%
> avg latency
> Baseline:698009.55 Test:710765.29 Difference: +1.8%
> PartitionedIndexedQueryBenchmark avg ops/sec
> Baseline: 30868.78 Test: 31478.90 Difference: +2.0%
> avg latency
> Baseline: 18670093.21 Test: 18278083.16 Difference: -2.1%
> PartitionedNonIndexedQueryBenchmark avg ops/sec
> Baseline:99.45 Test: 101.97 Difference: +2.5%
> avg latency
> Baseline: 723415530.75 Test: 705653061.86 Difference: -2.5%
> PartitionedPutAllBenchmark avg ops/sec
> Baseline: 7921.61 Test: 7816.66 Difference: -1.3%
> avg latency
> Baseline: 18172638.37 Test: 18416169.28 Difference: +1.3%
> PartitionedPutAllLongBenchmark avg ops/sec
> Baseline: 1379.53 Test: 1169.16 Difference: -15.2%
> avg latency
> Baseline: 105140260.44 Test: 123722914.94 Difference: +17.7%
> PartitionedPutBenchmark avg ops/sec
> Baseline:474986.11 Test:467924.19 Difference: -1.5%
>
[jira] [Commented] (GEODE-9340) Benchmark instability in PartitionedPutLongBenchmark
[
https://issues.apache.org/jira/browse/GEODE-9340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418593#comment-17418593
]
Geode Integration commented on GEODE-9340:
--
Seen in [benchmark-base
#204|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/204].
> Benchmark instability in PartitionedPutLongBenchmark
>
>
> Key: GEODE-9340
> URL: https://issues.apache.org/jira/browse/GEODE-9340
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Sarah Abbey
>Assignee: Hale Bales
>Priority: Major
> Labels: pull-request-available
>
> PartitionedPutLongBenchmark failed in CI
> (https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/6):
> {code:java}
> This is ITERATION 1 of benchmarking against baseline.
> P2pPartitionedGetBenchmark avg ops/sec
> Baseline:825011.38 Test:835847.67 Difference: +1.3%
> avg latency
> Baseline:871392.31 Test:859444.66 Difference: -1.4%
> P2pPartitionedPutBenchmark avg ops/sec
> Baseline:123838.43 Test:122686.30 Difference: -0.9%
> avg latency
> Baseline: 6015719.73 Test: 6119472.19 Difference: +1.7%
> P2pPartitionedPutBytesBenchmark avg ops/sec
> Baseline:174887.77 Test:171040.93 Difference: -2.2%
> avg latency
> Baseline: 4145337.60 Test: 4236159.60 Difference: +2.2%
> PartitionedFunctionExecutionBenchmark avg ops/sec
> Baseline:248635.36 Test:261498.94 Difference: +5.2%
> avg latency
> Baseline:867122.63 Test:824550.34 Difference: -4.9%
> PartitionedFunctionExecutionWithArgumentsBenchmark avg ops/sec
> Baseline:280071.19 Test:275305.31 Difference: -1.7%
> avg latency
> Baseline: 1026643.12 Test: 1044307.43 Difference: +1.7%
> PartitionedFunctionExecutionWithFiltersBenchmark avg ops/sec
> Baseline:301416.23 Test:304317.30 Difference: +1.0%
> avg latency
> Baseline: 1908390.88 Test: 1890040.46 Difference: -1.0%
> PartitionedGetBenchmark avg ops/sec
> Baseline:790800.52 Test:784514.74 Difference: -0.8%
> avg latency
> Baseline:908357.58 Test:915790.96 Difference: +0.8%
> PartitionedGetLongBenchmark avg ops/sec
> Baseline: 1020821.32 Test:996529.93 Difference: -2.4%
> avg latency
> Baseline:703761.09 Test:720744.36 Difference: +2.4%
> PartitionedGetStringBenchmark avg ops/sec
> Baseline: 1028992.93 Test: 1010447.47 Difference: -1.8%
> avg latency
> Baseline:698009.55 Test:710765.29 Difference: +1.8%
> PartitionedIndexedQueryBenchmark avg ops/sec
> Baseline: 30868.78 Test: 31478.90 Difference: +2.0%
> avg latency
> Baseline: 18670093.21 Test: 18278083.16 Difference: -2.1%
> PartitionedNonIndexedQueryBenchmark avg ops/sec
> Baseline:99.45 Test: 101.97 Difference: +2.5%
> avg latency
> Baseline: 723415530.75 Test: 705653061.86 Difference: -2.5%
> PartitionedPutAllBenchmark avg ops/sec
> Baseline: 7921.61 Test: 7816.66 Difference: -1.3%
> avg latency
> Baseline: 18172638.37 Test: 18416169.28 Difference: +1.3%
> PartitionedPutAllLongBenchmark avg ops/sec
> Baseline: 1379.53 Test: 1169.16 Difference: -15.2%
> avg latency
> Baseline: 105140260.44 Test: 123722914.94 Difference: +17.7%
> PartitionedPutBenchmark avg ops/sec
> Baseline:474986.11 Test:467924.19 Difference: -1.5%
>
[jira] [Commented] (GEODE-7138) CI failure: ClientServerTransactionFailoverWithMixedVersionServersDistributedTest > clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer
[ https://issues.apache.org/jira/browse/GEODE-7138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418594#comment-17418594 ] Geode Integration commented on GEODE-7138: -- Seen in [upgrade-test-openjdk11 #203|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/upgrade-test-openjdk11/builds/203] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0505/test-results/upgradeTest/1632272713/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0505/test-artifacts/1632272713/upgradetestfiles-openjdk11-1.15.0-build.0505.tgz]. > CI failure: > ClientServerTransactionFailoverWithMixedVersionServersDistributedTest > > clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer > -- > > Key: GEODE-7138 > URL: https://issues.apache.org/jira/browse/GEODE-7138 > Project: Geode > Issue Type: Bug > Components: transactions >Affects Versions: 1.11.0 >Reporter: Anilkumar Gingade >Assignee: Eric Shu >Priority: Major > Labels: GeodeCommons, flaky > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > DistributedTestOpenJDK8 #1035 > org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest > > clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest$$Lambda$47/1742885319.run > in VM 0 running on Host 13889d5ebaf9 with 6 VMs > at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579) > at org.apache.geode.test.dunit.VM.invoke(VM.java:406) > at > org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:137) > Caused by: > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest > that uses org.apache.geode.cache.Region, org.apache.geode.cache.Regionint > expected:<[144]> but was:<[37]> within 300 seconds. > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32) > at > org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902) > at > org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723) > at > org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.verifyTransactionResult(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:361) > at > org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.lambda$clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer$2967fbd$2(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:137) > Caused by: > org.junit.ComparisonFailure: expected:<[144]> but was:<[37]> > at > sun.reflect.GeneratedConstructorAccessor38.newInstance(Unknown Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.lambda$verifyTransactionResult$2(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:361) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9622) CI Failure: ClientServerTransactionFailoverWithMixedVersionServersDistributedTest fails with BindException
[
https://issues.apache.org/jira/browse/GEODE-9622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418595#comment-17418595
]
Geode Integration commented on GEODE-9622:
--
Seen in [upgrade-test-openjdk11
#203|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/upgrade-test-openjdk11/builds/203]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0505/test-results/upgradeTest/1632272713/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0505/test-artifacts/1632272713/upgradetestfiles-openjdk11-1.15.0-build.0505.tgz].
> CI Failure:
> ClientServerTransactionFailoverWithMixedVersionServersDistributedTest fails
> with BindException
> --
>
> Key: GEODE-9622
> URL: https://issues.apache.org/jira/browse/GEODE-9622
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Reporter: Kirk Lund
>Priority: Major
>
> {noformat}
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest
> > clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest$$Lambda$68/194483270.call
> in VM 5 running on Host
> heavy-lifter-2b8702f1-fe32-5895-9b14-832b7049b607.c.apachegeode-ci.internal
> with 6 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:473)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.rollLocatorToCurrent(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:216)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.setupPartiallyRolledVersion(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:171)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:127)
> Caused by:
> java.net.BindException: Failed to create server socket on
> heavy-lifter-2b8702f1-fe32-5895-9b14-832b7049b607.c.apachegeode-ci.internal/10.0.0.60[43535]
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:75)
> at
> org.apache.geode.internal.net.SCClusterSocketCreator.createServerSocket(SCClusterSocketCreator.java:55)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.createServerSocket(ClusterSocketCreatorImpl.java:54)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.initializeServerSocket(TcpServer.java:196)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.startServerThread(TcpServer.java:183)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.start(TcpServer.java:178)
> at
> org.apache.geode.distributed.internal.membership.gms.locator.MembershipLocatorImpl.start(MembershipLocatorImpl.java:112)
> at
> org.apache.geode.distributed.internal.InternalLocator.startPeerLocation(InternalLocator.java:653)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:394)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:345)
> at
> org.apache.geode.distributed.Locator.startLocator(Locator.java:261)
> at
> org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:207)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.startLocator(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:180)
> at
> org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.lambda$rollLocatorToCurrent$92d5d92a$1(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:216)
> Caused by:
> java.net.BindException: Address already in use (Bind failed)
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at
> java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> at java.net.ServerSocket.bind(ServerSocket.java:3
[jira] [Issue Comment Deleted] (GEODE-7138) CI failure: ClientServerTransactionFailoverWithMixedVersionServersDistributedTest > clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer
[ https://issues.apache.org/jira/browse/GEODE-7138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe updated GEODE-7138: -- Comment: was deleted (was: Seen in [upgrade-test-openjdk11 #203|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/upgrade-test-openjdk11/builds/203] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0505/test-results/upgradeTest/1632272713/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0505/test-artifacts/1632272713/upgradetestfiles-openjdk11-1.15.0-build.0505.tgz].) > CI failure: > ClientServerTransactionFailoverWithMixedVersionServersDistributedTest > > clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer > -- > > Key: GEODE-7138 > URL: https://issues.apache.org/jira/browse/GEODE-7138 > Project: Geode > Issue Type: Bug > Components: transactions >Affects Versions: 1.11.0 >Reporter: Anilkumar Gingade >Assignee: Eric Shu >Priority: Major > Labels: GeodeCommons, flaky > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > DistributedTestOpenJDK8 #1035 > org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest > > clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest$$Lambda$47/1742885319.run > in VM 0 running on Host 13889d5ebaf9 with 6 VMs > at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579) > at org.apache.geode.test.dunit.VM.invoke(VM.java:406) > at > org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:137) > Caused by: > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest > that uses org.apache.geode.cache.Region, org.apache.geode.cache.Regionint > expected:<[144]> but was:<[37]> within 300 seconds. > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32) > at > org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902) > at > org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723) > at > org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.verifyTransactionResult(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:361) > at > org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.lambda$clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer$2967fbd$2(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:137) > Caused by: > org.junit.ComparisonFailure: expected:<[144]> but was:<[37]> > at > sun.reflect.GeneratedConstructorAccessor38.newInstance(Unknown Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.lambda$verifyTransactionResult$2(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:361) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6645) CI: org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest > testDataStoreEntryCount FAILED
[
https://issues.apache.org/jira/browse/GEODE-6645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418597#comment-17418597
]
Geode Integration commented on GEODE-6645:
--
Seen on support/1.12 in [distributed-test-openjdk8
#44|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main/jobs/distributed-test-openjdk8/builds/44]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.5-build.0284/test-results/distributedTest/1632302511/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.5-build.0284/test-artifacts/1632302511/distributedtestfiles-openjdk8-1.12.5-build.0284.tgz].
> CI: org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest >
> testDataStoreEntryCount FAILED
>
>
> Key: GEODE-6645
> URL: https://issues.apache.org/jira/browse/GEODE-6645
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.10.0
>Reporter: Lynn Hughes-Godfrey
>Priority: Major
> Labels: CI, GeodeOperationAPI
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/617
> {noformat}
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest >
> testDataStoreEntryCount FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest$$Lambda$172/0x00084024dc40.run
> in VM 2 running on Host 1ee860aba5ac with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest.testDataStoreEntryCount(PartitionedRegionStatsDUnitTest.java:198)
> Caused by:
> org.junit.ComparisonFailure: expected:<[3]L> but was:<[2]L>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest.validateEntryCount(PartitionedRegionStatsDUnitTest.java:267)
> at
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest.lambda$testDataStoreEntryCount$bb17a952$18(PartitionedRegionStatsDUnitTest.java:198)
> {noformat}
> Artifacts are available here:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0176/test-results/distributedTest/1555097363/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0176/test-artifacts/1555097363/distributedtestfiles-OpenJDK11-1.10.0-SNAPSHOT.0176.tgz
> {noformat}
> Looking at this test, it goes through several phases of entry creation,
> destroy, destroy + put and GII (after adding a new member) for a partitioned
> region with redundantCopies=2. After adding the new member and forcing
> tombstone expiration, the newly created vm ends up with 1 less entry than
> expected (but the original two vms appear to have the expected number of
> entries (3)).
> Full stack
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest$$Lambda$172/0x00084024dc40.run
> in VM 2 running on Host 1ee860aba5ac with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest.testDataStoreEntryCount(PartitionedRegionStatsDUnitTest.java:198)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
>
[jira] [Commented] (GEODE-8634) CI failure: AsyncInvocationTimeoutDistributedTest. get_callable_timeout_includesStackTraceAsCause
[
https://issues.apache.org/jira/browse/GEODE-8634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418599#comment-17418599
]
Geode Integration commented on GEODE-8634:
--
Seen on support/1.12 in [distributed-test-openjdk8
#43|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main/jobs/distributed-test-openjdk8/builds/43]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.5-build.0284/test-results/distributedTest/1632271313/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.5-build.0284/test-artifacts/1632271313/distributedtestfiles-openjdk8-1.12.5-build.0284.tgz].
> CI failure: AsyncInvocationTimeoutDistributedTest.
> get_callable_timeout_includesStackTraceAsCause
> -
>
> Key: GEODE-8634
> URL: https://issues.apache.org/jira/browse/GEODE-8634
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.13.0, 1.14.0
>Reporter: Jens Deppe
>Assignee: Kirk Lund
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/DistributedTestOpenJDK8/builds/24
> {noformat}
> org.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest >
> get_callable_timeout_includesStackTraceAsCause FAILED
> java.lang.AssertionError:
> Expecting message to be:
> <"Stack trace for vm-0 thread-32">
> but was:
> <"Stack trace for vm-0 thread-33">
> Throwable that failed the check:
> org.apache.geode.test.dunit.internal.StackTrace: Stack trace for vm-0
> thread-33
> at sun.misc.Unsafe.park(Native Method)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at
> org.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest.lambda$get_callable_timeout_includesStackTraceAsCause$c2252e51$1(AsyncInvocationTimeoutDistributedTest.java:109)
> at
> org.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest$$Lambda$36/681142003.call(Unknown
> Source)
> at
> org.apache.geode.test.dunit.internal.IdentifiableCallable.call(IdentifiableCallable.java:41)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
> at
> org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:834)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$15/1238667039.run(Unknown
> Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at
> org.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest.get_callable_timeout_includesStackTraceAsCau
[jira] [Assigned] (GEODE-9624) Status redundancy command reports wrong value for empty regions
[
https://issues.apache.org/jira/browse/GEODE-9624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alberto Bustamante Reyes reassigned GEODE-9624:
---
Assignee: Alberto Bustamante Reyes
> Status redundancy command reports wrong value for empty regions
> ---
>
> Key: GEODE-9624
> URL: https://issues.apache.org/jira/browse/GEODE-9624
> Project: Geode
> Issue Type: Bug
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
>
> When a partitioned region is empty, the "status redundancy" command reports
> the current redundancy of than region as Integer.MAX_VALUE .
> This can be reproduced following these steps:
> {code:java}
> gfsh>start locator --name=locator1
> gfsh>start server --name=server1
> gfsh>start server --name=server2 --server-port=40405
> gfsh>create region --name=test --type=PARTITION_REDUNDANT_PERSISTENT
> gfsh>status redundancy
> Number of regions with zero redundant copies = 0
> Number of regions with partially satisfied redundancy = 1
> Number of regions with fully satisfied redundancy = 0
> Redundancy is partially satisfied for regions:
> test redundancy status: NOT_SATISFIED. Desired redundancy is 1 and actual
> redundancy is 2147483647.
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9624) Status redundancy command reports wrong value for empty regions
Alberto Bustamante Reyes created GEODE-9624:
---
Summary: Status redundancy command reports wrong value for empty
regions
Key: GEODE-9624
URL: https://issues.apache.org/jira/browse/GEODE-9624
Project: Geode
Issue Type: Bug
Reporter: Alberto Bustamante Reyes
When a partitioned region is empty, the "status redundancy" command reports the
current redundancy of than region as Integer.MAX_VALUE .
This can be reproduced following these steps:
{code:java}
gfsh>start locator --name=locator1
gfsh>start server --name=server1
gfsh>start server --name=server2 --server-port=40405
gfsh>create region --name=test --type=PARTITION_REDUNDANT_PERSISTENT
gfsh>status redundancy
Number of regions with zero redundant copies = 0
Number of regions with partially satisfied redundancy = 1
Number of regions with fully satisfied redundancy = 0
Redundancy is partially satisfied for regions:
test redundancy status: NOT_SATISFIED. Desired redundancy is 1 and actual
redundancy is 2147483647.
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9549) Enable .net core tests in CI
[ https://issues.apache.org/jira/browse/GEODE-9549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418625#comment-17418625 ] ASF GitHub Bot commented on GEODE-9549: --- pdxcodemonkey merged pull request #867: URL: https://github.com/apache/geode-native/pull/867 -- 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 > Enable .net core tests in CI > > > Key: GEODE-9549 > URL: https://issues.apache.org/jira/browse/GEODE-9549 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Priority: Major > Labels: pull-request-available > > The .net core build and tests are integrated into the CI, but test running is > currently disabled due to a few issues. These need to be cleaned up, and > tests enabled in CI. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9549) Enable .net core tests in CI
[ https://issues.apache.org/jira/browse/GEODE-9549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418624#comment-17418624 ] ASF subversion and git services commented on GEODE-9549: Commit a20293285e667c7ac1d6120bad4dd48a19e75830 in geode-native's branch refs/heads/develop from Blake Bender [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=a202932 ] GEODE-9549: enable netcore tests in CI (#867) * GEODE-9549: Enable .net core tests in CI - Enable test running job in yml * GEODE-9549: Build NetCore and NetCore.Test projects individually - This simplifies the cmake config, and makes the post-build file copy steps more reliable * GEODE-9549: Copy C bindings lib to binary dir for tests - Give Java project a reasonable name * GEODE-9549: Use ctest to run netcore tests - Eliminates need for start/stop scripts, all done via ctest now * GEODE-9549: Make .net core project build in sequence - Still getting sharing violations on parallel builds, so need to ensure none of these build at the same time. Co-authored-by: Jacob Barrett > Enable .net core tests in CI > > > Key: GEODE-9549 > URL: https://issues.apache.org/jira/browse/GEODE-9549 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Priority: Major > Labels: pull-request-available > > The .net core build and tests are integrated into the CI, but test running is > currently disabled due to a few issues. These need to be cleaned up, and > tests enabled in CI. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9619) README.md (top level) - fix format problems
[ https://issues.apache.org/jira/browse/GEODE-9619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes updated GEODE-9619: --- Priority: Minor (was: Major) > README.md (top level) - fix format problems > --- > > Key: GEODE-9619 > URL: https://issues.apache.org/jira/browse/GEODE-9619 > Project: Geode > Issue Type: Improvement > Components: docs >Affects Versions: 1.14.0 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Minor > > Community member Kaustubh Maske Patil notes that the top-level Geode > README.md file contains a numbered list in which items 9 and 10 appear on a > single line. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9357) Create CI pipeline for net-core-session
[ https://issues.apache.org/jira/browse/GEODE-9357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender resolved GEODE-9357. - Fix Version/s: 1.15.0 Resolution: Not A Problem Don't need this - we're already building/testing session in the main pipeline. > Create CI pipeline for net-core-session > --- > > Key: GEODE-9357 > URL: https://issues.apache.org/jira/browse/GEODE-9357 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Ernest Burghardt >Priority: Major > Fix For: 1.15.0 > > > This pipeline will be hosted on the Apache publicly available Concourse and > publish to NuGet -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9619) README.md (top level) - fix format problems
[ https://issues.apache.org/jira/browse/GEODE-9619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9619: -- Labels: pull-request-available (was: ) > README.md (top level) - fix format problems > --- > > Key: GEODE-9619 > URL: https://issues.apache.org/jira/browse/GEODE-9619 > Project: Geode > Issue Type: Improvement > Components: docs >Affects Versions: 1.14.0 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Minor > Labels: pull-request-available > > Community member Kaustubh Maske Patil notes that the top-level Geode > README.md file contains a numbered list in which items 9 and 10 appear on a > single line. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9619) README.md (top level) - fix format problems
[ https://issues.apache.org/jira/browse/GEODE-9619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418737#comment-17418737 ] ASF subversion and git services commented on GEODE-9619: Commit b8048e1b6126483db26a7370ed493f2902707c0b in geode's branch refs/heads/develop from Kaustubh Maske Patil [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b8048e1 ] GEODE-9619: [documentation] Align contents section in README (#6888) * Align contents in README * Fixed typo in "How to Contribute" Co-authored-by: Dan Smith > README.md (top level) - fix format problems > --- > > Key: GEODE-9619 > URL: https://issues.apache.org/jira/browse/GEODE-9619 > Project: Geode > Issue Type: Improvement > Components: docs >Affects Versions: 1.14.0 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Minor > Labels: pull-request-available > > Community member Kaustubh Maske Patil notes that the top-level Geode > README.md file contains a numbered list in which items 9 and 10 appear on a > single line. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9619) README.md (top level) - fix format problems
[ https://issues.apache.org/jira/browse/GEODE-9619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418739#comment-17418739 ] Dave Barnes commented on GEODE-9619: [~nikochiko] Thank you for your contribution. Your pull-request (including a typo fix by another community member) has been merged into the codebase for the develop branch. I will propagate the change to the v1.14 branch before closing this ticket. In response to your earlier comment: To request eligibility for JIRA ticket assignment, please send a request to the project mailing list, d...@geode.apache.org. > README.md (top level) - fix format problems > --- > > Key: GEODE-9619 > URL: https://issues.apache.org/jira/browse/GEODE-9619 > Project: Geode > Issue Type: Improvement > Components: docs >Affects Versions: 1.14.0 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Minor > Labels: pull-request-available > > Community member Kaustubh Maske Patil notes that the top-level Geode > README.md file contains a numbered list in which items 9 and 10 appear on a > single line. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9619) README.md (top level) - fix format problems
[ https://issues.apache.org/jira/browse/GEODE-9619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418745#comment-17418745 ] ASF subversion and git services commented on GEODE-9619: Commit e4841e162fa2b2ec7da726e51ab8f63f429e2ff8 in geode's branch refs/heads/support/1.14 from Kaustubh Maske Patil [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e4841e1 ] GEODE-9619: [documentation] Align contents section in README (#6888) * Align contents in README * Fixed typo in "How to Contribute" Co-authored-by: Dan Smith > README.md (top level) - fix format problems > --- > > Key: GEODE-9619 > URL: https://issues.apache.org/jira/browse/GEODE-9619 > Project: Geode > Issue Type: Improvement > Components: docs >Affects Versions: 1.14.0 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Minor > Labels: pull-request-available > Fix For: 1.14.1, 1.15.0 > > > Community member Kaustubh Maske Patil notes that the top-level Geode > README.md file contains a numbered list in which items 9 and 10 appear on a > single line. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9619) README.md (top level) - fix format problems
[ https://issues.apache.org/jira/browse/GEODE-9619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes resolved GEODE-9619. Fix Version/s: 1.15.0 1.14.1 Resolution: Fixed > README.md (top level) - fix format problems > --- > > Key: GEODE-9619 > URL: https://issues.apache.org/jira/browse/GEODE-9619 > Project: Geode > Issue Type: Improvement > Components: docs >Affects Versions: 1.14.0 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Minor > Labels: pull-request-available > Fix For: 1.14.1, 1.15.0 > > > Community member Kaustubh Maske Patil notes that the top-level Geode > README.md file contains a numbered list in which items 9 and 10 appear on a > single line. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9625) GatwaySenderEventImpl always serializes metadata necessary only for transaction grouping
Jacob Barrett created GEODE-9625: Summary: GatwaySenderEventImpl always serializes metadata necessary only for transaction grouping Key: GEODE-9625 URL: https://issues.apache.org/jira/browse/GEODE-9625 Project: Geode Issue Type: Bug Reporter: Jacob Barrett Recent additions for transaction grouping in WAN caused GatewaySenderEventImpl to serialize transaction ID and last transaction flags for every event regardless of the configuration of the transaction grouping option. This results in both WAN and AEQ queues to replication unnecessary data. Transaction ID also includes the member ID which is a large-sh object. The overhead should be removed from queues that don't need that metadata. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9625) GatwaySenderEventImpl always serializes metadata necessary only for transaction grouping
[ https://issues.apache.org/jira/browse/GEODE-9625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett updated GEODE-9625: - Affects Version/s: 1.15.0 1.14.1 1.14.0 > GatwaySenderEventImpl always serializes metadata necessary only for > transaction grouping > > > Key: GEODE-9625 > URL: https://issues.apache.org/jira/browse/GEODE-9625 > Project: Geode > Issue Type: Bug >Affects Versions: 1.14.0, 1.14.1, 1.15.0 >Reporter: Jacob Barrett >Priority: Major > > Recent additions for transaction grouping in WAN caused > GatewaySenderEventImpl to serialize transaction ID and last transaction flags > for every event regardless of the configuration of the transaction grouping > option. This results in both WAN and AEQ queues to replication unnecessary > data. Transaction ID also includes the member ID which is a large-sh object. > The overhead should be removed from queues that don't need that metadata. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9625) GatwaySenderEventImpl always serializes metadata necessary only for transaction grouping
[ https://issues.apache.org/jira/browse/GEODE-9625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett updated GEODE-9625: - Component/s: wan > GatwaySenderEventImpl always serializes metadata necessary only for > transaction grouping > > > Key: GEODE-9625 > URL: https://issues.apache.org/jira/browse/GEODE-9625 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.14.0, 1.14.1, 1.15.0 >Reporter: Jacob Barrett >Priority: Major > > Recent additions for transaction grouping in WAN caused > GatewaySenderEventImpl to serialize transaction ID and last transaction flags > for every event regardless of the configuration of the transaction grouping > option. This results in both WAN and AEQ queues to replication unnecessary > data. Transaction ID also includes the member ID which is a large-sh object. > The overhead should be removed from queues that don't need that metadata. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9625) GatwaySenderEventImpl always serializes metadata necessary only for transaction grouping
[ https://issues.apache.org/jira/browse/GEODE-9625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett reassigned GEODE-9625: Assignee: Jacob Barrett > GatwaySenderEventImpl always serializes metadata necessary only for > transaction grouping > > > Key: GEODE-9625 > URL: https://issues.apache.org/jira/browse/GEODE-9625 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.14.0, 1.14.1, 1.15.0 >Reporter: Jacob Barrett >Assignee: Jacob Barrett >Priority: Major > Fix For: 1.14.1, 1.15.0 > > > Recent additions for transaction grouping in WAN caused > GatewaySenderEventImpl to serialize transaction ID and last transaction flags > for every event regardless of the configuration of the transaction grouping > option. This results in both WAN and AEQ queues to replication unnecessary > data. Transaction ID also includes the member ID which is a large-sh object. > The overhead should be removed from queues that don't need that metadata. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9625) GatwaySenderEventImpl always serializes metadata necessary only for transaction grouping
[ https://issues.apache.org/jira/browse/GEODE-9625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett updated GEODE-9625: - Fix Version/s: 1.15.0 1.14.1 > GatwaySenderEventImpl always serializes metadata necessary only for > transaction grouping > > > Key: GEODE-9625 > URL: https://issues.apache.org/jira/browse/GEODE-9625 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.14.0, 1.14.1, 1.15.0 >Reporter: Jacob Barrett >Priority: Major > Fix For: 1.14.1, 1.15.0 > > > Recent additions for transaction grouping in WAN caused > GatewaySenderEventImpl to serialize transaction ID and last transaction flags > for every event regardless of the configuration of the transaction grouping > option. This results in both WAN and AEQ queues to replication unnecessary > data. Transaction ID also includes the member ID which is a large-sh object. > The overhead should be removed from queues that don't need that metadata. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9626) Field 'GeodeSessionStateCache._logger' is never assigned to, and will always have its default value null
Michael Oleske created GEODE-9626:
-
Summary: Field 'GeodeSessionStateCache._logger' is never assigned
to, and will always have its default value null
Key: GEODE-9626
URL: https://issues.apache.org/jira/browse/GEODE-9626
Project: Geode
Issue Type: Task
Components: native client
Reporter: Michael Oleske
When I run {{cmake --build}}
Then I see no warnings in NetCoreBuilds
Notes: When running {{cmake --build}}, there is a warning that pops up in
NetCoreSessionState.cs
{{NetCoreSessionState.cs(77,45): warning CS0649: Field
'GeodeSessionStateCache._logger' is never assigned to, and will always have its
default value null
[/Users/pivotal/workspace/geode-native/netcore/netcore-session/netcore-session.csproj]}}
{{ 1 Warning(s)}}
{{ 0 Error(s)}}
It seems that {{_logger}} is used, but never initialized. I thought about
deleting it but it looks like the logs would be useful. I'm not sure what to
initialize it to since I'm outta practice on my c# skills
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9626) Field 'GeodeSessionStateCache._logger' is never assigned to, and will always have its default value null
[
https://issues.apache.org/jira/browse/GEODE-9626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418784#comment-17418784
]
Michael Oleske commented on GEODE-9626:
---
This may be a duplicate of https://issues.apache.org/jira/browse/GEODE-9609 but
that issue has no description
> Field 'GeodeSessionStateCache._logger' is never assigned to, and will always
> have its default value null
>
>
> Key: GEODE-9626
> URL: https://issues.apache.org/jira/browse/GEODE-9626
> Project: Geode
> Issue Type: Task
> Components: native client
>Reporter: Michael Oleske
>Priority: Major
>
> When I run {{cmake --build}}
> Then I see no warnings in NetCoreBuilds
> Notes: When running {{cmake --build}}, there is a warning that pops up in
> NetCoreSessionState.cs
> {{NetCoreSessionState.cs(77,45): warning CS0649: Field
> 'GeodeSessionStateCache._logger' is never assigned to, and will always have
> its default value null
> [/Users/pivotal/workspace/geode-native/netcore/netcore-session/netcore-session.csproj]}}
> {{ 1 Warning(s)}}
> {{ 0 Error(s)}}
> It seems that {{_logger}} is used, but never initialized. I thought about
> deleting it but it looks like the logs would be useful. I'm not sure what to
> initialize it to since I'm outta practice on my c# skills
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9627) Add service loader interface to register DataSerializableFixedIDs
Jens Deppe created GEODE-9627:
-
Summary: Add service loader interface to register
DataSerializableFixedIDs
Key: GEODE-9627
URL: https://issues.apache.org/jira/browse/GEODE-9627
Project: Geode
Issue Type: Improvement
Components: core, lucene, redis
Reporter: Jens Deppe
External modules that require registering DataSerializableFixedIDs typically do
so as part of their service loading initialization step. However, it seems that
under some circumstances it may be necessary to have the DSFIDs be available
even before the service is loaded as peers may be sending DSFID values even as
a member is just starting up. Thus the DSFID should be made available even
before a member is available to receive peer messages.
This change introduces a service loader interface, {{DSFIDLoader}} which is
called as part of the static initialization block in
{{InternalDataSerializer}}. This will ensure that all reguired DSFIDs are
available almost as soon as the JVM starts.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-9627) Add service loader interface to register DataSerializableFixedIDs
[
https://issues.apache.org/jira/browse/GEODE-9627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe reassigned GEODE-9627:
-
Assignee: Jens Deppe
> Add service loader interface to register DataSerializableFixedIDs
> -
>
> Key: GEODE-9627
> URL: https://issues.apache.org/jira/browse/GEODE-9627
> Project: Geode
> Issue Type: Improvement
> Components: core, lucene, redis
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
>
> External modules that require registering DataSerializableFixedIDs typically
> do so as part of their service loading initialization step. However, it seems
> that under some circumstances it may be necessary to have the DSFIDs be
> available even before the service is loaded as peers may be sending DSFID
> values even as a member is just starting up. Thus the DSFID should be made
> available even before a member is available to receive peer messages.
> This change introduces a service loader interface, {{DSFIDLoader}} which is
> called as part of the static initialization block in
> {{InternalDataSerializer}}. This will ensure that all reguired DSFIDs are
> available almost as soon as the JVM starts.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9627) Add service loader interface to register DataSerializableFixedIDs
[
https://issues.apache.org/jira/browse/GEODE-9627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9627:
--
Labels: pull-request-available (was: )
> Add service loader interface to register DataSerializableFixedIDs
> -
>
> Key: GEODE-9627
> URL: https://issues.apache.org/jira/browse/GEODE-9627
> Project: Geode
> Issue Type: Improvement
> Components: core, lucene, redis
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> External modules that require registering DataSerializableFixedIDs typically
> do so as part of their service loading initialization step. However, it seems
> that under some circumstances it may be necessary to have the DSFIDs be
> available even before the service is loaded as peers may be sending DSFID
> values even as a member is just starting up. Thus the DSFID should be made
> available even before a member is available to receive peer messages.
> This change introduces a service loader interface, {{DSFIDLoader}} which is
> called as part of the static initialization block in
> {{InternalDataSerializer}}. This will ensure that all reguired DSFIDs are
> available almost as soon as the JVM starts.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9627) Add service loader interface to register DataSerializableFixedIDs
[
https://issues.apache.org/jira/browse/GEODE-9627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-9627:
--
Description:
External modules that require registering DataSerializableFixedIDs typically do
so as part of their service loading initialization step. However, it seems that
under some circumstances it may be necessary to have the DSFIDs be available
even before the service is loaded as peers may be sending DSFID values even as
a member is just starting up. Thus the DSFID should be made available even
before a member is available to receive peer messages.
This change introduces a service loader interface, {{DSFIDLoader}} which is
called as part of the static initialization block in
{{InternalDataSerializer}}. This will ensure that all reguired DSFIDs are
available almost as soon as the JVM starts.
This work is related to GEODE-9618
was:
External modules that require registering DataSerializableFixedIDs typically do
so as part of their service loading initialization step. However, it seems that
under some circumstances it may be necessary to have the DSFIDs be available
even before the service is loaded as peers may be sending DSFID values even as
a member is just starting up. Thus the DSFID should be made available even
before a member is available to receive peer messages.
This change introduces a service loader interface, {{DSFIDLoader}} which is
called as part of the static initialization block in
{{InternalDataSerializer}}. This will ensure that all reguired DSFIDs are
available almost as soon as the JVM starts.
> Add service loader interface to register DataSerializableFixedIDs
> -
>
> Key: GEODE-9627
> URL: https://issues.apache.org/jira/browse/GEODE-9627
> Project: Geode
> Issue Type: Improvement
> Components: core, lucene, redis
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> External modules that require registering DataSerializableFixedIDs typically
> do so as part of their service loading initialization step. However, it seems
> that under some circumstances it may be necessary to have the DSFIDs be
> available even before the service is loaded as peers may be sending DSFID
> values even as a member is just starting up. Thus the DSFID should be made
> available even before a member is available to receive peer messages.
> This change introduces a service loader interface, {{DSFIDLoader}} which is
> called as part of the static initialization block in
> {{InternalDataSerializer}}. This will ensure that all reguired DSFIDs are
> available almost as soon as the JVM starts.
> This work is related to GEODE-9618
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-6078) java.lang.UnsupportedOperationException: Use Pool APIs for doing operations when multiuser-secure-mode-enabled is set to true
[
https://issues.apache.org/jira/browse/GEODE-6078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-6078:
-
Description:
User is using
multiuser-authentication="true"
Below is the test code code
public static void testMultiUser() {
System.out.println("TestClient.testMultiUser()");
ClientCache cache = new ClientCacheFactory()
.set("security-client-auth-init",
"org.apache.geode.testfunction.UserPasswordAuthInit")
.set("name", "SecurityClient")
.set("cache-xml-file", "MultiuserSecurityClient.xml")
.create();
Properties properties = new Properties();
properties.setProperty("security-username", "admin");
properties.setProperty("security-password", "secret");
RegionService regionService = cache.createAuthenticatedView(
properties);
System.out.println(regionService);
String value=" {\"orders\": {\"orderId\":
\"\",\"accounts\": [{\"accountNumber\": \"\",\"accountType\":
\"INDIVIDUAL\",\"accountSubType\": \"INDIVIDUAL_REGULAR\",\"status\":
\"OPERATIONAL\",\"billingAddress\": {\"addressId\": 1008737},\"bills\":
[{\"billCycleDay\": 4}],\"isPRIndicator\": false,\"marketCode\":
\"SEW\",\"tenure\": \"1\",\"contactFirstName\": \"TEST\",\"contactFamilyName\":
\"MARKETINGCATKH\"},{\"accountNumber\": \"33\",\"accountType\":
\"INDIVIDUAL\",\"accountSubType\": \"INDIVIDUAL_REGULAR\",\"status\":
\"OPERATIONAL\",\"billingAddress\": {\"addressId\": 1008737},\"bills\":
[{\"billCycleDay\": 4}],\"isPuertoRicoIndicator\": false,\"marketCode\":
\"SEW\",\"tenure\": \"1\",\"contactFirstName\": \"TEST\",\"contactFamilyName\":
\"MARKETINGCATKH\"}]}}";
Region region = cache.getRegion("Test");
PdxInstance pdx= JSONFormatter.fromJSON(value);
region.put("key",pdx);
System.out.println(FunctionService.onServer(regionService).execute(new
TestFunction()).getResult());
}
was:
User is using
multiuser-authentication="true"
Below is the test code code
public static void testMultiUser() {
System.out.println("TestClient.testMultiUser()");
ClientCache cache = new ClientCacheFactory()
.set("security-client-auth-init",
"com.pivotal.support.johnson.testfunction.UserPasswordAuthInit")
.set("name", "SecurityClient")
.set("cache-xml-file", "MultiuserSecurityClient.xml")
.create();
Properties properties = new Properties();
properties.setProperty("security-username", "admin");
properties.setProperty("security-password", "secret");
RegionService regionService = cache.createAuthenticatedView(
properties);
System.out.println(regionService);
String value=" {\"orders\": {\"orderId\":
\"7101012826\",\"accounts\": [{\"accountNumber\":
\"960555183\",\"accountType\": \"INDIVIDUAL\",\"accountSubType\":
\"INDIVIDUAL_REGULAR\",\"status\": \"OPERATIONAL\",\"billingAddress\":
{\"addressId\": 1008737},\"bills\": [{\"billCycleDay\":
4}],\"isPuertoRicoIndicator\": false,\"marketCode\": \"SEW\",\"tenure\":
\"1\",\"contactFirstName\": \"TEST\",\"contactFamilyName\":
\"MARKETINGCATKH\"},{\"accountNumber\": \"33\",\"accountType\":
\"INDIVIDUAL\",\"accountSubType\": \"INDIVIDUAL_REGULAR\",\"status\":
\"OPERATIONAL\",\"billingAddress\": {\"addressId\": 1008737},\"bills\":
[{\"billCycleDay\": 4}],\"isPuertoRicoIndicator\": false,\"marketCode\":
\"SEW\",\"tenure\": \"1\",\"contactFirstName\": \"TEST\",\"contactFamilyName\":
\"MARKETINGCATKH\"}]}}";
Region region = cache.getRegion("Test");
PdxInstance pdx= JSONFormatter.fromJSON(value);
region.put("key",pdx);
System.out.println(FunctionService.onServer(regionService).execute(new
TestFunction()).getResult());
}
> java.lang.UnsupportedOperationException: Use Pool APIs for doing operations
> when multiuser-secure-mode-enabled is set to true
> -
>
> Key: GEODE-6078
> URL: https://issues.apache.org/jira/browse/GEODE-6078
> Project: Geode
> Issue Type: Bug
>Reporter: Jinmei Liao
>Assignee: Anilkumar Gingade
>Priority: Major
> Labels: SmallFeature
> Fix For: 1.9.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> User is using
> multiuser-authentication="true"
> Below is the test code code
> public static void testMultiUser() {
> System.out.println("TestClient.testMultiUser()");
> ClientCache cache = new ClientCacheFactory()
> .set("security-client-auth-init",
> "org.apache.geode.testfunction.UserPasswordAuthInit")
> .set("name"
[jira] [Closed] (GEODE-9465) Add radish test using redisson library
[ https://issues.apache.org/jira/browse/GEODE-9465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe closed GEODE-9465. - Assignee: Jens Deppe > Add radish test using redisson library > -- > > Key: GEODE-9465 > URL: https://issues.apache.org/jira/browse/GEODE-9465 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > > We should have a test that uses the redisson > (https://github.com/redisson/redisson) library to connect to a cluster. > Ensure that bucket movements are handled correctly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9465) Add radish test using redisson library
[
https://issues.apache.org/jira/browse/GEODE-9465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-9465.
---
Resolution: Won't Fix
Redisson does not work with our implementation since it relies very heavily on
the ability to execute scripts via {{EVAL}}.
> Add radish test using redisson library
> --
>
> Key: GEODE-9465
> URL: https://issues.apache.org/jira/browse/GEODE-9465
> Project: Geode
> Issue Type: Test
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
>
> We should have a test that uses the redisson
> (https://github.com/redisson/redisson) library to connect to a cluster.
> Ensure that bucket movements are handled correctly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9625) GatwaySenderEventImpl always serializes metadata necessary only for transaction grouping
[ https://issues.apache.org/jira/browse/GEODE-9625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9625: -- Labels: pull-request-available (was: ) > GatwaySenderEventImpl always serializes metadata necessary only for > transaction grouping > > > Key: GEODE-9625 > URL: https://issues.apache.org/jira/browse/GEODE-9625 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.14.0, 1.14.1, 1.15.0 >Reporter: Jacob Barrett >Assignee: Jacob Barrett >Priority: Major > Labels: pull-request-available > Fix For: 1.14.1, 1.15.0 > > > Recent additions for transaction grouping in WAN caused > GatewaySenderEventImpl to serialize transaction ID and last transaction flags > for every event regardless of the configuration of the transaction grouping > option. This results in both WAN and AEQ queues to replication unnecessary > data. Transaction ID also includes the member ID which is a large-sh object. > The overhead should be removed from queues that don't need that metadata. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9611) Incorrect spelling
[
https://issues.apache.org/jira/browse/GEODE-9611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9611:
--
Labels: pull-request-available (was: )
> Incorrect spelling
> --
>
> Key: GEODE-9611
> URL: https://issues.apache.org/jira/browse/GEODE-9611
> Project: Geode
> Issue Type: Improvement
> Components: configuration
>Affects Versions: 1.14.0
>Reporter: Deepak Khopade
>Priority: Major
> Labels: pull-request-available
>
> Incorrect spelling is found in the below error message that is getting
> printed in the logs. It should be.
> {code:java}
> parameterization{code}
> https://github.com/apache/geode/blob/a5bd36f9fa787d3a71c6e6efafed5a7b0fe52d2b/geode-core/src/main/java/org/apache/geode/internal/cache/xmlcache/CacheXmlPropertyResolver.java#L125
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9628) Documentation fix for setting credentials in a client
Nabarun Nag created GEODE-9628:
--
Summary: Documentation fix for setting credentials in a client
Key: GEODE-9628
URL: https://issues.apache.org/jira/browse/GEODE-9628
Project: Geode
Issue Type: Bug
Components: docs
Reporter: Nabarun Nag
Current:
{noformat}
How a Client Cache Sets Its CredentialIn order to connect with a locator or a
server that does authentication, a client will need to set its credential,
composed of the two properties security-username and security-password. Choose
one of these two ways to accomplish this:{noformat}
The last line needs to be changed to needing both the steps, instead of
choosing one of the two steps
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-9628) Documentation fix for setting credentials in a client
[
https://issues.apache.org/jira/browse/GEODE-9628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nabarun Nag reassigned GEODE-9628:
--
Assignee: Nabarun Nag
> Documentation fix for setting credentials in a client
> -
>
> Key: GEODE-9628
> URL: https://issues.apache.org/jira/browse/GEODE-9628
> Project: Geode
> Issue Type: Bug
> Components: docs
>Reporter: Nabarun Nag
>Assignee: Nabarun Nag
>Priority: Major
>
> Current:
> {noformat}
> How a Client Cache Sets Its CredentialIn order to connect with a locator or a
> server that does authentication, a client will need to set its credential,
> composed of the two properties security-username and security-password.
> Choose one of these two ways to accomplish this:{noformat}
> The last line needs to be changed to needing both the steps, instead of
> choosing one of the two steps
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9628) Documentation fix for setting credentials in a client
[
https://issues.apache.org/jira/browse/GEODE-9628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9628:
--
Labels: pull-request-available (was: )
> Documentation fix for setting credentials in a client
> -
>
> Key: GEODE-9628
> URL: https://issues.apache.org/jira/browse/GEODE-9628
> Project: Geode
> Issue Type: Bug
> Components: docs
>Reporter: Nabarun Nag
>Assignee: Nabarun Nag
>Priority: Major
> Labels: pull-request-available
>
> Current:
> {noformat}
> How a Client Cache Sets Its CredentialIn order to connect with a locator or a
> server that does authentication, a client will need to set its credential,
> composed of the two properties security-username and security-password.
> Choose one of these two ways to accomplish this:{noformat}
> The last line needs to be changed to needing both the steps, instead of
> choosing one of the two steps
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9629) GatewaySender.setRetriesToGetTransactionEventsFromQueue on public API
[ https://issues.apache.org/jira/browse/GEODE-9629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-9629: - Priority: Blocker (was: Major) > GatewaySender.setRetriesToGetTransactionEventsFromQueue on public API > - > > Key: GEODE-9629 > URL: https://issues.apache.org/jira/browse/GEODE-9629 > Project: Geode > Issue Type: Improvement > Components: wan >Affects Versions: 1.15.0 >Reporter: Udo Kohlmeyer >Priority: Blocker > > GatewaySender.setRetriesToGetTransactionEventsFromQueue is defined on the > public API. > The problem with this is that Geode should not allow for the simple > modification of settings for a GatewaySender. Without proper process / > management around the changing of the properties it would be too simple to > introduce side-effects by changing settings on the GatewaySender. > We (Geode) should NOT allow for the direct manipulation of configuration of > ANY component without it having gone through a controlled process, to ensure > that there aren't any side effects resulting from the change. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9629) GatewaySender.setRetriesToGetTransactionEventsFromQueue on public API
Udo Kohlmeyer created GEODE-9629: Summary: GatewaySender.setRetriesToGetTransactionEventsFromQueue on public API Key: GEODE-9629 URL: https://issues.apache.org/jira/browse/GEODE-9629 Project: Geode Issue Type: Improvement Components: wan Affects Versions: 1.15.0 Reporter: Udo Kohlmeyer GatewaySender.setRetriesToGetTransactionEventsFromQueue is defined on the public API. The problem with this is that Geode should not allow for the simple modification of settings for a GatewaySender. Without proper process / management around the changing of the properties it would be too simple to introduce side-effects by changing settings on the GatewaySender. We (Geode) should NOT allow for the direct manipulation of configuration of ANY component without it having gone through a controlled process, to ensure that there aren't any side effects resulting from the change. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9630) Gateway sender has public setter methods that should not be exposed
[ https://issues.apache.org/jira/browse/GEODE-9630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-9630: - Priority: Blocker (was: Major) > Gateway sender has public setter methods that should not be exposed > --- > > Key: GEODE-9630 > URL: https://issues.apache.org/jira/browse/GEODE-9630 > Project: Geode > Issue Type: Improvement > Components: wan >Affects Versions: 1.15.0 >Reporter: Udo Kohlmeyer >Priority: Blocker > > Looking at the GatewaySender interface I noticed there are numerous public > setter methods. Geode should not allow for the ability to directly change > GatewaySender functionality without proper process. > This is largely to avoid the introduction of side effects into the system. A > prime example of this is, the ability to call `setGroupTransactionEvents`, > which from what I understand should NEVER be allowed to be changed in just 1 > server instead of cluster-wide. This by writing a function and changing the > setting on only 1 server can run the risk of the whole system behaving > incorrectly causing failures which would be close to impossible to track down. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9630) Gateway sender has public setter methods that should not be exposed
Udo Kohlmeyer created GEODE-9630: Summary: Gateway sender has public setter methods that should not be exposed Key: GEODE-9630 URL: https://issues.apache.org/jira/browse/GEODE-9630 Project: Geode Issue Type: Improvement Components: wan Affects Versions: 1.15.0 Reporter: Udo Kohlmeyer Looking at the GatewaySender interface I noticed there are numerous public setter methods. Geode should not allow for the ability to directly change GatewaySender functionality without proper process. This is largely to avoid the introduction of side effects into the system. A prime example of this is, the ability to call `setGroupTransactionEvents`, which from what I understand should NEVER be allowed to be changed in just 1 server instead of cluster-wide. This by writing a function and changing the setting on only 1 server can run the risk of the whole system behaving incorrectly causing failures which would be close to impossible to track down. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9629) GatewaySender.setRetriesToGetTransactionEventsFromQueue on public API
[ https://issues.apache.org/jira/browse/GEODE-9629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-9629: Labels: blocks-1.15.0 (was: ) > GatewaySender.setRetriesToGetTransactionEventsFromQueue on public API > - > > Key: GEODE-9629 > URL: https://issues.apache.org/jira/browse/GEODE-9629 > Project: Geode > Issue Type: Improvement > Components: wan >Affects Versions: 1.15.0 >Reporter: Udo Kohlmeyer >Priority: Blocker > Labels: blocks-1.15.0 > > GatewaySender.setRetriesToGetTransactionEventsFromQueue is defined on the > public API. > The problem with this is that Geode should not allow for the simple > modification of settings for a GatewaySender. Without proper process / > management around the changing of the properties it would be too simple to > introduce side-effects by changing settings on the GatewaySender. > We (Geode) should NOT allow for the direct manipulation of configuration of > ANY component without it having gone through a controlled process, to ensure > that there aren't any side effects resulting from the change. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9630) Gateway sender has public setter methods that should not be exposed
[ https://issues.apache.org/jira/browse/GEODE-9630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-9630: Labels: blocks-1.15.0 (was: ) > Gateway sender has public setter methods that should not be exposed > --- > > Key: GEODE-9630 > URL: https://issues.apache.org/jira/browse/GEODE-9630 > Project: Geode > Issue Type: Improvement > Components: wan >Affects Versions: 1.15.0 >Reporter: Udo Kohlmeyer >Priority: Blocker > Labels: blocks-1.15.0 > > Looking at the GatewaySender interface I noticed there are numerous public > setter methods. Geode should not allow for the ability to directly change > GatewaySender functionality without proper process. > This is largely to avoid the introduction of side effects into the system. A > prime example of this is, the ability to call `setGroupTransactionEvents`, > which from what I understand should NEVER be allowed to be changed in just 1 > server instead of cluster-wide. This by writing a function and changing the > setting on only 1 server can run the risk of the whole system behaving > incorrectly causing failures which would be close to impossible to track down. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9522) When a server is force disconnected, it should set shutdown cause for dm to prevent clients recreating server connection.
[ https://issues.apache.org/jira/browse/GEODE-9522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418943#comment-17418943 ] Xiaojian Zhou commented on GEODE-9522: -- A detailed description of the issue and fix is here: When the membership received a request to remove itself from locator (this could be triggered by playDead), it will call GMSMembership.forceDisconnect() to close its DM then cache. However, the uncleanShutdownDS() which is running in DisconnectThread could take a few seconds (6-10) to close all the connections before it set shutdownCause in DM (which is used to trigger cancel exception in c/s request or distribution). Since it's running in a separate thread, the membership thought the forceDisconnect() is done while it's still closing connections. During this time windows, a client could re-initiate a ServerConnection, which could put event to cache and HARegionQueue. Those ServerConnection should be prevented in this time window because it will cause data mismatch. The idea to fix is to set shutdownCause in DM as early as possible (before closing connection). It will prevent the incoming AcceptorImpl socket request by triggering cancel exception. > When a server is force disconnected, it should set shutdown cause for dm to > prevent clients recreating server connection. > - > > Key: GEODE-9522 > URL: https://issues.apache.org/jira/browse/GEODE-9522 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Priority: Major > Labels: pull-request-available > > When a client is doing puts (mainly creates) to servers with replicated > region, shutdown some servers to force switching of primary HARegionQueue, > sometimes, the event with later event id is distributed by previous primary > HARegionQueue, which caused the events with earlier event ids are rejected by > clients. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7309) Upgrade Lucene from 6.6.2 to 8.2.0
[ https://issues.apache.org/jira/browse/GEODE-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17418952#comment-17418952 ] ASF subversion and git services commented on GEODE-7309: Commit 68629356f561a932f5dfbace70b01d9971a42473 in geode's branch refs/heads/develop from Mario Kevo [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6862935 ] GEODE-7309: uplift lucene to 7.1.0 (#6351) * GEODE-7309: uplift lucene to 7.1.0 > Upgrade Lucene from 6.6.2 to 8.2.0 > -- > > Key: GEODE-7309 > URL: https://issues.apache.org/jira/browse/GEODE-7309 > Project: Geode > Issue Type: Sub-task >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Labels: pull-request-available > Time Spent: 5.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
