[jira] [Commented] (GEODE-9333) SessionsAndCrashesDUnitTest.sessionOperationsDoNotFail_whileServersAreRestarted may fail due to IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/GEODE-9333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17355752#comment-17355752
]
Geode Integration commented on GEODE-9333:
--
Seen in [distributed-test-openjdk11
#6|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk11/builds/6]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0283/test-results/distributedTest/1622589146/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0283/test-artifacts/1622589146/distributedtestfiles-openjdk11-1.15.0-build.0283.tgz].
> SessionsAndCrashesDUnitTest.sessionOperationsDoNotFail_whileServersAreRestarted
> may fail due to IndexOutOfBoundsException
> -
>
> Key: GEODE-9333
> URL: https://issues.apache.org/jira/browse/GEODE-9333
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Jens Deppe
>Priority: Major
>
> Seen in a PR pre-checkin test run:
> {noformat}
> org.apache.geode.redis.session.SessionsAndCrashesDUnitTest >
> sessionOperationsDoNotFail_whileServersAreRestarted FAILED
> java.lang.IndexOutOfBoundsException: Index -5 out of bounds for length 100
> at jdk.internal.util.Preconditions.outOfBounds(Preconditions.java:64)
> at
> jdk.internal.util.Preconditions.outOfBoundsCheckIndex(Preconditions.java:70)
> at jdk.internal.util.Preconditions.checkIndex(Preconditions.java:248)
> at java.util.Objects.checkIndex(Objects.java:372)
> at java.util.ArrayList.get(ArrayList.java:459)
> at
> org.apache.geode.redis.session.SessionsAndCrashesDUnitTest.validateSessionAttributes(SessionsAndCrashesDUnitTest.java:179)
> at
> org.apache.geode.redis.session.SessionsAndCrashesDUnitTest.sessionOperationsDoNotFail_whileServersAreRestarted(SessionsAndCrashesDUnitTest.java:170)
> {noformat}
> This occurs in the below block when {{totalUpdates}} is less than
> {{NUM_SESSIONS}}.
> {code:java}
> for (int i = totalUpdates - NUM_SESSIONS; i < totalUpdates; i++) {
> int sessionIdx = i % NUM_SESSIONS;
> String sessionId = sessionIds.get(sessionIdx);
> ...
> {code}
> Running the test locally with some trace logging added, it seems that
> {{totalUpdates}} is typically ~120, so if something were to cause updates to
> be 20% slower on a run of the test, this failure could show up. A solution
> might be to either await until at least {{NUM_SESSIONS}} updates have been
> performed by the updater threads, or to put in some logic to handle the case
> when {{totalUpdates}} is less than {{NUM_SESSIONS}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9116) CI Failure: ParallelWANStatsDUnitTest fails when checking that batches with incomplete transactions should be 0
[ https://issues.apache.org/jira/browse/GEODE-9116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17355755#comment-17355755 ] Geode Integration commented on GEODE-9116: -- Seen in [distributed-test-openjdk8 #6|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk8/builds/6] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0283/test-results/distributedTest/1622589909/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0283/test-artifacts/1622589909/distributedtestfiles-openjdk8-1.15.0-build.0283.tgz]. > CI Failure: ParallelWANStatsDUnitTest fails when checking that batches with > incomplete transactions should be 0 > --- > > Key: GEODE-9116 > URL: https://issues.apache.org/jira/browse/GEODE-9116 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Benjamin P Ross >Priority: Major > > org.apache.geode.internal.cache.wan.parallel.ParallelWANStatsDUnitTest > > testPRParallelPropagationWithGroupTransactionEventsDoesNotSendBatchesWithIncompleteTransactionsIfGatewaySenderIsStoppedWhileReceivingTrafficAndLaterStarted > FAILED > java.lang.AssertionError: expected:<0> but was:<1> > at org.junit.Assert.fail(Assert.java:89) > at org.junit.Assert.failNotEquals(Assert.java:835) > at org.junit.Assert.assertEquals(Assert.java:647) > at org.junit.Assert.assertEquals(Assert.java:633) > at > org.apache.geode.internal.cache.wan.parallel.ParallelWANStatsDUnitTest.checkOnlyCompleteTransactionsAreReplicatedAfterSenderStopped(ParallelWANStatsDUnitTest.java:611) > at > org.apache.geode.internal.cache.wan.parallel.ParallelWANStatsDUnitTest.testPRParallelPropagationWithGroupTransactionEventsDoesNotSendBatchesWithIncompleteTransactionsIfGatewaySenderIsStoppedWhileReceivingTrafficAndLaterStarted(ParallelWANStatsDUnitTest.java:520) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9319) CI failure: session.NativeRedisSessionExpirationAcceptanceTest > classMethod FAILED
[
https://issues.apache.org/jira/browse/GEODE-9319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17355756#comment-17355756
]
Geode Integration commented on GEODE-9319:
--
Seen in [acceptance-test-openjdk11
#6|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk11/builds/6]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0283/test-results/acceptanceTest/1622590372/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0283/test-artifacts/1622590372/acceptancetestfiles-openjdk11-1.15.0-build.0283.tgz].
> CI failure: session.NativeRedisSessionExpirationAcceptanceTest > classMethod
> FAILED
> ---
>
> Key: GEODE-9319
> URL: https://issues.apache.org/jira/browse/GEODE-9319
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
>
> {noformat}
> session.NativeRedisSessionExpirationAcceptanceTest > classMethod FAILED
> 14:17:23java.lang.AssertionError: Suspicious strings were written to the
> log during this run.
> 14:17:23Fix the strings or use IgnoredException.addIgnoredException to
> ignore.
> 14:17:23
> ---
> 14:17:23Found suspect string in 'dunit_suspect-local.log' at line 287
> 14:17:23
> 14:17:23[error 2021/05/26 21:17:10.762 UTC tid=92]
> Failed to return response on inboundChannel
> 14:17:23io.netty.channel.StacklessClosedChannelException
> 14:17:23 at
> io.netty.channel.AbstractChannel$AbstractUnsafe.write(Object,
> ChannelPromise)(Unknown Source)
> 14:17:23at org.junit.Assert.fail(Assert.java:89)
> 14:17:23at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:409)
> 14:17:23at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:185)
> 14:17:23at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.access$100(ClusterStartupRule.java:69)
> 14:17:23at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:140)
> 14:17:23at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> 14:17:23at
> org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> 14:17:23at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> 14:17:23at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> 14:17:23at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> 14:17:23at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> 14:17:23at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> 14:17:23at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> 14:17:23at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 14:17:23at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 14:17:23at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 14:17:23at java.lang.reflect.Method.invoke(Method.java:566)
> 14:17:23at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
> 14:17:23at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> 14:17:23at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33)
> 14:17:23at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94)
> 14:17:23at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> 14:17:23at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:119)
> 14:17:23at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 14:17:23at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 14:17:23at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 14:17:23at java.lang.reflect.Method.invoke(Method.java:566)
> 14:17:23at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
> 14:17:23at
> org.gradle.interna
[jira] [Commented] (GEODE-7183) CI Failure: ClientServerFunctionExecutionDUnitTest > testServerExecution_SocketTimeOut_WithoutRegister[ExecuteFunctionById] failed with AssertionError
[
https://issues.apache.org/jira/browse/GEODE-7183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17355761#comment-17355761
]
Geode Integration commented on GEODE-7183:
--
Seen in [distributed-test-openjdk8
#7|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk8/builds/7]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0284/test-results/distributedTest/1622591082/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0284/test-artifacts/1622591082/distributedtestfiles-openjdk8-1.15.0-build.0284.tgz].
> CI Failure: ClientServerFunctionExecutionDUnitTest >
> testServerExecution_SocketTimeOut_WithoutRegister[ExecuteFunctionById] failed
> with AssertionError
> --
>
> Key: GEODE-7183
> URL: https://issues.apache.org/jira/browse/GEODE-7183
> Project: Geode
> Issue Type: Bug
> Components: functions
>Reporter: Barrett Oglesby
>Priority: Major
>
> {noformat}
> org.apache.geode.internal.cache.execute.ClientServerFunctionExecutionDUnitTest
> > testServerExecution_SocketTimeOut_WithoutRegister[ExecuteFunctionById]
> FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.execute.ClientServerFunctionExecutionDUnitTest$$Lambda$68/1900027546.run
> in VM 3 running on Host 6c6dc0c2627c 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.execute.ClientServerFunctionExecutionDUnitTest.testServerExecution_SocketTimeOut_WithoutRegister(ClientServerFunctionExecutionDUnitTest.java:339)
> Caused by:
> java.lang.AssertionError: Test failed after the execute operation
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.internal.cache.execute.ClientServerFunctionExecutionDUnitTest.allServerExecution(ClientServerFunctionExecutionDUnitTest.java:891)
> at
> org.apache.geode.internal.cache.execute.ClientServerFunctionExecutionDUnitTest.lambda$testServerExecution_SocketTimeOut_WithoutRegister$bb17a952$2(ClientServerFunctionExecutionDUnitTest.java:339)
> {noformat}
> The test logs this exception right before the failure:
> {noformat}
> [vm3] [info 2019/09/09 18:00:10.793 GMT Connection(26)-172.17.0.19> tid=0xb1] Exception :
> [vm3] org.apache.geode.cache.client.ServerConnectivityException: Pool
> unexpected SocketException connection=Pooled Connection to
> 6c6dc0c2627c:25980: Connection[DESTROYED]). Server unreachable: could not
> connect after 1 attempts
> [vm3] at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:659)
> [vm3] at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:501)
> [vm3] at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeOnServer(OpExecutorImpl.java:331)
> [vm3] at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeOn(OpExecutorImpl.java:300)
> [vm3] at
> org.apache.geode.cache.client.internal.PoolImpl.executeOn(PoolImpl.java:814)
> [vm3] at
> org.apache.geode.cache.client.internal.SingleHopOperationCallable.call(SingleHopOperationCallable.java:52)
> [vm3] at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> [vm3] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [vm3] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [vm3] at java.lang.Thread.run(Thread.java:748)
> [vm3] Caused by: java.net.SocketException: Socket is closed
> [vm3] at java.net.Socket.setSoTimeout(Socket.java:1137)
> [vm3] at
> org.apache.geode.cache.client.internal.AbstractOpWithTimeout.attempt(AbstractOpWithTimeout.java:48)
> [vm3] at
> org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:263)
> [vm3] at
> org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:353)
> [vm3] at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:750)
> [vm3] at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeOnServer(OpExecutorImpl.java:329)
> [vm3] ... 7 more
> {noformat}
> https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/DistributedTestOpenJDK8/builds/952
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
[jira] [Created] (GEODE-9340) Benchmark instability in PartitionedPutLongBenchmark
Sarah Abbey created GEODE-9340:
--
Summary: Benchmark instability in PartitionedPutLongBenchmark
Key: GEODE-9340
URL: https://issues.apache.org/jira/browse/GEODE-9340
Project: Geode
Issue Type: Bug
Components: benchmarks
Reporter: Sarah Abbey
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%
avg latency
Baseline: 1514276.31 Test: 1536263.99 Difference: +1.5%
PartitionedPutBytesBenchmark avg ops/sec
Baseline:457550.69 Test:456011.33 Difference: -0.3%
avg latency
Baseline: 1570713.84 Test: 1575841.02 Difference: +0.3%
PartitionedPutLongBenchmark avg ops/sec
Baseline:418221.79 Test:389221.70 Difference: -6.9%
avg latency
Baseline: 1717869.66
[jira] [Updated] (GEODE-9340) Benchmark instability in PartitionedPutLongBenchmark
[
https://issues.apache.org/jira/browse/GEODE-9340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sarah Abbey updated GEODE-9340:
---
Description:
PartitionedPutLongBenchmark failed in CI:
{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%
avg latency
Baseline: 1514276.31 Test: 1536263.99 Difference: +1.5%
PartitionedPutBytesBenchmark avg ops/sec
Baseline:457550.69 Test:456011.33 Difference: -0.3%
avg latency
Baseline: 1570713.84 Test: 1575841.02 Difference: +0.3%
PartitionedPutLongBenchmark avg ops/sec
Baseline:418221.79 Test:389221.70 Difference: -6.9%
avg latency
Baseline: 1717869.66 Test: 1849602.96 Difference: +7.7%
PartitionedPutStringBenchmark avg ops/sec
Baseline:410007.93 Test:390442.31 Difference: -4.8%
avg latency
Baseline: 1754915
[jira] [Updated] (GEODE-9340) Benchmark instability in PartitionedPutLongBenchmark
[
https://issues.apache.org/jira/browse/GEODE-9340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sarah Abbey updated GEODE-9340:
---
Description:
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%
avg latency
Baseline: 1514276.31 Test: 1536263.99 Difference: +1.5%
PartitionedPutBytesBenchmark avg ops/sec
Baseline:457550.69 Test:456011.33 Difference: -0.3%
avg latency
Baseline: 1570713.84 Test: 1575841.02 Difference: +0.3%
PartitionedPutLongBenchmark avg ops/sec
Baseline:418221.79 Test:389221.70 Difference: -6.9%
avg latency
Baseline: 1717869.66 Test: 1849602.96 Difference: +7.7%
PartitionedPutStringBenchmark avg ops/sec
Baseline:410007.93 Test:390442.31 Dif
[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=17355781#comment-17355781
]
Geode Integration commented on GEODE-9340:
--
Seen in [benchmark-base
#6|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/6].
> Benchmark instability in PartitionedPutLongBenchmark
>
>
> Key: GEODE-9340
> URL: https://issues.apache.org/jira/browse/GEODE-9340
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Reporter: Sarah Abbey
>Priority: Major
>
> 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%
> avg latency
> Baseline: 1514276.31 Test: 1536263.99 Difference:
[jira] [Updated] (GEODE-9340) Benchmark instability in PartitionedPutLongBenchmark
[
https://issues.apache.org/jira/browse/GEODE-9340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sarah Abbey updated GEODE-9340:
---
Affects Version/s: 1.15.0
> 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
>Priority: Major
>
> 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%
> avg latency
> Baseline: 1514276.31 Test: 1536263.99 Difference: +1.5%
> PartitionedPutBytesBenchmark avg ops/sec
> Baseline:457550.69 Test:456011.33 Difference: -0.3
[jira] [Commented] (GEODE-9318) implement ZREM command
[ https://issues.apache.org/jira/browse/GEODE-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17355807#comment-17355807 ] ASF subversion and git services commented on GEODE-9318: Commit 81828af9c198774fb5855be0cc9cbad0d262e3e2 in geode's branch refs/heads/develop from Eric Shu [ https://gitbox.apache.org/repos/asf?p=geode.git;h=81828af ] GEODE-9318: Implement ZREM command. (#6545) > implement ZREM command > -- > > Key: GEODE-9318 > URL: https://issues.apache.org/jira/browse/GEODE-9318 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available > > Part of the redis supported command for sorted set. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9318) implement ZREM command
[ https://issues.apache.org/jira/browse/GEODE-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-9318: Component/s: (was: redis) > implement ZREM command > -- > > Key: GEODE-9318 > URL: https://issues.apache.org/jira/browse/GEODE-9318 > Project: Geode > Issue Type: New Feature >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available > > Part of the redis supported command for sorted set. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9318) implement ZREM command
[ https://issues.apache.org/jira/browse/GEODE-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-9318: Component/s: redis > implement ZREM command > -- > > Key: GEODE-9318 > URL: https://issues.apache.org/jira/browse/GEODE-9318 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available > > Part of the redis supported command for sorted set. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9318) implement ZREM command
[ https://issues.apache.org/jira/browse/GEODE-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu resolved GEODE-9318. - Resolution: Fixed > implement ZREM command > -- > > Key: GEODE-9318 > URL: https://issues.apache.org/jira/browse/GEODE-9318 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available > > Part of the redis supported command for sorted set. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9318) implement ZREM command
[ https://issues.apache.org/jira/browse/GEODE-9318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-9318: Fix Version/s: 1.15.0 > implement ZREM command > -- > > Key: GEODE-9318 > URL: https://issues.apache.org/jira/browse/GEODE-9318 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Part of the redis supported command for sorted set. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9331) ConnectionTable maintains WeakReference to thread local map for no reason
[ https://issues.apache.org/jira/browse/GEODE-9331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17355845#comment-17355845 ] ASF subversion and git services commented on GEODE-9331: Commit 88918f1221e7bf90c88596d19c06ec41eec8315e in geode's branch refs/heads/develop from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=88918f1 ] GEODE-9331: remove the threadConnMaps ArrayList (#6535) Removed the threadConnMaps ArrayList. This removal also means that the HashMap is now only referenced by a ThreadLocal so it no longer is synchronized which simplified the code. > ConnectionTable maintains WeakReference to thread local map for no reason > - > > Key: GEODE-9331 > URL: https://issues.apache.org/jira/browse/GEODE-9331 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > Every time a p2p thread owned connection is created it is added to a HashMap > kept by the thread in a ThreadLocal. A WeakReference referencing that HashMap > is also added to an ArrayList. But this ArrayList is not actually used for > anything. It is iterated over in ConnectionTable.close to close any of the > thread local connections but all of these connections are also in the > "threadConnectionMap" which is iterated over during close. > So the ArrayList "threadConnMaps" can be removed with no loss of > functionality. Getting rid of it will improve performance the first time a > thread creates a thread owned connection and will reduce the amount of memory > consumed (the ArrayList will have at least one entry for every thread using > thread owned connections but it may have more since the WeakReference can be > slow to be garbage collected). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9331) ConnectionTable maintains WeakReference to thread local map for no reason
[ https://issues.apache.org/jira/browse/GEODE-9331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-9331. - Fix Version/s: 1.15.0 Resolution: Fixed > ConnectionTable maintains WeakReference to thread local map for no reason > - > > Key: GEODE-9331 > URL: https://issues.apache.org/jira/browse/GEODE-9331 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > Every time a p2p thread owned connection is created it is added to a HashMap > kept by the thread in a ThreadLocal. A WeakReference referencing that HashMap > is also added to an ArrayList. But this ArrayList is not actually used for > anything. It is iterated over in ConnectionTable.close to close any of the > thread local connections but all of these connections are also in the > "threadConnectionMap" which is iterated over during close. > So the ArrayList "threadConnMaps" can be removed with no loss of > functionality. Getting rid of it will improve performance the first time a > thread creates a thread owned connection and will reduce the amount of memory > consumed (the ArrayList will have at least one entry for every thread using > thread owned connections but it may have more since the WeakReference can be > slow to be garbage collected). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7812) PutAllClientServerDistributedTest.testEventIdMisorderInPRSingleHop is failing
[
https://issues.apache.org/jira/browse/GEODE-7812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund reassigned GEODE-7812:
Assignee: Kirk Lund (was: Mark Hanson)
> PutAllClientServerDistributedTest.testEventIdMisorderInPRSingleHop is failing
> -
>
> Key: GEODE-7812
> URL: https://issues.apache.org/jira/browse/GEODE-7812
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Assignee: Kirk Lund
>Priority: Major
> Labels: flaky
> Attachments: Exception.txt, entries.txt,
> repository-open-graph-template (2).png
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PutAllClientServerDistributedTest$$Lambda$510/1407303081.run
> in VM 3 running on Host d8813bc515cd with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at
> org.apache.geode.internal.cache.PutAllClientServerDistributedTest.testEventIdMisorderInPRSingleHop(PutAllClientServerDistributedTest.java:2356)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:59)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:59)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:449)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:393)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.ja
[jira] [Commented] (GEODE-9339) bump json-smart to recommended version
[ https://issues.apache.org/jira/browse/GEODE-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17355858#comment-17355858 ] ASF subversion and git services commented on GEODE-9339: Commit 44e5d4e8e078b4b45f1ab36658330e38c1b868d5 in geode's branch refs/heads/develop from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=44e5d4e ] GEODE-9339: bump json-smart from 2.3 to 2.3.1 (#6547) > bump json-smart to recommended version > -- > > Key: GEODE-9339 > URL: https://issues.apache.org/jira/browse/GEODE-9339 > Project: Geode > Issue Type: Improvement > Components: management >Affects Versions: 1.12.2, 1.13.2, 1.14.0, 1.15.0 >Reporter: Owen Nichols >Priority: Major > Labels: blocks-1.14.0, pull-request-available > > json-smart 2.3 should be updated to 2.3.1 > (fyi json-smart is used by json-path, not directly by Geode) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-4826) Fail fast with Spotless and rat checks
[ https://issues.apache.org/jira/browse/GEODE-4826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Houghton resolved GEODE-4826. Fix Version/s: 1.15.0 Resolution: Fixed > Fail fast with Spotless and rat checks > -- > > Key: GEODE-4826 > URL: https://issues.apache.org/jira/browse/GEODE-4826 > Project: Geode > Issue Type: New Feature >Reporter: Michael W. Dodge >Assignee: Robert Houghton >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The Spotless and rat checks happened at the *end* of the build, which makes > them fail as slowly as possible. Enhance developer productivity by putting > those checks (and the potential for concomitant failures) at the *beginning* > of the build. Also, investigate automatically applying the Spotless rules to > prevent any possibility of a failed Spotless check. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-4826) Fail fast with Spotless and rat checks
[ https://issues.apache.org/jira/browse/GEODE-4826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17355931#comment-17355931 ] ASF subversion and git services commented on GEODE-4826: Commit a0521313dd2fc27d7441dba3a8d66aeb645298b1 in geode's branch refs/heads/develop from Robert Houghton [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a052131 ] GEODE-4826: we didn't need spotless for srcDistTar anyway (#6543) > Fail fast with Spotless and rat checks > -- > > Key: GEODE-4826 > URL: https://issues.apache.org/jira/browse/GEODE-4826 > Project: Geode > Issue Type: New Feature >Reporter: Michael W. Dodge >Assignee: Robert Houghton >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The Spotless and rat checks happened at the *end* of the build, which makes > them fail as slowly as possible. Enhance developer productivity by putting > those checks (and the potential for concomitant failures) at the *beginning* > of the build. Also, investigate automatically applying the Spotless rules to > prevent any possibility of a failed Spotless check. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9341) Fix Redis Session tests to correctly retry commands as necessary
Jens Deppe created GEODE-9341: - Summary: Fix Redis Session tests to correctly retry commands as necessary Key: GEODE-9341 URL: https://issues.apache.org/jira/browse/GEODE-9341 Project: Geode Issue Type: Test Components: redis Reporter: Jens Deppe The following tests are disabled as part of this PR: - NativeRedisSessionAcceptanceTest - RedisSessionDUnitTest - NativeRedisSessionExpirationAcceptanceTest - SessionExpirationDUnitTest It seems to be almost impossible to have Spring/Lettuce retry commands so that tests are not flaky. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9306) Implement **ZINCRBY**
[ https://issues.apache.org/jira/browse/GEODE-9306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hale Bales reassigned GEODE-9306: - Assignee: Hale Bales > Implement **ZINCRBY** > - > > Key: GEODE-9306 > URL: https://issues.apache.org/jira/browse/GEODE-9306 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0 >Reporter: Hale Bales >Assignee: Hale Bales >Priority: Major > Labels: pull-request-available > > Implement the ZINCRBY Redis command. https://redis.io/commands/zincrby > AC > Unit and integration tests for ZINCRBY command -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9335) Organize HitsMissesIntegrationTest
[ https://issues.apache.org/jira/browse/GEODE-9335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9335: -- Labels: pull-request-available (was: ) > Organize HitsMissesIntegrationTest > -- > > Key: GEODE-9335 > URL: https://issues.apache.org/jira/browse/GEODE-9335 > Project: Geode > Issue Type: Task > Components: redis >Affects Versions: 1.15.0 >Reporter: Hale Bales >Priority: Major > Labels: pull-request-available > > the HitsMissesIntegrationTest has sections divided by comments to keep all > the supported commands separate from the unsupported ones, and to keep > commands of the same type together within the supported/unsupported sections. > as we added more supported commands, we didn't move the tests into the right > section. > A.C. > All the tests that test supported commands have been moved to the appropriate > section. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8609) Create a dunit suspect file per VM
[
https://issues.apache.org/jira/browse/GEODE-8609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17355958#comment-17355958
]
ASF subversion and git services commented on GEODE-8609:
Commit e39c4c5ad79ee07d7760c98a85259cfb68c64e4c in geode's branch
refs/heads/develop from Nabarun Nag
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=e39c4c5 ]
GEODE-8609: Check logs for suspicious logs when VM is stopped.
* When a VM is stopped, the suspect string file is deleted
* Log checker is called at the end of the test.
* If a VM is restarted during a test, the logs are deleted and is not
checked at the end of the test.
* With the fix the logs are checked when the VM is stopped.
> Create a dunit suspect file per VM
> --
>
> Key: GEODE-8609
> URL: https://issues.apache.org/jira/browse/GEODE-8609
> Project: Geode
> Issue Type: Test
> Components: tests
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
> Fix For: 1.14.0
>
>
> In some situations, especially when restarting Dunit VMs, it appears that the
> suspect log file can be corrupted since suspect processing reports errors
> such as:
> {noformat}
> org.apache.geode.redis.internal.executor.CrashAndNoRepeatDUnitTest >
> classMethod FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 19594
> /home/geode/.gradle/caches/modules-2/files-2.1/antlr/antlr/2.7.7/83cd2cd674a21[warn
> 2020/10/11 15:23:24.988 GMT tid=105] Execution
> of Redis command APPEND append-key-1 -append-key-1-17484- failed:
> org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.cache.execute.FunctionInvocationTargetException:
> memberDeparted event for < 172.17.0.20(server-3:2004):41003 > crashed,
> true{noformat}
> Where the suspected string is corrupted.
> The proposed fix will create a new dunit_suspect log for each VM. The logs
> will now be named {{dunit_suspect-vm.log}}. The {{locator}} vm and the
> test runner vm will have logs named {{dunit_suspect-locator.log}} and
> {{dunit_suspect-local.log}} respectively.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9342) Handle a double reply of "Infinite" in the same way as Redis
Sarah Abbey created GEODE-9342:
--
Summary: Handle a double reply of "Infinite" in the same way as
Redis
Key: GEODE-9342
URL: https://issues.apache.org/jira/browse/GEODE-9342
Project: Geode
Issue Type: Improvement
Components: redis
Affects Versions: 1.15.0
Reporter: Sarah Abbey
Currently, in `Coder.java` `stringToDouble` and `doubleToString` methods, we
return "Infinity" or "-Infinity", but native Redis returns "inf" or "-inf"
respectively, as seen in `networking.c`:
{code:java}
void addReplyDouble(client *c, double d) {
char dbuf[128], sbuf[128];
int dlen, slen;
if (isinf(d)) {
/* Libc in odd systems (Hi Solaris!) will format infinite in a
* different way, so better to handle it in an explicit way. */
addReplyBulkCString(c, d > 0 ? "inf" : "-inf");
} else {
dlen = snprintf(dbuf,sizeof(dbuf),"%.17g",d);
slen = snprintf(sbuf,sizeof(sbuf),"$%d\r\n%s\r\n",dlen,dbuf);
addReplyString(c,sbuf,slen);
}
}
{code}
We should return "inf" or "-inf" like native Redis.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9342) Handle a double reply of "inf" in the same way as Redis
[
https://issues.apache.org/jira/browse/GEODE-9342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sarah Abbey updated GEODE-9342:
---
Summary: Handle a double reply of "inf" in the same way as Redis (was:
Handle a double reply of "Infinite" in the same way as Redis)
> Handle a double reply of "inf" in the same way as Redis
> ---
>
> Key: GEODE-9342
> URL: https://issues.apache.org/jira/browse/GEODE-9342
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Sarah Abbey
>Priority: Major
>
> Currently, in `Coder.java` `stringToDouble` and `doubleToString` methods, we
> return "Infinity" or "-Infinity", but native Redis returns "inf" or "-inf"
> respectively, as seen in `networking.c`:
> {code:java}
> void addReplyDouble(client *c, double d) {
> char dbuf[128], sbuf[128];
> int dlen, slen;
> if (isinf(d)) {
> /* Libc in odd systems (Hi Solaris!) will format infinite in a
> * different way, so better to handle it in an explicit way. */
> addReplyBulkCString(c, d > 0 ? "inf" : "-inf");
> } else {
> dlen = snprintf(dbuf,sizeof(dbuf),"%.17g",d);
> slen = snprintf(sbuf,sizeof(sbuf),"$%d\r\n%s\r\n",dlen,dbuf);
> addReplyString(c,sbuf,slen);
> }
> }
> {code}
> We should return "inf" or "-inf" like native Redis.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9343) Refactoring: move getInfo() method from INFO command to a TestHelper class
Eric Shu created GEODE-9343: --- Summary: Refactoring: move getInfo() method from INFO command to a TestHelper class Key: GEODE-9343 URL: https://issues.apache.org/jira/browse/GEODE-9343 Project: Geode Issue Type: Bug Components: redis Reporter: Eric Shu the getInfo() method is used throughout our tests to parse the data returned by the INFO command. There is a lot of duplication of this implementation, which is risky for future development. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9343) Refactoring: move getInfo() method from INFO command to a TestHelper class
[ https://issues.apache.org/jira/browse/GEODE-9343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu reassigned GEODE-9343: --- Assignee: Eric Shu > Refactoring: move getInfo() method from INFO command to a TestHelper class > -- > > Key: GEODE-9343 > URL: https://issues.apache.org/jira/browse/GEODE-9343 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > > the getInfo() method is used throughout our tests to parse the data returned > by the INFO command. There is a lot of duplication of this implementation, > which is risky for future development. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-5304) RemoteTransactionCCEDUnitTest.testValuesIteratorOnDestroy FAILED
[
https://issues.apache.org/jira/browse/GEODE-5304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-5304:
--
Labels: pull-request-available (was: )
> RemoteTransactionCCEDUnitTest.testValuesIteratorOnDestroy FAILED
>
>
> Key: GEODE-5304
> URL: https://issues.apache.org/jira/browse/GEODE-5304
> Project: Geode
> Issue Type: Bug
> Components: tests, transactions
>Reporter: Eric Shu
>Assignee: Louis R. Jacome
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> This failed in one of the precheckin run.
> The test assume that the accessor.invoke will use the some thread each time,
> but the assumption is wrong.
> Test could use suspend and resume the transaction to make sure the
> transaction can continue in different invoke methods.
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest$58.call in VM 0
> running on Host 79f3f35365c7 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:436)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:405)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:371)
> at
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest.doTestIterator(RemoteTransactionDUnitTest.java:2086)
> at
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest.testValuesIteratorOnDestroy(RemoteTransactionDUnitTest.java:2013)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
> at sun.reflect.NativeMeth
[jira] [Commented] (GEODE-9139) SSLException in starting up a Locator
[
https://issues.apache.org/jira/browse/GEODE-9139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17355971#comment-17355971
]
ASF subversion and git services commented on GEODE-9139:
Commit 863835969db3b5408764887aeeaf3b6943040c68 in geode's branch
refs/heads/support/1.14 from Ernie Burghardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=8638359 ]
GEODE-9139 SSLException in starting up a Locator (#6308)(#6401)
* Preserve the bind-address string specified by the user for
cluster communications
* Enabled use of hostnames in member identifiers if endpoint
validation is enabled.
* Retain the bind-address string or bind-address InetAddress in a
HostAddress
* HostAndPort could not be used because there will be a port set
but there may not be a bind-address set. That class requires a host name.
* Simplify HostAndPort & HostAddress by creating a common superclass
to hold their InetSocketAddress.
* Cache the result of attempting to resolve the hostname.
* Retain the string passed in as the hostname to avoid things like
127.0.0.1 being converted to localhost
* Added comments about retention of the hostname parameter
Co-authored-by: Bruce Schuchardt
(cherry picked from commit 55921a4d7b66a51279e71d1a665dc797fcc8ca6f)
> SSLException in starting up a Locator
> -
>
> Key: GEODE-9139
> URL: https://issues.apache.org/jira/browse/GEODE-9139
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
> Fix For: 1.15.0
>
>
> If you start up a locator using its host name, without a domain name, as a
> bind address you may get an SSLException in the form
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative DNS name matching hostname.domainname found
> {noformat}
> The LocatorLauncher and InternalLocator throw away the bind address string
> and later do a reverse lookup to find the fully qualified hostname to use in
> endpoint identification matching.If the locator's own TLS certificate
> doesn't have the fully qualified name in it as a Subject Alternate Name the
> connection that the Locator makes to its own location service will fail.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9343) Refactoring: move getInfo() method from INFO command to a TestHelper class
[ https://issues.apache.org/jira/browse/GEODE-9343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9343: -- Labels: pull-request-available (was: ) > Refactoring: move getInfo() method from INFO command to a TestHelper class > -- > > Key: GEODE-9343 > URL: https://issues.apache.org/jira/browse/GEODE-9343 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available > > the getInfo() method is used throughout our tests to parse the data returned > by the INFO command. There is a lot of duplication of this implementation, > which is risky for future development. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9339) bump json-smart to recommended version
[ https://issues.apache.org/jira/browse/GEODE-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17355972#comment-17355972 ] ASF subversion and git services commented on GEODE-9339: Commit 07010d24ca00aa964459c1f8ac529b86506cdc6e in geode's branch refs/heads/support/1.14 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=07010d2 ] GEODE-9339: bump json-smart from 2.3 to 2.3.1 (cherry picked from commit b3b86bb1b2919f0faadf239046883c217d3e2d80) > bump json-smart to recommended version > -- > > Key: GEODE-9339 > URL: https://issues.apache.org/jira/browse/GEODE-9339 > Project: Geode > Issue Type: Improvement > Components: management >Affects Versions: 1.12.2, 1.13.2, 1.14.0, 1.15.0 >Reporter: Owen Nichols >Priority: Major > Labels: blocks-1.14.0, pull-request-available > > json-smart 2.3 should be updated to 2.3.1 > (fyi json-smart is used by json-path, not directly by Geode) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9339) bump json-smart to recommended version
[ https://issues.apache.org/jira/browse/GEODE-9339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-9339. - Fix Version/s: 1.15.0 1.14.0 1.13.3 1.12.3 Resolution: Fixed > bump json-smart to recommended version > -- > > Key: GEODE-9339 > URL: https://issues.apache.org/jira/browse/GEODE-9339 > Project: Geode > Issue Type: Improvement > Components: management >Affects Versions: 1.12.2, 1.13.2, 1.14.0, 1.15.0 >Reporter: Owen Nichols >Priority: Major > Labels: blocks-1.14.0, pull-request-available > Fix For: 1.12.3, 1.13.3, 1.14.0, 1.15.0 > > > json-smart 2.3 should be updated to 2.3.1 > (fyi json-smart is used by json-path, not directly by Geode) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7861) Improve error reporting when a member is unable to contact a locator
[
https://issues.apache.org/jira/browse/GEODE-7861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-7861:
Fix Version/s: 1.13.3
> Improve error reporting when a member is unable to contact a locator
>
>
> Key: GEODE-7861
> URL: https://issues.apache.org/jira/browse/GEODE-7861
> Project: Geode
> Issue Type: Improvement
> Components: membership
>Reporter: Dan Smith
>Assignee: Kamilla Aslami
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.13.3, 1.14.0
>
>
> When a member is unable to contact a join the system due to a failure to
> contact a locator, we could be a lot more specific, which would help users
> debug issues in their environment. We currently print out
> {noformat}
> Unable to join the distributed system. Operation either timed out, was
> stopped or Locator does not exist.
> {noformat}
> We should include the underlying exception from the last locator we tried to
> contact as a cause, so that users can see why it failed (DNS error, ???).
> Perhaps also the list of locators we tried to contact.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9139) SSLException in starting up a Locator
[
https://issues.apache.org/jira/browse/GEODE-9139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-9139:
Fix Version/s: 1.14.0
1.13.3
> SSLException in starting up a Locator
> -
>
> Key: GEODE-9139
> URL: https://issues.apache.org/jira/browse/GEODE-9139
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
> Fix For: 1.13.3, 1.14.0, 1.15.0
>
>
> If you start up a locator using its host name, without a domain name, as a
> bind address you may get an SSLException in the form
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative DNS name matching hostname.domainname found
> {noformat}
> The LocatorLauncher and InternalLocator throw away the bind address string
> and later do a reverse lookup to find the fully qualified hostname to use in
> endpoint identification matching.If the locator's own TLS certificate
> doesn't have the fully qualified name in it as a Subject Alternate Name the
> connection that the Locator makes to its own location service will fail.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7861) Improve error reporting when a member is unable to contact a locator
[
https://issues.apache.org/jira/browse/GEODE-7861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17355990#comment-17355990
]
ASF subversion and git services commented on GEODE-7861:
Commit 53d32c325c808d6e965a45cdf36aca1a71db2183 in geode's branch
refs/heads/support/1.13 from Kamilla Aslami
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=53d32c3 ]
GEODE-7861: Improve error reporting in GMSJoinLeave.join() (#5839)
* GEODE-7861: Improve error reporting in GMSJoinLeave.join()
* Fix LocatorDUnitTest.testNoLocator
* Changes after the code review
* Fix typo
(cherry picked from commit 089c1ba7e20606f8201a4cd8f7221f6adc60ba5c)
> Improve error reporting when a member is unable to contact a locator
>
>
> Key: GEODE-7861
> URL: https://issues.apache.org/jira/browse/GEODE-7861
> Project: Geode
> Issue Type: Improvement
> Components: membership
>Reporter: Dan Smith
>Assignee: Kamilla Aslami
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.13.3, 1.14.0
>
>
> When a member is unable to contact a join the system due to a failure to
> contact a locator, we could be a lot more specific, which would help users
> debug issues in their environment. We currently print out
> {noformat}
> Unable to join the distributed system. Operation either timed out, was
> stopped or Locator does not exist.
> {noformat}
> We should include the underlying exception from the last locator we tried to
> contact as a cause, so that users can see why it failed (DNS error, ???).
> Perhaps also the list of locators we tried to contact.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8206) CI Failure: ReconnectWithClusterConfigurationDUnitTest.testReconnectAfterMeltdown hang
[
https://issues.apache.org/jira/browse/GEODE-8206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-8206:
Fix Version/s: 1.13.3
> CI Failure:
> ReconnectWithClusterConfigurationDUnitTest.testReconnectAfterMeltdown hang
> --
>
> Key: GEODE-8206
> URL: https://issues.apache.org/jira/browse/GEODE-8206
> Project: Geode
> Issue Type: Bug
> Components: ci, membership
>Reporter: Eric Shu
>Assignee: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.13.3, 1.14.0
>
>
> This test hangs in:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/221#A
> {noformat}
> "RMI TCP Connection(1)-172.17.0.23" #32 daemon prio=5 os_prio=0
> tid=0x7fea58001800 nid=0x27d waiting on condition [0x7feb23bf7000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xe0e6cb10> (a
> java.util.concurrent.CountDownLatch$Sync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72)
> at
> org.apache.geode.internal.cache.LocalRegion.waitOnInitialization(LocalRegion.java:4693)
> at
> org.apache.geode.internal.cache.LocalRegion.waitOnInitialization(LocalRegion.java:4671)
> at
> org.apache.geode.internal.cache.LocalRegion.getSubregion(LocalRegion.java:4558)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getRegion(GemFireCacheImpl.java:3322)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getRegion(GemFireCacheImpl.java:3153)
> at
> org.apache.geode.distributed.internal.InternalConfigurationPersistenceService.getConfigurationRegion(InternalConfigurationPersistenceService.java:792)
> at
> org.apache.geode.distributed.internal.InternalConfigurationPersistenceService.destroySharedConfiguration(InternalConfigurationPersistenceService.java:639)
> at
> org.apache.geode.cache30.ReconnectWithClusterConfigurationDUnitTest.lambda$teardown$bb17a952$1(ReconnectWithClusterConfigurationDUnitTest.java:112)
> at
> org.apache.geode.cache30.ReconnectWithClusterConfigurationDUnitTest$$Lambda$339/1176989958.run(Unknown
> Source)
> 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/2049270388.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
[jira] [Commented] (GEODE-9139) SSLException in starting up a Locator
[
https://issues.apache.org/jira/browse/GEODE-9139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17355992#comment-17355992
]
ASF subversion and git services commented on GEODE-9139:
Commit a55e472e9fdeb4b0373199463119b340b0cf90a3 in geode's branch
refs/heads/support/1.13 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a55e472 ]
GEODE-9139 SSLException in starting up a Locator (#6308)
* GEODE-9139 SSLException in starting up a Locator
Preserve the bind-address string specified by the user for cluster
communications
Also enable use of host names in member identifiers if endpoint
validation is enabled.
* retain the bind address string or bind address InetAddress in a HostAddress
HostAndPort could not be used because there will be a port set but there
may not be a bindAddress set. That class requires a host name.
* fixed NPE
* fixing a few problems with HostAddress
* spA
* fixed lgtm issue
* more lgtm issues fixed
* addressing Kamilla's comments
* typo
* simplify HostAndPort & HostAddress by creating a common superclass to hold
their InetSocketAddress.
Cache the result of attempting to resolve the host name, as suggested by
Bill.
* retain the string passed in as the hostname to avoid things like 127.0.0.1
being converted to localhost
* added comments about retention of the hostName parameter
(cherry picked from commit 55921a4d7b66a51279e71d1a665dc797fcc8ca6f)
> SSLException in starting up a Locator
> -
>
> Key: GEODE-9139
> URL: https://issues.apache.org/jira/browse/GEODE-9139
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
> Fix For: 1.13.3, 1.14.0, 1.15.0
>
>
> If you start up a locator using its host name, without a domain name, as a
> bind address you may get an SSLException in the form
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative DNS name matching hostname.domainname found
> {noformat}
> The LocatorLauncher and InternalLocator throw away the bind address string
> and later do a reverse lookup to find the fully qualified hostname to use in
> endpoint identification matching.If the locator's own TLS certificate
> doesn't have the fully qualified name in it as a Subject Alternate Name the
> connection that the Locator makes to its own location service will fail.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7861) Improve error reporting when a member is unable to contact a locator
[
https://issues.apache.org/jira/browse/GEODE-7861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17355989#comment-17355989
]
ASF subversion and git services commented on GEODE-7861:
Commit 53d32c325c808d6e965a45cdf36aca1a71db2183 in geode's branch
refs/heads/support/1.13 from Kamilla Aslami
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=53d32c3 ]
GEODE-7861: Improve error reporting in GMSJoinLeave.join() (#5839)
* GEODE-7861: Improve error reporting in GMSJoinLeave.join()
* Fix LocatorDUnitTest.testNoLocator
* Changes after the code review
* Fix typo
(cherry picked from commit 089c1ba7e20606f8201a4cd8f7221f6adc60ba5c)
> Improve error reporting when a member is unable to contact a locator
>
>
> Key: GEODE-7861
> URL: https://issues.apache.org/jira/browse/GEODE-7861
> Project: Geode
> Issue Type: Improvement
> Components: membership
>Reporter: Dan Smith
>Assignee: Kamilla Aslami
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.13.3, 1.14.0
>
>
> When a member is unable to contact a join the system due to a failure to
> contact a locator, we could be a lot more specific, which would help users
> debug issues in their environment. We currently print out
> {noformat}
> Unable to join the distributed system. Operation either timed out, was
> stopped or Locator does not exist.
> {noformat}
> We should include the underlying exception from the last locator we tried to
> contact as a cause, so that users can see why it failed (DNS error, ???).
> Perhaps also the list of locators we tried to contact.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9139) SSLException in starting up a Locator
[
https://issues.apache.org/jira/browse/GEODE-9139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17355991#comment-17355991
]
ASF subversion and git services commented on GEODE-9139:
Commit a55e472e9fdeb4b0373199463119b340b0cf90a3 in geode's branch
refs/heads/support/1.13 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a55e472 ]
GEODE-9139 SSLException in starting up a Locator (#6308)
* GEODE-9139 SSLException in starting up a Locator
Preserve the bind-address string specified by the user for cluster
communications
Also enable use of host names in member identifiers if endpoint
validation is enabled.
* retain the bind address string or bind address InetAddress in a HostAddress
HostAndPort could not be used because there will be a port set but there
may not be a bindAddress set. That class requires a host name.
* fixed NPE
* fixing a few problems with HostAddress
* spA
* fixed lgtm issue
* more lgtm issues fixed
* addressing Kamilla's comments
* typo
* simplify HostAndPort & HostAddress by creating a common superclass to hold
their InetSocketAddress.
Cache the result of attempting to resolve the host name, as suggested by
Bill.
* retain the string passed in as the hostname to avoid things like 127.0.0.1
being converted to localhost
* added comments about retention of the hostName parameter
(cherry picked from commit 55921a4d7b66a51279e71d1a665dc797fcc8ca6f)
> SSLException in starting up a Locator
> -
>
> Key: GEODE-9139
> URL: https://issues.apache.org/jira/browse/GEODE-9139
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
> Fix For: 1.13.3, 1.14.0, 1.15.0
>
>
> If you start up a locator using its host name, without a domain name, as a
> bind address you may get an SSLException in the form
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative DNS name matching hostname.domainname found
> {noformat}
> The LocatorLauncher and InternalLocator throw away the bind address string
> and later do a reverse lookup to find the fully qualified hostname to use in
> endpoint identification matching.If the locator's own TLS certificate
> doesn't have the fully qualified name in it as a Subject Alternate Name the
> connection that the Locator makes to its own location service will fail.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8206) CI Failure: ReconnectWithClusterConfigurationDUnitTest.testReconnectAfterMeltdown hang
[
https://issues.apache.org/jira/browse/GEODE-8206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17355993#comment-17355993
]
ASF subversion and git services commented on GEODE-8206:
Commit aba29fb7dd236ecd8f784672c50236d7983332a0 in geode's branch
refs/heads/support/1.13 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=aba29fb ]
GEODE-8206: CI Failure:
ReconnectWithClusterConfigurationDUnitTest.testReconnectAfterMeltdown hang
(#5192)
Modified the test to set the correct locator ports.
Modified the teardown code to tell the cache to stop
reconnecting.
Modified each run to use a temporary working directory so that runs
don't leave behind artifacts on disk that can taint subsequent runs.
(cherry picked from commit 426d7fd41d0d66a7557f86236d6773f582e7ef0a)
> CI Failure:
> ReconnectWithClusterConfigurationDUnitTest.testReconnectAfterMeltdown hang
> --
>
> Key: GEODE-8206
> URL: https://issues.apache.org/jira/browse/GEODE-8206
> Project: Geode
> Issue Type: Bug
> Components: ci, membership
>Reporter: Eric Shu
>Assignee: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.13.3, 1.14.0
>
>
> This test hangs in:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/221#A
> {noformat}
> "RMI TCP Connection(1)-172.17.0.23" #32 daemon prio=5 os_prio=0
> tid=0x7fea58001800 nid=0x27d waiting on condition [0x7feb23bf7000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xe0e6cb10> (a
> java.util.concurrent.CountDownLatch$Sync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72)
> at
> org.apache.geode.internal.cache.LocalRegion.waitOnInitialization(LocalRegion.java:4693)
> at
> org.apache.geode.internal.cache.LocalRegion.waitOnInitialization(LocalRegion.java:4671)
> at
> org.apache.geode.internal.cache.LocalRegion.getSubregion(LocalRegion.java:4558)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getRegion(GemFireCacheImpl.java:3322)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getRegion(GemFireCacheImpl.java:3153)
> at
> org.apache.geode.distributed.internal.InternalConfigurationPersistenceService.getConfigurationRegion(InternalConfigurationPersistenceService.java:792)
> at
> org.apache.geode.distributed.internal.InternalConfigurationPersistenceService.destroySharedConfiguration(InternalConfigurationPersistenceService.java:639)
> at
> org.apache.geode.cache30.ReconnectWithClusterConfigurationDUnitTest.lambda$teardown$bb17a952$1(ReconnectWithClusterConfigurationDUnitTest.java:112)
> at
> org.apache.geode.cache30.ReconnectWithClusterConfigurationDUnitTest$$Lambda$339/1176989958.run(Unknown
> Source)
> 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.TC
[jira] [Updated] (GEODE-8859) Redis data structures may not accurately reflect their size in Geode stats
[
https://issues.apache.org/jira/browse/GEODE-8859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-8859:
Labels: pull-request-available (was: pull-request-available
release-blocker)
> Redis data structures may not accurately reflect their size in Geode stats
> --
>
> Key: GEODE-8859
> URL: https://issues.apache.org/jira/browse/GEODE-8859
> Project: Geode
> Issue Type: Bug
> Components: redis, statistics
>Affects Versions: 1.14.0
>Reporter: Jens Deppe
>Assignee: Hale Bales
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> Here is a comment from Darrel regarding this issue. For some background, the
> Redis structures implement {{Delta}}.
>
> {quote}I was playing around with RedisInsight and was able to get most the
> the overview dashboard and the data browser working with geode redis. But I
> found a problem with how we are using geode that causes the geode stats that
> track how much data is stored in a partitioned region to be wrong and the
> bucket sizes used for rebalancing are also wrong. Basically when we do create
> ops on the region the stats track it okay. But when we do updates then geode
> always thinks that nothing (size wise) changed. So for example I created a
> string by doing a redis “set” command. I saw the size of the string accounted
> for in dataStoreBytesInUse. But then I kept doing redis “append” commands on
> that key and the dataStoreBytesInUse did not change at all. I think the
> problem is in how we are updating the data structure in place instead of
> getting a copy, modifying it, and then putting the copy into the region.
> Avoiding this copy gives us MUCH better performance but it messes up geode
> when it is trying to calculate the memory increase or decrease. It is
> possible that this is only an issue on the primary and that the secondary
> sizing may be correct. If so that could lead to other problems because for a
> given bucket our primary size would be different than the secondary. The
> bucket sizes are used when you do a rebalance but basically we can have a
> bunch of memory that is “untracked” so we might see the JVM heaps unbalanced
> but geode will think the buckets are balanced. I’m not sure what we should do
> about this.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-9146) idle expiration should ignore destroyed or invalid entries when computing last access time
[ https://issues.apache.org/jira/browse/GEODE-9146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-9146. - Fix Version/s: 1.15.0 Resolution: Fixed > idle expiration should ignore destroyed or invalid entries when computing > last access time > -- > > Key: GEODE-9146 > URL: https://issues.apache.org/jira/browse/GEODE-9146 > Project: Geode > Issue Type: Bug > Components: expiration >Affects Versions: 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0, 1.9.1, 1.9.2, > 1.10.0, 1.11.0, 1.12.0, 1.12.1, 1.13.0, 1.13.1, 1.13.2 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > When expiration is trying to determine if an entry has idle expired, it sends > a message to the other members to determine the last time the entry was > accessed. When that message, LatestLastAccessTimeMessage, checks for the > entry it should ignore a destroyed entry if the expiration action is destroy, > and it should ignore invalid entries if the expiration action is invalidate. > But currently it does not ignore such entries and since invalidate/destroy > also set the last accessed time, this can extend the expiration time on one > member that has already performed the expiration on another member. Normally > distributed expiration actions are done so this is not a problem but for > local invalidates or destroys this can cause the entry to live longer than it > should on some members. > In particular this issue has been seen on partitioned regions that are > configured with expiration destroy and eviction destroy. In that case the > expire destroy becomes a local destroy even when a distributed destroy was > requested. > This issue has existed since geode 1.4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9146) idle expiration should ignore destroyed or invalid entries when computing last access time
[ https://issues.apache.org/jira/browse/GEODE-9146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17356034#comment-17356034 ] ASF subversion and git services commented on GEODE-9146: Commit e4e10ace74a8a74868690d0c78f97814380a566d in geode's branch refs/heads/develop from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e4e10ac ] GEODE-9146: have idle expiration ignore timestamp on removed remote entries LatestLastAccessTimeMessage now ignores the last access time of both invalid and removed entries. > idle expiration should ignore destroyed or invalid entries when computing > last access time > -- > > Key: GEODE-9146 > URL: https://issues.apache.org/jira/browse/GEODE-9146 > Project: Geode > Issue Type: Bug > Components: expiration >Affects Versions: 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0, 1.9.1, 1.9.2, > 1.10.0, 1.11.0, 1.12.0, 1.12.1, 1.13.0, 1.13.1, 1.13.2 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > When expiration is trying to determine if an entry has idle expired, it sends > a message to the other members to determine the last time the entry was > accessed. When that message, LatestLastAccessTimeMessage, checks for the > entry it should ignore a destroyed entry if the expiration action is destroy, > and it should ignore invalid entries if the expiration action is invalidate. > But currently it does not ignore such entries and since invalidate/destroy > also set the last accessed time, this can extend the expiration time on one > member that has already performed the expiration on another member. Normally > distributed expiration actions are done so this is not a problem but for > local invalidates or destroys this can cause the entry to live longer than it > should on some members. > In particular this issue has been seen on partitioned regions that are > configured with expiration destroy and eviction destroy. In that case the > expire destroy becomes a local destroy even when a distributed destroy was > requested. > This issue has existed since geode 1.4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9277) Constrain Redis FLUSHALL command to local member data only
[
https://issues.apache.org/jira/browse/GEODE-9277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17356140#comment-17356140
]
ASF subversion and git services commented on GEODE-9277:
Commit 8161df86df30d0d4f710b9d0dd4fba8abd51b0aa in geode's branch
refs/heads/develop from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=8161df8 ]
GEODE-9277: Redis FLUSHALL should only remove local keys (#6481)
- This changes the `FLUSHALL` command from a distributed command to a command
which only removes keys on the node to which the client is connected. This is
consistent with redis cluster.
- In DUnit tests, now use `RedisClusterStartupRule.flushAll()` to remove all
keys in the cluster.
- This commit also disables 4 session-related tests due to issues with retrying
session commands.
> Constrain Redis FLUSHALL command to local member data only
> --
>
> Key: GEODE-9277
> URL: https://issues.apache.org/jira/browse/GEODE-9277
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> Currently our {{FLUSHALL}} command will iterate and delete all keys in the
> whole region. While this is nice and convenient for now, it is not how native
> redis does it and will need to be switched once the function execution layer
> is removed.
> It would be helpful to do this work separately.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
