[jira] [Updated] (GEODE-9870) JedisMovedDataException exception in testReconnectionWithAuthAndServerRestarts
[
https://issues.apache.org/jira/browse/GEODE-9870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9870:
--
Labels: pull-request-available (was: )
> JedisMovedDataException exception in testReconnectionWithAuthAndServerRestarts
> --
>
> Key: GEODE-9870
> URL: https://issues.apache.org/jira/browse/GEODE-9870
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Priority: Major
> Labels: pull-request-available
>
> CI failure here
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/315|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/315]:
>
> {code:java}
> AuthWhileServersRestartDUnitTest > testReconnectionWithAuthAndServerRestarts
> FAILED
> redis.clients.jedis.exceptions.JedisMovedDataException: MOVED 12539
> 127.0.0.1:26259
> at redis.clients.jedis.Protocol.processError(Protocol.java:119)
> at redis.clients.jedis.Protocol.process(Protocol.java:169)
> at redis.clients.jedis.Protocol.read(Protocol.java:223)
> at
> redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:352)
> at
> redis.clients.jedis.Connection.getStatusCodeReply(Connection.java:270)
> at redis.clients.jedis.BinaryJedis.flushAll(BinaryJedis.java:826)
> at
> org.apache.geode.test.dunit.rules.RedisClusterStartupRule.flushAll(RedisClusterStartupRule.java:147)
> at
> org.apache.geode.test.dunit.rules.RedisClusterStartupRule.flushAll(RedisClusterStartupRule.java:131)
> at
> org.apache.geode.redis.internal.executor.auth.AuthWhileServersRestartDUnitTest.after(AuthWhileServersRestartDUnitTest.java:88){code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9871) CI failure: InfoStatsIntegrationTest > networkKiloBytesReadOverLastSecond_shouldBeCloseToBytesReadOverLastSecond
[
https://issues.apache.org/jira/browse/GEODE-9871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9871:
--
Labels: pull-request-available (was: )
> CI failure: InfoStatsIntegrationTest >
> networkKiloBytesReadOverLastSecond_shouldBeCloseToBytesReadOverLastSecond
>
>
> Key: GEODE-9871
> URL: https://issues.apache.org/jira/browse/GEODE-9871
> Project: Geode
> Issue Type: Bug
> Components: redis, statistics
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Priority: Major
> Labels: pull-request-available
>
> link:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/38]
> stack trace:
> {code:java}
> InfoStatsIntegrationTest >
> networkKiloBytesReadOverLastSecond_shouldBeCloseToBytesReadOverLastSecond
> FAILED
> org.opentest4j.AssertionFailedError:
> expected: 0.0
> but was: 0.01
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.redis.internal.commands.executor.server.AbstractRedisInfoStatsIntegrationTest.networkKiloBytesReadOverLastSecond_shouldBeCloseToBytesReadOverLastSecond(AbstractRedisInfoStatsIntegrationTest.java:228)
> 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:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> 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.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:43)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
>
[jira] [Updated] (GEODE-9873) Add AuthenticationExpiredException message to Radish error response
[
https://issues.apache.org/jira/browse/GEODE-9873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9873:
--
Labels: pull-request-available (was: )
> Add AuthenticationExpiredException message to Radish error response
> ---
>
> Key: GEODE-9873
> URL: https://issues.apache.org/jira/browse/GEODE-9873
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> When an {{AuthenticationExpiredException}} is detected we should return a
> Redis error containing the exception message. Since there is nothing similar
> in Redis we feel it's OK to deviate and do something more specific to Geode.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9814) Add an example of geode-for-redis to the geode examples project
[ https://issues.apache.org/jira/browse/GEODE-9814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454224#comment-17454224 ] ASF GitHub Bot commented on GEODE-9814: --- DonalEvans commented on a change in pull request #110: URL: https://github.com/apache/geode-examples/pull/110#discussion_r763353956 ## File path: geodeForRedis/README.md ## @@ -0,0 +1,86 @@ + + +# Geode for Redis Example using Jedis Client + +This example demonstrates simple operations on a Geode for Redis cluster using the Jedis Client. + +In this example, two servers are started with geode-for-redis enabled, some data is added to the cluster. + +This example assumes that Java and Geode are installed. + +## Set up the cluster +1. Set directory ```geode-examples/geodeForRedis``` to be the +current working directory. Review comment: Since this file is in markdown format, a single newline in the source doesn't result in a visible newline in the file when viewed online or with an appropriate markdown file reader, but regardless, this one doesn't need to be there as the line isn't too long to easily view in an editor without it. I'll remove it. -- 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 > Add an example of geode-for-redis to the geode examples project > --- > > Key: GEODE-9814 > URL: https://issues.apache.org/jira/browse/GEODE-9814 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Dan Smith >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > > Add an example to the geode-examples project/repo demonstrating how to turn > on and use geode-for-redis. > This is just a script. User must download native Redis to get command line > tool. > Cluster Mode must be used. > Start Server with gfsh. > Use JedisCluster client to: > * Perform Sets > * Perform Gets > Have a readme that speaks to using native Redis. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9814) Add an example of geode-for-redis to the geode examples project
[
https://issues.apache.org/jira/browse/GEODE-9814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454199#comment-17454199
]
ASF GitHub Bot commented on GEODE-9814:
---
ringles commented on a change in pull request #110:
URL: https://github.com/apache/geode-examples/pull/110#discussion_r763310985
##
File path:
geodeForRedis/src/main/java/org/apache/geode_examples/geodeForRedis/Example.java
##
@@ -0,0 +1,70 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+package org.apache.geode_examples.geodeForRedis;
+
+import java.text.DecimalFormat;
+import java.util.HashMap;
+import java.util.Map;
+import java.util.Random;
+
+import redis.clients.jedis.HostAndPort;
+import redis.clients.jedis.JedisCluster;
+
+public class Example {
+ public static final String SORTED_SET_KEY = "leaderboard";
+
+ public static void main(String[] args) {
+JedisCluster jedis = new JedisCluster(new HostAndPort("127.0.0.1", 6379));
+
+populateSortedSet(jedis);
+
+System.out.println("Initial leaderboard with key '" + SORTED_SET_KEY + "':
"
Review comment:
Since the "jedis.zrangeWithScores(SORTED_SET_KEY, 0, Integer.MAX_VALUE)"
is repeated, possibly make it a method, say:
private static void printSortedSet(JedisCluster jedis, String message) {
System.out.println(message + ": " +
jedis.zrangeWithScores(SORTED_SET_KEY, 0, Integer.MAX_VALUE));
}
Very minor benefits, though.
##
File path:
geodeForRedis/src/main/java/org/apache/geode_examples/geodeForRedis/Example.java
##
@@ -0,0 +1,70 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+package org.apache.geode_examples.geodeForRedis;
+
+import java.text.DecimalFormat;
+import java.util.HashMap;
+import java.util.Map;
+import java.util.Random;
+
+import redis.clients.jedis.HostAndPort;
+import redis.clients.jedis.JedisCluster;
+
+public class Example {
+ public static final String SORTED_SET_KEY = "leaderboard";
+
+ public static void main(String[] args) {
+JedisCluster jedis = new JedisCluster(new HostAndPort("127.0.0.1", 6379));
+
+populateSortedSet(jedis);
+
+System.out.println("Initial leaderboard with key '" + SORTED_SET_KEY + "':
"
++ jedis.zrangeWithScores(SORTED_SET_KEY, 0, Integer.MAX_VALUE));
+System.out.println("Updating scores...");
Review comment:
Purely cosmetic, but possibly move the "Updating scores", "Removing",
etc. closer to the lines that do so, and setting apart the "set dump" lines?
--
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
> Add an example of geode-for-redis to the geode examples project
> ---
>
> Key: GEODE-9814
> URL: https://issues.apache.org/jira/browse/GEODE-9814
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Dan Smith
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
>
> Add an example to the geode-examples project/repo demonstrating how to turn
> on and use
[jira] [Commented] (GEODE-9814) Add an example of geode-for-redis to the geode examples project
[
https://issues.apache.org/jira/browse/GEODE-9814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17453281#comment-17453281
]
ASF GitHub Bot commented on GEODE-9814:
---
rhoughton-pivot commented on a change in pull request #110:
URL: https://github.com/apache/geode-examples/pull/110#discussion_r762371563
##
File path: geodeForRedis/build.gradle
##
@@ -0,0 +1,20 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+dependencies {
+compile "redis.clients:jedis"
Review comment:
we prefer `implementation` over `compile`
--
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
> Add an example of geode-for-redis to the geode examples project
> ---
>
> Key: GEODE-9814
> URL: https://issues.apache.org/jira/browse/GEODE-9814
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Dan Smith
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
>
> Add an example to the geode-examples project/repo demonstrating how to turn
> on and use geode-for-redis.
> This is just a script. User must download native Redis to get command line
> tool.
> Cluster Mode must be used.
> Start Server with gfsh.
> Use JedisCluster client to:
> * Perform Sets
> * Perform Gets
> Have a readme that speaks to using native Redis.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9814) Add an example of geode-for-redis to the geode examples project
[ https://issues.apache.org/jira/browse/GEODE-9814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17453273#comment-17453273 ] ASF GitHub Bot commented on GEODE-9814: --- Kris-10-0 commented on a change in pull request #110: URL: https://github.com/apache/geode-examples/pull/110#discussion_r762367315 ## File path: geodeForRedis/README.md ## @@ -0,0 +1,86 @@ + + +# Geode for Redis Example using Jedis Client + +This example demonstrates simple operations on a Geode for Redis cluster using the Jedis Client. + +In this example, two servers are started with geode-for-redis enabled, some data is added to the cluster. + +This example assumes that Java and Geode are installed. + +## Set up the cluster +1. Set directory ```geode-examples/geodeForRedis``` to be the +current working directory. Review comment: Not sure, but is this supposed to be a new line? -- 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 > Add an example of geode-for-redis to the geode examples project > --- > > Key: GEODE-9814 > URL: https://issues.apache.org/jira/browse/GEODE-9814 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Dan Smith >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > > Add an example to the geode-examples project/repo demonstrating how to turn > on and use geode-for-redis. > This is just a script. User must download native Redis to get command line > tool. > Cluster Mode must be used. > Start Server with gfsh. > Use JedisCluster client to: > * Perform Sets > * Perform Gets > Have a readme that speaks to using native Redis. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9814) Add an example of geode-for-redis to the geode examples project
[ https://issues.apache.org/jira/browse/GEODE-9814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9814: -- Labels: pull-request-available (was: ) > Add an example of geode-for-redis to the geode examples project > --- > > Key: GEODE-9814 > URL: https://issues.apache.org/jira/browse/GEODE-9814 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Dan Smith >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > > Add an example to the geode-examples project/repo demonstrating how to turn > on and use geode-for-redis. > This is just a script. User must download native Redis to get command line > tool. > Cluster Mode must be used. > Start Server with gfsh. > Use JedisCluster client to: > * Perform Sets > * Perform Gets > Have a readme that speaks to using native Redis. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9814) Add an example of geode-for-redis to the geode examples project
[ https://issues.apache.org/jira/browse/GEODE-9814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17453271#comment-17453271 ] ASF GitHub Bot commented on GEODE-9814: --- DonalEvans opened a new pull request #110: URL: https://github.com/apache/geode-examples/pull/110 Authored-by: Donal Evans -- 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 > Add an example of geode-for-redis to the geode examples project > --- > > Key: GEODE-9814 > URL: https://issues.apache.org/jira/browse/GEODE-9814 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Dan Smith >Assignee: Donal Evans >Priority: Major > > Add an example to the geode-examples project/repo demonstrating how to turn > on and use geode-for-redis. > This is just a script. User must download native Redis to get command line > tool. > Cluster Mode must be used. > Start Server with gfsh. > Use JedisCluster client to: > * Perform Sets > * Perform Gets > Have a readme that speaks to using native Redis. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9578) bump spring-security to recommended version
[ https://issues.apache.org/jira/browse/GEODE-9578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9578: -- Labels: pull-request-available (was: ) > bump spring-security to recommended version > --- > > Key: GEODE-9578 > URL: https://issues.apache.org/jira/browse/GEODE-9578 > Project: Geode > Issue Type: Improvement > Components: pulse >Affects Versions: 1.12.4, 1.13.4, 1.14.0 >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.12.5, 1.13.5, 1.14.1 > > > 1.14 has spring-security 5.4.5, will bump to 5.4.8 > 1.13 has spring-security 5.3.9, will bump to 5.3.11 > 1.12 has spring-security 5.2.10, will bump to 5.2.12 > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9785) CI Failure: RedundancyLevelPart2DUnitTest.testRedundancySpecifiedEPFails FAILED
[
https://issues.apache.org/jira/browse/GEODE-9785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9785:
--
Labels: needsTriage pull-request-available (was: needsTriage)
> CI Failure: RedundancyLevelPart2DUnitTest.testRedundancySpecifiedEPFails
> FAILED
> ---
>
> Key: GEODE-9785
> URL: https://issues.apache.org/jira/browse/GEODE-9785
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Eric Shu
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> {noformat}
> org.junit.ComparisonFailure: expected:<[2]> but was:<[0]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart2DUnitTest.testRedundancySpecifiedEPFails(RedundancyLevelPart2DUnitTest.java:215)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
[jira] [Updated] (GEODE-9831) SISMEMBER Command Supported
[ https://issues.apache.org/jira/browse/GEODE-9831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9831: -- Labels: pull-request-available (was: ) > SISMEMBER Command Supported > --- > > Key: GEODE-9831 > URL: https://issues.apache.org/jira/browse/GEODE-9831 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Assignee: Kristen >Priority: Major > Labels: pull-request-available > > The SISMEMBER command has been implemented but lacks sufficient testing to > ensure that the implementation is robust and does not regress in the future. > > Write unit/integration tests that run against both Geode Redis and native > Redis, and dunit tests which test multiple concurrent clients accessing > different servers. > > +Acceptance Criteria+ > > Passing Unit/integration tests for both Geode and native Redis. The > RedisCommandType class and > README/redis_api_for_[geode.html.md.erb|http://geode.html.md.erb/] updated to > make command "supported". Stories in the backlog to fix the identified issues > (with JIRA tickets) and problem tests that are ignored should be fixed and > enabled. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9563) Close Radish connections when AuthenticationExpiredException is caught
[ https://issues.apache.org/jira/browse/GEODE-9563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9563: -- Labels: pull-request-available (was: ) > Close Radish connections when AuthenticationExpiredException is caught > -- > > Key: GEODE-9563 > URL: https://issues.apache.org/jira/browse/GEODE-9563 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Priority: Major > Labels: pull-request-available > > The Redis Server and clients do not directly support token refresh or > reauthentication. Write example code of how we can accomplish a forced > reauthentication using the existing Redis clients. > > _Acceptance Criteria_ > Example code has been written using the Jedis and Lettuce clients that > illustrate how to force these clients to reauthenticate. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9826) SCARD Command Supported
[ https://issues.apache.org/jira/browse/GEODE-9826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9826: -- Labels: pull-request-available (was: ) > SCARD Command Supported > --- > > Key: GEODE-9826 > URL: https://issues.apache.org/jira/browse/GEODE-9826 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Assignee: Kristen >Priority: Major > Labels: pull-request-available > > The SCARD command has been implemented but lacks sufficient testing to ensure > that the implementation is robust and does not regress in the future. > > Write unit/integration tests that run against both Geode Redis and native > Redis, and dunit tests which test multiple concurrent clients accessing > different servers. > > +Acceptance Criteria+ > > Passing Unit/integration tests for both Geode and native Redis. The > RedisCommandType class and > README/redis_api_for_[geode.html.md.erb|http://geode.html.md.erb/] updated to > make command "supported". Stories in the backlog to fix the identified issues > (with JIRA tickets) and problem tests that are ignored should be fixed and > enabled. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9324) Remove ACE_Task references
[
https://issues.apache.org/jira/browse/GEODE-9324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17452470#comment-17452470
]
ASF GitHub Bot commented on GEODE-9324:
---
gaussianrecurrence commented on a change in pull request #812:
URL: https://github.com/apache/geode-native/pull/812#discussion_r761217916
##
File path: cppcache/integration-test/ThinClientSecurityHelper.hpp
##
@@ -198,18 +198,26 @@ class putThread : public ACE_Task_Base {
}
void start() {
-m_run = true;
-activate(THR_NEW_LWP | THR_JOINABLE, m_numthreads);
+for(auto i = 0; i < m_numthreads; ++i) {
+ threads_.emplace_back([this](){
+run();
+ });
+}
+ }
+
+ void wait() {
+for(auto& thread : threads_) {
+ if(thread.joinable()) {
+thread.join();
+ }
+}
}
void stop() {
-if (m_run) {
- m_run = false;
Review comment:
Thanks for pointing this out. Thing is there is no mechanism now to tell
the task to end, as there wasn't before. Because m_run was not used, except as
a mean to tell whether or not the thread was started, but that was not
necessary as the thread was run in a controlled environment and it was not
going to be stopped before it was started, and this last part is not different
now.
--
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
> Remove ACE_Task references
> --
>
> Key: GEODE-9324
> URL: https://issues.apache.org/jira/browse/GEODE-9324
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: obliterate-ace, pull-request-available
>
> *AS A* native client contributor
> *I WANT TO* remove all remaining references to ACE_Task
> *SO THAT* eventually we can get rid of ACE library
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9854) Orphaned .drf files causing memory leak
[
https://issues.apache.org/jira/browse/GEODE-9854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9854:
--
Labels: pull-request-available (was: )
> Orphaned .drf files causing memory leak
> ---
>
> Key: GEODE-9854
> URL: https://issues.apache.org/jira/browse/GEODE-9854
> Project: Geode
> Issue Type: Bug
>Reporter: Jakov Varenina
>Priority: Major
> Labels: pull-request-available
> Attachments: screenshot-1.png, screenshot-2.png, server1.log
>
>
> Issue:
> An OpLog files are compacted, but the .drf file is left because it contains
> deletes ofentries in previous .crfs. The .crf file is deleted, but the
> orphaned .drf is not until all
> previous .crf files (.crfs with smaller id) are deleted.
> The problem is that compacted Oplog object representing orphaned .drf file
> holds a structure in memory (Oplog.regionMap) that contains information that
> is not useful
> after the compaction and it takes certain amount of memory. Besides, there is
> a race condition in the code when creating .krf files that, depending on the
> execution order,
> could make the problem more severe (it could leave pendingKrfTags structure
> on the regionMap and this could take up a significant amount of memory). This
> pendingKrfTags HashMap is actually empty, but consumes memory because it was
> used previously and the size of the HashMap was not reduced after it is
> cleared.
> This race condition usually happens when new Oplog is rolled out and previous
> Oplog is immediately marked as eligible for compaction. Compaction and .krf
> creation start at
> the similar time and compactor cancels creation of .krf if it is executed
> first. The pendingKrfTags structure is usually cleared when .krf file is
> created, but sincecompaction canceled creation of .krf, the pendingKrfTags
> structure remain in memory until Oplog representing orphaned .drf file is
> deleted.
> Below it can be see that actually .krf is never created for the orphaned .drf
> Oplog object that has memory allocated in pendingKrfTags:
> {code:java}
> server1.log:1956:[info 2021/11/25 21:52:26.866 CET server1
> tid=0x34] Created oplog#129
> drf for disk store store1.
> server1.log:1958:[info 2021/11/25 21:52:26.867 CET server1
> tid=0x34] Created oplog#129
> crf for disk store store1.
> server1.log:1974:[info 2021/11/25 21:52:39.490 CET server1 store1 for oplog oplog#129> tid=0x5c] OplogCompactor for store1 compaction
> oplog id(s): oplog#129
> server1.log:1980:[info 2021/11/25 21:52:39.532 CET server1 store1 for oplog oplog#129> tid=0x5c] compaction did 3685 creates and updates
> in 41 ms
> server1.log:1982:[info 2021/11/25 21:52:39.532 CET server1 Task4> tid=0x5d] Deleted oplog#129 crf for disk store store1.
> {code}
> !screenshot-1.png|width=1123,height=268!
> Below you can see the log and heap dump of orphaned .drf Oplg that dont have
> pendingKrfTags allocated in memory. This is because pendingKrfTags is cleared
> when .krf is created as can be seen in below logs.
> {code:java}
> server1.log:1976:[info 2021/11/25 21:52:39.491 CET server1
> tid=0x34] Created oplog#130
> drf for disk store store1.
> server1.log:1978:[info 2021/11/25 21:52:39.493 CET server1
> tid=0x34] Created oplog#130
> crf for disk store store1.
> server1.log:1998:[info 2021/11/25 21:52:41.131 CET server1 OplogCompactor> tid=0x5c] Created oplog#130 krf for disk store store1.
> server1.log:2000:[info 2021/11/25 21:52:41.893 CET server1 store1 for oplog oplog#130> tid=0x5c|#130> tid=0x5c] OplogCompactor for
> store1 compaction oplog id(s): oplog#130
> server1.log:2002:[info 2021/11/25 21:52:41.958 CET server1 store1 for oplog oplog#130> tid=0x5c|#130> tid=0x5c] compaction did 9918
> creates and updates in 64 ms
> server1.log:2004:[info 2021/11/25 21:52:41.958 CET server1 Task4> tid=0x5d] Deleted oplog#130 crf for disk store store1.
> server1.log:2006:[info 2021/11/25 21:52:41.958 CET server1 Task4> tid=0x5d] Deleted oplog#130 krf for disk store store1.
> {code}
> !screenshot-2.png|width=1123,height=268!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9867) NPE When a connection is terminated after the client already sent in the operation
[ https://issues.apache.org/jira/browse/GEODE-9867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9867: -- Labels: pull-request-available (was: ) > NPE When a connection is terminated after the client already sent in the > operation > -- > > Key: GEODE-9867 > URL: https://issues.apache.org/jira/browse/GEODE-9867 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: pull-request-available > > The sequence of action is: > # the client sent in the operation to the server > # the message dispatcher to the client encountered some error and unregister > this client and terminates the connection > # the other thread continues to use the connection to process the command > and we get the NPE: > > java.lang.NullPointerException > at > org.apache.geode.internal.cache.tier.sockets.ServerConnection.bindSubject(ServerConnection.java:907) > at > org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:867) > at > org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:1055) > at > org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1326) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:690) > at > org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) > at java.lang.Thread.run(Thread.java:748) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9866) CI Failure : MemoryStatsIntegrationTest > usedMemory_shouldIncrease_givenAdditionalValuesAdded FAILED
[
https://issues.apache.org/jira/browse/GEODE-9866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9866:
--
Labels: pull-request-available (was: )
> CI Failure : MemoryStatsIntegrationTest >
> usedMemory_shouldIncrease_givenAdditionalValuesAdded FAILED
> -
>
> Key: GEODE-9866
> URL: https://issues.apache.org/jira/browse/GEODE-9866
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Reporter: Nabarun Nag
>Priority: Major
> Labels: pull-request-available
>
> link :
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-integration-test-openjdk8/builds/31]
> Bug Report:
> {noformat}
> MemoryStatsIntegrationTest >
> usedMemory_shouldIncrease_givenAdditionalValuesAdded FAILED
> java.lang.AssertionError:
> Expecting actual:
> 61121264L
> to be greater than:
> 105070472L
> at
> org.apache.geode.redis.internal.commands.executor.server.AbstractRedisMemoryStatsIntegrationTest.usedMemory_shouldIncrease_givenAdditionalValuesAdded(AbstractRedisMemoryStatsIntegrationTest.java:80)
> 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:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> 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.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:43)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at
> java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:82)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:73)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
>
[jira] [Updated] (GEODE-9851) Use strongly typed enums rather than int for enumeration like values.
[ https://issues.apache.org/jira/browse/GEODE-9851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9851: -- Labels: pull-request-available (was: ) > Use strongly typed enums rather than int for enumeration like values. > - > > Key: GEODE-9851 > URL: https://issues.apache.org/jira/browse/GEODE-9851 > Project: Geode > Issue Type: Improvement >Reporter: Jacob Barrett >Priority: Major > Labels: pull-request-available > > Internally register interest has both an interest policy and data storage > policy that it passes around as `int`. Since these values are finite and have > well defined values it makes sense to pass them as proper Java enums. > Strongly typing them provides compile time checks on acceptable values and > makes the code more readable. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9863) Fix redis benchmarks broken by grgit dependencies
[ https://issues.apache.org/jira/browse/GEODE-9863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9863: -- Labels: pull-request-available (was: ) > Fix redis benchmarks broken by grgit dependencies > - > > Key: GEODE-9863 > URL: https://issues.apache.org/jira/browse/GEODE-9863 > Project: Geode > Issue Type: Test > Components: benchmarks, build, redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > > Related to GEODE-9862, we need to apply the same fix to redis benchmarks. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9865) ConnectionManagerImpl forceCreateConnection to a specific server increments the count regardless whether the connection is successful
[
https://issues.apache.org/jira/browse/GEODE-9865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9865:
--
Labels: pull-request-available (was: )
> ConnectionManagerImpl forceCreateConnection to a specific server increments
> the count regardless whether the connection is successful
> -
>
> Key: GEODE-9865
> URL: https://issues.apache.org/jira/browse/GEODE-9865
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.14.0
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: pull-request-available
>
> *ConnectionManagerImpl forceCreateConnection* does:
> {noformat}
> private PooledConnection forceCreateConnection(ServerLocation serverLocation)
> throws ServerRefusedConnectionException, ServerOperationException {
> connectionAccounting.create();
> try {
> return createPooledConnection(serverLocation);
> } catch (GemFireSecurityException e) {
> throw new ServerOperationException(e);
> }
> }{noformat}
> The call to *connectionAccounting.create()* increments the count. If
> *createPooledConnection* is unsuccessful, the count is not decremented. This
> causes the client to think there are more connections than there actually are.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9862) build broken by grgit dependencies
[ https://issues.apache.org/jira/browse/GEODE-9862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9862: -- Labels: pull-request-available (was: ) > build broken by grgit dependencies > -- > > Key: GEODE-9862 > URL: https://issues.apache.org/jira/browse/GEODE-9862 > Project: Geode > Issue Type: Bug > Components: build, ci >Affects Versions: 1.15.0 >Reporter: Robert Houghton >Priority: Major > Labels: pull-request-available > > CI build started failing, and many local builds once gradle caches were > updated. Logs > [here|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0696/test-results/build/1638221535/]. > > We need to pin `org.eclipse.jgit` to fix for now. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9827) SDIFF Command Supported
[ https://issues.apache.org/jira/browse/GEODE-9827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9827: -- Labels: pull-request-available (was: ) > SDIFF Command Supported > --- > > Key: GEODE-9827 > URL: https://issues.apache.org/jira/browse/GEODE-9827 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Assignee: Kristen >Priority: Major > Labels: pull-request-available > > The SDIFF command has been implemented but lacks sufficient testing to ensure > that the implementation is robust and does not regress in the future. > > Write unit/integration tests that run against both Geode Redis and native > Redis, and dunit tests which test multiple concurrent clients accessing > different servers. > > +Acceptance Criteria+ > > Passing Unit/integration tests for both Geode and native Redis. The > RedisCommandType class and > README/redis_api_for_[geode.html.md.erb|http://geode.html.md.erb/] updated to > make command "supported". Stories in the backlog to fix the identified issues > (with JIRA tickets) and problem tests that are ignored should be fixed and > enabled. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9859) Mass-Test-Run: WanCopyRegionCommandDUnitTest.testRegionDestroyedDuringExecution(false, false) [0] FAILED
[
https://issues.apache.org/jira/browse/GEODE-9859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9859:
--
Labels: pull-request-available (was: )
> Mass-Test-Run:
> WanCopyRegionCommandDUnitTest.testRegionDestroyedDuringExecution(false,
> false) [0] FAILED
>
>
> Key: GEODE-9859
> URL: https://issues.apache.org/jira/browse/GEODE-9859
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Assignee: Alberto Gomez
>Priority: Major
> Labels: pull-request-available
>
> Looks like this might be failing from the original PR. I have linked to
> GEODE-9369 as the most likely origination.
>
> {noformat}
> WanCopyRegionCommandDUnitTest > testRegionDestroyedDuringExecution(false,
> false) [0] FAILED
> java.lang.AssertionError:
> Expecting elements:
> ["Execution failed. Error:
> org.apache.geode.cache.EntryDestroyedException: 937"]
> to have exactly 1 times execution error
> at
> org.apache.geode.cache.wan.internal.cli.commands.WanCopyRegionCommandDUnitTest.testRegionDestroyedDuringExecution(WanCopyRegionCommandDUnitTest.java:450)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9855) Radish authentication during HA
[ https://issues.apache.org/jira/browse/GEODE-9855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9855: -- Labels: pull-request-available (was: ) > Radish authentication during HA > --- > > Key: GEODE-9855 > URL: https://issues.apache.org/jira/browse/GEODE-9855 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Priority: Major > Labels: pull-request-available > > A test should be created where clients continually authenticate to a cluster > while members are being killed and restarted. Any problem behavior identified > should be turned into tickets for addressing the issues. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9853) Optimize number of ParallelQueueRemovalMessage sent for dropped events in large clusters
[ https://issues.apache.org/jira/browse/GEODE-9853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9853: -- Labels: pull-request-available (was: ) > Optimize number of ParallelQueueRemovalMessage sent for dropped events in > large clusters > > > Key: GEODE-9853 > URL: https://issues.apache.org/jira/browse/GEODE-9853 > Project: Geode > Issue Type: Improvement > Components: wan >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > > In multi site cluster (16 or more servers), in case we stop gw sender, and > continue to put new entries in region, it is observed large number of > ParallelQueueRemovalMessage sent. > It seems that this can be optimized, since most of sent messages are ignored > by most of other servers. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9788) Develop PubSub Benchmark Tests
[ https://issues.apache.org/jira/browse/GEODE-9788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9788: -- Labels: pull-request-available (was: ) > Develop PubSub Benchmark Tests > -- > > Key: GEODE-9788 > URL: https://issues.apache.org/jira/browse/GEODE-9788 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Wayne >Assignee: Eric Zoerner >Priority: Major > Labels: pull-request-available > > Develop a suite of benchmarking tests for the pubsub API that benchmark the > comparison between native Redis and the compatibility with Redis layer. > +Acceptance Criteria+ > A benchmark should be developed that provides acceptable coverage (TBD) of > the pubsub that allows us to monitor the performance over time and compared > to native Redis. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9788) Develop PubSub Benchmark Tests
[ https://issues.apache.org/jira/browse/GEODE-9788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17448901#comment-17448901 ] ASF GitHub Bot commented on GEODE-9788: --- ezoerner opened a new pull request #161: URL: https://github.com/apache/geode-benchmarks/pull/161 Still under test, opening a draft PR for visibility -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Develop PubSub Benchmark Tests > -- > > Key: GEODE-9788 > URL: https://issues.apache.org/jira/browse/GEODE-9788 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Wayne >Assignee: Eric Zoerner >Priority: Major > > Develop a suite of benchmarking tests for the pubsub API that benchmark the > comparison between native Redis and the compatibility with Redis layer. > +Acceptance Criteria+ > A benchmark should be developed that provides acceptable coverage (TBD) of > the pubsub that allows us to monitor the performance over time and compared > to native Redis. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9324) Remove ACE_Task references
[
https://issues.apache.org/jira/browse/GEODE-9324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17448884#comment-17448884
]
ASF GitHub Bot commented on GEODE-9324:
---
pivotal-jbarrett commented on a change in pull request #812:
URL: https://github.com/apache/geode-native/pull/812#discussion_r756470894
##
File path: cppcache/integration-test/ThinClientSecurityHelper.hpp
##
@@ -198,18 +198,26 @@ class putThread : public ACE_Task_Base {
}
void start() {
-m_run = true;
-activate(THR_NEW_LWP | THR_JOINABLE, m_numthreads);
+for(auto i = 0; i < m_numthreads; ++i) {
+ threads_.emplace_back([this](){
+run();
+ });
+}
+ }
+
+ void wait() {
+for(auto& thread : threads_) {
+ if(thread.joinable()) {
+thread.join();
+ }
+}
}
void stop() {
-if (m_run) {
- m_run = false;
Review comment:
With the removal of `m_run = false` what is left to tell the tasks to
end?
##
File path: cppcache/integration-test/ThinClientTransactionsXA.hpp
##
@@ -355,72 +356,73 @@ const bool NO_ACK = false;
#define THREADERRORCHECK(x, y) \
do { \
if (!(x)) {\
- m_isFailed = true; \
- m_error = y; \
- return -1; \
+ failed_ = true; \
+ error_ = y; \
+ return; \
} \
} while (0)
-class SuspendTransactionThread : public ACE_Task_Base {
- private:
- TransactionId* m_suspendedTransaction;
- bool m_sleep;
- ACE_Auto_Event* m_txEvent;
-
+class SuspendTransactionThread {
public:
- SuspendTransactionThread(bool sleep, ACE_Auto_Event* txEvent)
- : m_suspendedTransaction(nullptr), m_sleep(sleep), m_txEvent(txEvent) {}
+ SuspendTransactionThread(bool sleep, binary_semaphore& event)
+ : sleep_{sleep}, tx_{nullptr}, sem_(event) {}
- int svc(void) override {
+ void run() {
LOG(" In SuspendTransactionThread");
-auto txManager = getHelper()->getCache()->getCacheTransactionManager();
+auto txm = getHelper()->getCache()->getCacheTransactionManager();
Review comment:
When changing variable names please tend towards full names over
abbreviations.
--
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
> Remove ACE_Task references
> --
>
> Key: GEODE-9324
> URL: https://issues.apache.org/jira/browse/GEODE-9324
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: obliterate-ace, pull-request-available
>
> *AS A* native client contributor
> *I WANT TO* remove all remaining references to ACE_Task
> *SO THAT* eventually we can get rid of ACE library
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9808) Client ops fail with NoLocatorsAvailableException when all servers leave the DS
[
https://issues.apache.org/jira/browse/GEODE-9808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9808:
--
Labels: needsTriage pull-request-available (was: needsTriage)
> Client ops fail with NoLocatorsAvailableException when all servers leave the
> DS
>
>
> Key: GEODE-9808
> URL: https://issues.apache.org/jira/browse/GEODE-9808
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Assignee: Donal Evans
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> When there are no cache servers (only locators) in a cluster, client
> operations will fail with a misleading exception:
> {noformat}
> org.apache.geode.cache.client.NoAvailableLocatorsException: Unable to connect
> to any locators in the list
> [gemfire-cluster-locator-0.gemfire-cluster-locator.namespace-1850250019.svc.cluster.local:10334,
>
> gemfire-cluster-locator-1.gemfire-cluster-locator.namespace-1850250019.svc.cluster.local:10334,
>
> gemfire-cluster-locator-2.gemfire-cluster-locator.namespace-1850250019.svc.cluster.local:10334]
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:174)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:211)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.forceCreateConnection(ConnectionManagerImpl.java:227)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.exchangeConnection(ConnectionManagerImpl.java:365)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:161)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:120)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:805)
> at org.apache.geode.cache.client.internal.PutOp.execute(PutOp.java:91)
> {noformat}
> Even the client is able to connect to a locator, we encounter a
> NoAvailableLocatorsException exception with the message "Unable to connect to
> any locators in the list".
> Investigating the product code we see:
> # If there are no cache servers in the cluster, ServerLocator.pickServer()
> will definitely construct a ClientConnectionResponse(null) which causes that
> object’s hasResult() to respond with false in the loop termination in
> AutoConnectionSourceImpl.queryLocators()
> # Not only is the exception wording misleading in
> AutoConnectionSourceImpl.findServer()—it’s also misleading in at least two
> other calling locations in AutoConnectionSourceImpl: findReplacementServer()
> and findServersForQueue().
> # In each of those cases the calling method translates a null response from
> queryLocators() into a throw of a NoAvailableLocatorsException
> # an appropriate exception, NoAvailableServersException, already exists, for
> the case where we were able to contact a locator but the locator was not able
> to find any cache servers
> # According to my Git spelunking queryLocators() has been obfuscating the
> true cause of the failure since at least 2015
> Without analyzing ServerLocator.pickServer()
> (LocatorLoadSnapshot.getServerForConnection()) to discern why two locators
> might disagree on how many cache servers are in the cluster, it seems to me
> that we should modify AutoConnectionSourceImpl.queryLocators() so that:
> * if it gets a ServerLocationResponse with hasResult() true, it immediately
> returns that as it does now
> * otherwise it keeps trying and it keeps track of the last (non-null)
> ServerLocationResponse it has received
> * it returns the last non-null ServerLocationResponse it received (otherwise
> it returns null)
> With that in hand, we can change the three call locations in
> AutoConnectionSourceImpl: findServer(), findReplacementServer(), and
> findServersForQueue() to each throw NoAvailableLocatorsException if no
> locator responded, or NoAvailableServersException if a locator responded with
> a ClientConnectionResponse for which hasResult() returns null.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9782) improve package organization of geode-for-redis
[ https://issues.apache.org/jira/browse/GEODE-9782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9782: -- Labels: pull-request-available (was: ) > improve package organization of geode-for-redis > --- > > Key: GEODE-9782 > URL: https://issues.apache.org/jira/browse/GEODE-9782 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > > It would be nice to improve how the internals of geode-for-redis are packaged > before it is released in 1.15. Try to do this when others are not active > working on these classes since it could cause a bunch of conflicts. Be aware > that a few of the internals may have dependencies outside of geode and those > will also need to be updated. Make sure and move corresponding tests to be in > the same package. Here are some ideas: > # move the collections package into the data package > # move the delta package into the data package > # move all the Stripe classes in the services package into a new > services.locking package > # move RegionProvider into services > # move PassiveExpirationManager into services > # move RedisSanctionedSerializablesService into the services > # move SlotAdvisor into the cluster package > # move the cluster package into the services package (or leave it as is, > also consider moving pubsub and statics into services. The "services" package > is so generic lots of things could be put into it or we could get rid of it). > # create a new package named "commands" > # move Command, RedisCommandSupportLevel, and RedisCommandType into commands > # move parameters into commands > # move executor into commands -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9850) flaky test: testGetOldestTombstoneTimeForReplicateTombstoneSweeper
[
https://issues.apache.org/jira/browse/GEODE-9850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9850:
--
Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI)
> flaky test: testGetOldestTombstoneTimeForReplicateTombstoneSweeper
> --
>
> Key: GEODE-9850
> URL: https://issues.apache.org/jira/browse/GEODE-9850
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.5
>Reporter: Bill Burcham
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> First saw this failure in PR pipeline on support/1.13 here:
> [https://concourse.apachegeode-ci.info/builds/3912569]
> {code:java}
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest >
> testGetOldestTombstoneTimeForReplicateTombstoneSweeper FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest$$Lambda$42/2046302475.run
> in VM 0 running on Host 9a305b2d7db7 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.versions.TombstoneDUnitTest.testGetOldestTombstoneTimeForReplicateTombstoneSweeper(TombstoneDUnitTest.java:228)
> Caused by:
> java.lang.AssertionError:
> Expecting:
> <-1637701703343L>
> to be greater than:
> <0L>
> at
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest.lambda$testGetOldestTombstoneTimeForReplicateTombstoneSweeper$bb17a952$3(TombstoneDUnitTest.java:237)
> {code}
> I believe the fix is to wrap this assertion in an awaitility call.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9838) Log key info for deserilation issue while index update
[
https://issues.apache.org/jira/browse/GEODE-9838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9838:
--
Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI)
> Log key info for deserilation issue while index update
> ---
>
> Key: GEODE-9838
> URL: https://issues.apache.org/jira/browse/GEODE-9838
> Project: Geode
> Issue Type: Improvement
> Components: querying
>Affects Versions: 1.15.0
>Reporter: Anilkumar Gingade
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> When there is issue in Index update (maintenance); the index is marked as
> invalid. And warning is logged:
> [warn 2021/11/11 07:39:28.215 CST pazrslsrv004 Processor 963> tid=0x124ecf] Updating the Index patientMemberIdentifier
> failed. The index is corrupted and marked as invalid.
> org.apache.geode.cache.query.internal.index.IMQException
> Adding "key" information in the log helps diagnosing the failure and adding
> or removing the entry in question.
> Code path IndexManager.java:
> void addIndexMapping(RegionEntry entry, IndexProtocol index) {
> try {
> index.addIndexMapping(entry);
> } catch (Exception exception) {
> index.markValid(false);
> setPRIndexAsInvalid((AbstractIndex) index);
> logger.warn(String.format(
> "Updating the Index %s failed. The index is corrupted and marked as
> invalid.",
> ((AbstractIndex) index).indexName), exception);
> }
> }
> void removeIndexMapping(RegionEntry entry, IndexProtocol index, int opCode) {
> try {
> index.removeIndexMapping(entry, opCode);
> } catch (Exception exception) {
> index.markValid(false);
> setPRIndexAsInvalid((AbstractIndex) index);
> logger.warn(String.format(
> "Updating the Index %s failed. The index is corrupted and marked as
> invalid.",
> ((AbstractIndex) index).indexName), exception);
> }
> }
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9841) Move internal packages to conform to new internal package structure
[ https://issues.apache.org/jira/browse/GEODE-9841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9841: -- Labels: pull-request-available (was: ) > Move internal packages to conform to new internal package structure > --- > > Key: GEODE-9841 > URL: https://issues.apache.org/jira/browse/GEODE-9841 > Project: Geode > Issue Type: Improvement >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > > Both ClassLoader and Deployment are in the `internal.classloader` and > `internal.deployment` package structure, which would make more sense (and > conform to newer thinking) to be `classloader.internal` and > `deployment.internal`. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[ https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17446735#comment-17446735 ] ASF GitHub Bot commented on GEODE-9804: --- mmartell merged pull request #894: URL: https://github.com/apache/geode-native/pull/894 -- 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 > Both registerAllKeys and registerRegex always fetch initial entries. > > > Key: GEODE-9804 > URL: https://issues.apache.org/jira/browse/GEODE-9804 > Project: Geode > Issue Type: Bug >Reporter: Jacob Barrett >Priority: Major > Labels: needsTriage, pull-request-available > > A inconsistency and bug in how the two regex interest methods configure the > initial interest policy results in the both registerAllKeys and registerRegex > fetching all initial entries despite the boolean parameter to get initial > entries. Furthermore the misconfiguration results in none of the entries > actually getting sent to the cache listener. The result is unnecessarily long > registration times, network traffic and load on the servers. On servers with > say millions of keys this can result in long GC pauses to unintentionally > iterate over all those keys. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9727) Redis Command COMMAND Should Throw Error With Invalid Arguments
[ https://issues.apache.org/jira/browse/GEODE-9727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9727: -- Labels: pull-request-available (was: ) > Redis Command COMMAND Should Throw Error With Invalid Arguments > --- > > Key: GEODE-9727 > URL: https://issues.apache.org/jira/browse/GEODE-9727 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Assignee: Kristen >Priority: Major > Labels: pull-request-available > > The Redis command COMMAND should throw an error when provided with an illegal > argument. > Native Redis behaves as follows: > COMMAND foo > (error) ERR Unknown subcommand or wrong number of arguments for 'foo'. Try > COMMAND HELP. > Our existing COMMANDimplementation does not provide an error messages for the > extra argument and just executes the COMMAND normally as if no additional > arguments were provided. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9638) CI failure: DeployedJarTest getDeployedFileName failed on Windows intermittently
[ https://issues.apache.org/jira/browse/GEODE-9638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9638: -- Labels: GeodeOperationAPI flaky needsTriage pull-request-available (was: GeodeOperationAPI flaky needsTriage) > CI failure: DeployedJarTest getDeployedFileName failed on Windows > intermittently > - > > Key: GEODE-9638 > URL: https://issues.apache.org/jira/browse/GEODE-9638 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI, flaky, needsTriage, > pull-request-available > > org.apache.geode.deployment.internal.DeployedJarTest > getDeployedFileName > FAILED > java.nio.file.DirectoryNotEmptyException: > C:\Users\geode\AppData\Local\Temp\javaCompiler2976436474406314797\classes > at > sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:266) > at > sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103) > at java.nio.file.Files.delete(Files.java:1126) > at org.apache.commons.io.FileUtils.delete(FileUtils.java:1175) > at > org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1194) > at > org.apache.geode.test.compiler.JavaCompiler.compile(JavaCompiler.java:91) > at > org.apache.geode.test.compiler.JarBuilder.buildJarFromClassNames(JarBuilder.java:83) > at > org.apache.geode.deployment.internal.DeployedJarTest.createJarFile(DeployedJarTest.java:82) > at > org.apache.geode.deployment.internal.DeployedJarTest.getDeployedFileName(DeployedJarTest.java:65) > see: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-unit-test-openjdk8/builds/206 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9825) Disparate socket-buffer-size Results in "IOException: Unknown header byte" and Hangs
[
https://issues.apache.org/jira/browse/GEODE-9825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9825:
--
Labels: pull-request-available (was: )
> Disparate socket-buffer-size Results in "IOException: Unknown header byte"
> and Hangs
>
>
> Key: GEODE-9825
> URL: https://issues.apache.org/jira/browse/GEODE-9825
> Project: Geode
> Issue Type: Bug
> Components: messaging
>Affects Versions: 1.12.4, 1.15.0
>Reporter: Bill Burcham
>Priority: Major
> Labels: pull-request-available
> Attachments: GEODE-9825-demo.patch
>
>
> GEODE-9141 introduced a bug that causes {{IOException: "Unknown header
> byte..."}} and hangs if members are configured with different
> {{socket-buffer-size}} settings.
> h2. Reproduction
> To reproduce this bug, modify {{P2PMessagingConcurrencyDUnitTest}} so that
> sender and locator and receiver use different configuration parameters. Set
> {{socket-buffer-size}} to 212992 for the sender and 32 * 1024 for the
> receiver. Oh and just skip the call to {{{}securityProperties(){}}}—we want
> to induce the "Unknown header byte" exception—we don't want the TLS framework
> throwing exceptions. See attached patch file GEODE-9825-demo.patch for an
> example.
> h2. Analysis
> In {{{}Connection.processInputBuffer(){}}}. When that method has read all the
> messages it can from the current input buffer, it then considers whether the
> buffer needs expansion. If it does then:
> {code:java}
> inputBuffer = inputSharing.expandReadBufferIfNeeded(allocSize); {code}
> Is executed and the method returns. The caller then expects to be able to
> _write_ bytes into {{{}inputBuffer{}}}.
> The problem, it seems, is that
> {{ByteBufferSharingInternalImpl.expandReadBufferIfNeeded()}} does not leave
> the the {{ByteBuffer}} in the proper state. It leaves the buffer ready to be
> _read_ not written.
> Before the changes for GEODE-9141 were introduced, the line of code
> referenced above used to be this snippet in
> {{Connection.compactOrResizeBuffer(int messageLength)}} (that method has
> since been removed):
> {code:java}
> // need a bigger buffer
> logger.info("Allocating larger network read buffer, new size is {} old
> size was {}.",
> allocSize, oldBufferSize);
> ByteBuffer oldBuffer = inputBuffer;
> inputBuffer = getBufferPool().acquireDirectReceiveBuffer(allocSize);
> if (oldBuffer != null) {
> int oldByteCount = oldBuffer.remaining();
> inputBuffer.put(oldBuffer);
> inputBuffer.position(oldByteCount);
> getBufferPool().releaseReceiveBuffer(oldBuffer);
> } {code}
> Notice how this method leaves {{inputBuffer}} ready to be _written_ to.
> But the code inside
> {{ByteBufferSharingInternalImpl.expandReadBufferIfNeeded()}} is doing
> something like:
> {code:java}
> newBuffer.clear();
> newBuffer.put(existing);
> newBuffer.flip();
> releaseBuffer(type, existing);
> return newBuffer; {code}
> The solution (shown in the attached patch file GEODE-9825-demo.patch) is to
> do add logic after the call to {{expandReadBufferIfNeeded(allocSize)}} to
> leave the buffer in a _writeable_ state:
> {code:java}
> inputBuffer = inputSharing.expandReadBufferIfNeeded(allocSize);
> // we're returning to the caller (done == true) so make buffer writeable
> inputBuffer.position(inputBuffer.limit());
> inputBuffer.limit(inputBuffer.capacity()); {code}
> h2. Resolution
> When this ticket is complete the bug will be fixed and
> {{P2PMessagingConcurrencyDUnitTest}} will be enhanced to test these
> combinations:
> [security, sender/locator socket-buffer-size, receiver socket-buffer-size]
> [TLS, (default), (default)] this is what the test currently does
> [no TLS, 64 * 1024, 32 * 1024] *new: this illustrates this bug*
> [no TLS, (default), (default)] *new*
> We might want to mix in conserve-sockets true/false in there too while we're
> at it (the test currently holds it at true).
> The attached patch file GEODE-9825-demo.patch shows a quick hack to
> {{P2PMessagingConcurrencyDUnitTest}} to illustrate the bug. The patch also
> includes a fix.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[
https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17446626#comment-17446626
]
ASF GitHub Bot commented on GEODE-9804:
---
mmartell commented on a change in pull request #894:
URL: https://github.com/apache/geode-native/pull/894#discussion_r753433793
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -575,4 +605,227 @@ TEST(RegisterKeysTest, RegisterAnyWithProxyRegion) {
cache.close();
}
+apache::geode::client::Cache createCache() {
+ return apache::geode::client::CacheFactory()
+ .set("log-level", "debug")
+ .set("log-file", "c:/temp/RegisterKeysTest.log")
+ .set("statistic-sampling-enabled", "false")
+ .create();
+}
+
+std::shared_ptr createPool(
+Cluster& cluster, apache::geode::client::Cache& cache) {
+ auto poolFactory = cache.getPoolManager().createFactory();
+ cluster.applyLocators(poolFactory);
+ poolFactory.setSubscriptionEnabled(true); // Per the customer.
+ return poolFactory.create("default");
+}
+
+std::shared_ptr setupRegion(
+apache::geode::client::Cache& cache,
+const std::shared_ptr& pool) {
+ auto region =
+ cache
+ .createRegionFactory(apache::geode::client::RegionShortcut::
+ CACHING_PROXY) // Per the customer.
+ .setPoolName(pool->getName())
+ .create("region");
+
+ return region;
+}
+
+TEST(RegisterKeysTest, DontReceiveValues) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+
+ cluster.start();
+
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("PARTITION")
+ .execute();
+
+ auto cache1 = createCache();
+ auto pool1 = createPool(cluster, cache1);
+ auto region1 = setupRegion(cache1, pool1);
+ auto attrMutator = region1->getAttributesMutator();
+
+ boost::latch allKeysUpdatedLatch{kNumKeys};
+ boost::latch allKeysInvalidLatch{kNumKeys};
+ auto listener = std::make_shared(allKeysUpdatedLatch,
+allKeysInvalidLatch);
+
+ attrMutator->setCacheListener(listener);
+
+ auto cache2 = createCache();
+ auto pool2 = createPool(cluster, cache2);
+ auto region2 = setupRegion(cache2, pool2);
+
+ for (auto i = 0U; i < kNumKeys; i++) {
+region2->put(CacheableInt32::create(i), CacheableInt32::create(i));
+ }
+
+ region1->registerAllKeys(false, false, false);
+
+ for (auto i = 0U; i < kNumKeys; i++) {
+auto hasKey = region1->containsKey(CacheableInt32::create(i));
+EXPECT_FALSE(hasKey);
+ }
+
+ for (auto i = 0U; i < kNumKeys; i++) {
+auto value = region1->get(CacheableInt32::create(i));
+ }
+
+ allKeysInvalidLatch.reset(kNumKeys);
+ listener->reset();
+
+ for (auto i = 0U; i < kNumKeys; i++) {
+region2->put(CacheableInt32::create(i), CacheableInt32::create(i + 1000));
+ }
+
+ EXPECT_EQ(boost::cv_status::no_timeout,
+allKeysInvalidLatch.wait_for(boost::chrono::seconds(60)));
+
+ for (auto i = 0U; i < kNumKeys; i++) {
+auto hasKey = region1->containsKey(CacheableInt32::create(i));
+EXPECT_TRUE(hasKey);
+
+auto hasValue = region1->containsValueForKey(CacheableInt32::create(i));
+EXPECT_FALSE(hasValue);
+ }
+}
+
+TEST(RegisterKeysTest, ReceiveValuesLocalInvalidate) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+
+ cluster.start();
+
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("PARTITION")
+ .execute();
+
+ auto cache1 = createCache();
+ auto pool1 = createPool(cluster, cache1);
+ auto region1 = setupRegion(cache1, pool1);
+ auto attrMutator = region1->getAttributesMutator();
+
+ boost::latch allKeysUpdatedLatch{kNumKeys};
+ boost::latch allKeysInvalidLatch{kNumKeys};
+ auto listener = std::make_shared(allKeysUpdatedLatch,
Review comment:
Done
--
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
> Both registerAllKeys and registerRegex always fetch initial entries.
>
>
> Key: GEODE-9804
> URL: https://issues.apache.org/jira/browse/GEODE-9804
> Project: Geode
> Issue Type: Bug
>Reporter: Jacob Barrett
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> A inconsistency and bug in how the two regex interest methods configure the
> initial interest policy results in the both registerAllKeys and registerRegex
> fetching all initial entries despite the boolean parameter to get initial
> entries. Furthermore the misconfiguration results in
[jira] [Commented] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[
https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17446625#comment-17446625
]
ASF GitHub Bot commented on GEODE-9804:
---
mmartell commented on a change in pull request #894:
URL: https://github.com/apache/geode-native/pull/894#discussion_r753433661
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -575,4 +605,227 @@ TEST(RegisterKeysTest, RegisterAnyWithProxyRegion) {
cache.close();
}
+apache::geode::client::Cache createCache() {
+ return apache::geode::client::CacheFactory()
+ .set("log-level", "debug")
+ .set("log-file", "c:/temp/RegisterKeysTest.log")
+ .set("statistic-sampling-enabled", "false")
+ .create();
+}
+
+std::shared_ptr createPool(
+Cluster& cluster, apache::geode::client::Cache& cache) {
+ auto poolFactory = cache.getPoolManager().createFactory();
+ cluster.applyLocators(poolFactory);
+ poolFactory.setSubscriptionEnabled(true); // Per the customer.
+ return poolFactory.create("default");
+}
+
+std::shared_ptr setupRegion(
+apache::geode::client::Cache& cache,
+const std::shared_ptr& pool) {
+ auto region =
+ cache
+ .createRegionFactory(apache::geode::client::RegionShortcut::
+ CACHING_PROXY) // Per the customer.
+ .setPoolName(pool->getName())
+ .create("region");
+
+ return region;
+}
+
+TEST(RegisterKeysTest, DontReceiveValues) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+
+ cluster.start();
+
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("PARTITION")
+ .execute();
+
+ auto cache1 = createCache();
+ auto pool1 = createPool(cluster, cache1);
+ auto region1 = setupRegion(cache1, pool1);
+ auto attrMutator = region1->getAttributesMutator();
+
+ boost::latch allKeysUpdatedLatch{kNumKeys};
+ boost::latch allKeysInvalidLatch{kNumKeys};
+ auto listener = std::make_shared(allKeysUpdatedLatch,
Review comment:
Nice suggestion. Moved latches to CountdownListener.
--
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
> Both registerAllKeys and registerRegex always fetch initial entries.
>
>
> Key: GEODE-9804
> URL: https://issues.apache.org/jira/browse/GEODE-9804
> Project: Geode
> Issue Type: Bug
>Reporter: Jacob Barrett
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> A inconsistency and bug in how the two regex interest methods configure the
> initial interest policy results in the both registerAllKeys and registerRegex
> fetching all initial entries despite the boolean parameter to get initial
> entries. Furthermore the misconfiguration results in none of the entries
> actually getting sent to the cache listener. The result is unnecessarily long
> registration times, network traffic and load on the servers. On servers with
> say millions of keys this can result in long GC pauses to unintentionally
> iterate over all those keys.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[
https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17446608#comment-17446608
]
ASF GitHub Bot commented on GEODE-9804:
---
mmartell commented on a change in pull request #894:
URL: https://github.com/apache/geode-native/pull/894#discussion_r753407297
##
File path: cppcache/integration/benchmark/RegisterInterestBM.cpp
##
@@ -0,0 +1,156 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include
+#include
+#include
+
+#ifdef _MSC_VER
+#pragma warning(push)
+#pragma warning(disable : 4596)
+#endif
+#include
+#include
+#include
+#ifdef _MSC_VER
+#pragma warning(pop)
+#endif
+
+#include
+#include
+#include
+#include
+#include
+
+namespace {
+
+using apache::geode::client::Cache;
+using apache::geode::client::CacheableString;
+using apache::geode::client::HashMapOfCacheable;
+using apache::geode::client::Region;
+using apache::geode::client::RegionShortcut;
+
+class RegisterInterestBM : public benchmark::Fixture {
+ public:
+ RegisterInterestBM() {
+boost::log::core::get()->set_filter(boost::log::trivial::severity >=
+boost::log::trivial::debug);
Review comment:
Done
--
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
> Both registerAllKeys and registerRegex always fetch initial entries.
>
>
> Key: GEODE-9804
> URL: https://issues.apache.org/jira/browse/GEODE-9804
> Project: Geode
> Issue Type: Bug
>Reporter: Jacob Barrett
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> A inconsistency and bug in how the two regex interest methods configure the
> initial interest policy results in the both registerAllKeys and registerRegex
> fetching all initial entries despite the boolean parameter to get initial
> entries. Furthermore the misconfiguration results in none of the entries
> actually getting sent to the cache listener. The result is unnecessarily long
> registration times, network traffic and load on the servers. On servers with
> say millions of keys this can result in long GC pauses to unintentionally
> iterate over all those keys.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[
https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17446545#comment-17446545
]
ASF GitHub Bot commented on GEODE-9804:
---
pivotal-jbarrett commented on a change in pull request #894:
URL: https://github.com/apache/geode-native/pull/894#discussion_r753304896
##
File path: cppcache/integration/benchmark/RegisterInterestBM.cpp
##
@@ -0,0 +1,156 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include
+#include
+#include
+
+#ifdef _MSC_VER
Review comment:
If we have to make more changes to this PR, let's pull this out of the
couple of headers it is in now and make a common 'logging.hpp' in the
integration framework
##
File path: cppcache/integration/benchmark/RegisterInterestBM.cpp
##
@@ -0,0 +1,156 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include
+#include
+#include
+
+#ifdef _MSC_VER
+#pragma warning(push)
+#pragma warning(disable : 4596)
+#endif
+#include
+#include
+#include
+#ifdef _MSC_VER
+#pragma warning(pop)
+#endif
+
+#include
+#include
+#include
+#include
+#include
+
+namespace {
+
+using apache::geode::client::Cache;
+using apache::geode::client::CacheableString;
+using apache::geode::client::HashMapOfCacheable;
+using apache::geode::client::Region;
+using apache::geode::client::RegionShortcut;
+
+class RegisterInterestBM : public benchmark::Fixture {
+ public:
+ RegisterInterestBM() {
+boost::log::core::get()->set_filter(boost::log::trivial::severity >=
+boost::log::trivial::debug);
Review comment:
If the test is ready for prime time let's change the logging level to
warning.
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -575,4 +605,227 @@ TEST(RegisterKeysTest, RegisterAnyWithProxyRegion) {
cache.close();
}
+apache::geode::client::Cache createCache() {
+ return apache::geode::client::CacheFactory()
+ .set("log-level", "debug")
+ .set("log-file", "c:/temp/RegisterKeysTest.log")
+ .set("statistic-sampling-enabled", "false")
+ .create();
+}
+
+std::shared_ptr createPool(
+Cluster& cluster, apache::geode::client::Cache& cache) {
+ auto poolFactory = cache.getPoolManager().createFactory();
+ cluster.applyLocators(poolFactory);
+ poolFactory.setSubscriptionEnabled(true); // Per the customer.
+ return poolFactory.create("default");
+}
+
+std::shared_ptr setupRegion(
+apache::geode::client::Cache& cache,
+const std::shared_ptr& pool) {
+ auto region =
+ cache
+ .createRegionFactory(apache::geode::client::RegionShortcut::
+ CACHING_PROXY) // Per the customer.
+ .setPoolName(pool->getName())
+ .create("region");
+
+ return region;
+}
+
+TEST(RegisterKeysTest, DontReceiveValues) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+
+ cluster.start();
+
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("PARTITION")
+ .execute();
+
+ auto cache1 = createCache();
+ auto pool1 = createPool(cluster, cache1);
+ auto region1 = setupRegion(cache1, pool1);
+ auto attrMutator = region1->getAttributesMutator();
+
+ boost::latch allKeysUpdatedLatch{kNumKeys};
+ boost::latch allKeysInvalidLatch{kNumKeys};
+ auto listener =
[jira] [Updated] (GEODE-9824) AvailablePortHelper configures itself poorly in a test JVM
[ https://issues.apache.org/jira/browse/GEODE-9824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9824: -- Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI) > AvailablePortHelper configures itself poorly in a test JVM > -- > > Key: GEODE-9824 > URL: https://issues.apache.org/jira/browse/GEODE-9824 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.15.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > In the test JVM, `AvailablePortHelper` initializes its "next port to check" > to a randomly selected port. That randomly selected port might be one of the > ones that a child VM will check early. > Here's a problematic sequence of events: > # In the test JVM, `AvailablePortHelper` learns that the range of ports > available to it is (say) 23750–24166. It randomly selects one of those as its > "next port to check." Let's suppose it randomly picks 23854 as its starting > port. > # The test starts vm0. In vm0 `AvailablePortHelper` initializes its "next > port to check" by computing it based on its VM number. For the given > available port range (23750–24166), vm0 will *always* start at 23854. > # At this point, both the test JVM and child vm0 have the exact same "next > port to check." Trouble is looming. > # The test requests a port in the test JVM, and gets the randomly selected > one: 23854. It doesn't bind to this port yet. Later it will try to start a > server on this port in vm1. Trouble is fast approaching. > # The test invokes `AvailablePortHelper` in vm0, and gets vm0's starting > port: 23854. The test then starts a server, which binds to that port. > # At this point, the test JVM thinks it has reserved the port, but vm0 has > bound to it. Trouble is imminent. > # The test tries to start a server in vm1, using the port it believes it > reserved. Trouble has arrived. The operation fails because the port is > already in use. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[
https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17446208#comment-17446208
]
ASF GitHub Bot commented on GEODE-9804:
---
mmartell commented on a change in pull request #894:
URL: https://github.com/apache/geode-native/pull/894#discussion_r752733955
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -575,4 +605,223 @@ TEST(RegisterKeysTest, RegisterAnyWithProxyRegion) {
cache.close();
}
+apache::geode::client::Cache createCache() {
+ return apache::geode::client::CacheFactory()
+ .set("log-level", "debug")
+ .set("log-file", "c:/temp/RegisterKeysTest.log")
+ .set("statistic-sampling-enabled", "false")
+ .create();
+}
+
+std::shared_ptr createPool(
+Cluster& cluster, apache::geode::client::Cache& cache) {
+ auto poolFactory = cache.getPoolManager().createFactory();
+ cluster.applyLocators(poolFactory);
+ poolFactory.setSubscriptionEnabled(true); // Per the customer.
+ return poolFactory.create("default");
+}
+
+std::shared_ptr setupRegion(
+apache::geode::client::Cache& cache,
+const std::shared_ptr& pool) {
+ auto region =
+ cache
+ .createRegionFactory(apache::geode::client::RegionShortcut::
+ CACHING_PROXY) // Per the customer.
+ .setPoolName(pool->getName())
+ .create("region");
+
+ return region;
+}
+
+TEST(RegisterKeysTest, DontReceiveValues) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+
+ cluster.start();
+
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("PARTITION")
+ .execute();
+
+ auto cache1 = createCache();
+ auto pool1 = createPool(cluster, cache1);
+ auto region1 = setupRegion(cache1, pool1);
+ auto attrMutator = region1->getAttributesMutator();
+
+ auto allKeysUpdatedLatch = std::make_shared(kNumKeys);
+ auto allKeysInvalidLatch = std::make_shared(kNumKeys);
+ auto listener = std::make_shared(allKeysUpdatedLatch,
+allKeysInvalidLatch);
+ attrMutator->setCacheListener(listener);
+
+ auto cache2 = createCache();
+ auto pool2 = createPool(cluster, cache2);
+ auto region2 = setupRegion(cache2, pool2);
+
+ for (int i = 0; i < kNumKeys; i++) {
+region2->put(CacheableInt32::create(i), CacheableInt32::create(i));
+ }
+
+ region1->registerAllKeys(false, false, false);
+
+ for (int i = 0; i < kNumKeys; i++) {
+auto hasKey = region1->containsKey(CacheableInt32::create(i));
+EXPECT_FALSE(hasKey);
+ }
+
+ for (int i = 0; i < kNumKeys; i++) {
+auto value = region1->get(CacheableInt32::create(i));
+ }
+
+ allKeysInvalidLatch->reset(kNumKeys);
+ listener->reset();
+
+ for (int i = 0; i < kNumKeys; i++) {
+region2->put(CacheableInt32::create(i), CacheableInt32::create(i + 1000));
+ }
+
+ allKeysInvalidLatch->wait();
Review comment:
Yah, good catch. Will switch it to wait_for.
--
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
> Both registerAllKeys and registerRegex always fetch initial entries.
>
>
> Key: GEODE-9804
> URL: https://issues.apache.org/jira/browse/GEODE-9804
> Project: Geode
> Issue Type: Bug
>Reporter: Jacob Barrett
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> A inconsistency and bug in how the two regex interest methods configure the
> initial interest policy results in the both registerAllKeys and registerRegex
> fetching all initial entries despite the boolean parameter to get initial
> entries. Furthermore the misconfiguration results in none of the entries
> actually getting sent to the cache listener. The result is unnecessarily long
> registration times, network traffic and load on the servers. On servers with
> say millions of keys this can result in long GC pauses to unintentionally
> iterate over all those keys.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[
https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17446207#comment-17446207
]
ASF GitHub Bot commented on GEODE-9804:
---
mmartell commented on a change in pull request #894:
URL: https://github.com/apache/geode-native/pull/894#discussion_r752732064
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -39,19 +42,46 @@ namespace {
using apache::geode::client::binary_semaphore;
using apache::geode::client::Cache;
using apache::geode::client::CacheableInt16;
+using apache::geode::client::CacheableInt32;
using apache::geode::client::CacheableKey;
using apache::geode::client::CacheableString;
using apache::geode::client::CacheFactory;
+using apache::geode::client::CacheListener;
using apache::geode::client::CacheListenerMock;
+using apache::geode::client::EntryEvent;
using apache::geode::client::IllegalStateException;
using apache::geode::client::Region;
+using apache::geode::client::RegionEvent;
using apache::geode::client::RegionShortcut;
using ::testing::_;
using ::testing::DoAll;
using ::testing::InvokeWithoutArgs;
using ::testing::Return;
+constexpr auto kNumKeys = 100;
+
+class MyCacheListener : public CacheListener {
+ std::shared_ptr m_allKeysUpdatedLatch;
Review comment:
Done
--
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
> Both registerAllKeys and registerRegex always fetch initial entries.
>
>
> Key: GEODE-9804
> URL: https://issues.apache.org/jira/browse/GEODE-9804
> Project: Geode
> Issue Type: Bug
>Reporter: Jacob Barrett
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> A inconsistency and bug in how the two regex interest methods configure the
> initial interest policy results in the both registerAllKeys and registerRegex
> fetching all initial entries despite the boolean parameter to get initial
> entries. Furthermore the misconfiguration results in none of the entries
> actually getting sent to the cache listener. The result is unnecessarily long
> registration times, network traffic and load on the servers. On servers with
> say millions of keys this can result in long GC pauses to unintentionally
> iterate over all those keys.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9669) AbstractRedisInfoStatsIntegrationTest.memFragmentation_shouldBeGreaterThanOne is Failing
[ https://issues.apache.org/jira/browse/GEODE-9669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9669: -- Labels: pull-request-available (was: ) > AbstractRedisInfoStatsIntegrationTest.memFragmentation_shouldBeGreaterThanOne > is Failing > > > Key: GEODE-9669 > URL: https://issues.apache.org/jira/browse/GEODE-9669 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Wayne >Priority: Major > Labels: pull-request-available > > The > AbstractRedisInfoStatsIntegrationTest.memFragmentation_shouldBeGreaterThanOne > test is currently disabled with the @Ignore annotation. Ideally, we would > like to remove the @Ignore annotation and fix the test/product issues causing > failure. At present, the tests always returns a 1 for the queried stat. > +Acceptance Criteria+ > The > AbstractRedisInfoStatsIntegrationTest.memFragmentation_shouldBeGreaterThanOne > test no longer fails and the @Ignore annotation has been removed. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[
https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17446129#comment-17446129
]
ASF GitHub Bot commented on GEODE-9804:
---
pivotal-jbarrett commented on a change in pull request #894:
URL: https://github.com/apache/geode-native/pull/894#discussion_r752586341
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -39,19 +42,46 @@ namespace {
using apache::geode::client::binary_semaphore;
using apache::geode::client::Cache;
using apache::geode::client::CacheableInt16;
+using apache::geode::client::CacheableInt32;
using apache::geode::client::CacheableKey;
using apache::geode::client::CacheableString;
using apache::geode::client::CacheFactory;
+using apache::geode::client::CacheListener;
using apache::geode::client::CacheListenerMock;
+using apache::geode::client::EntryEvent;
using apache::geode::client::IllegalStateException;
using apache::geode::client::Region;
+using apache::geode::client::RegionEvent;
using apache::geode::client::RegionShortcut;
using ::testing::_;
using ::testing::DoAll;
using ::testing::InvokeWithoutArgs;
using ::testing::Return;
+constexpr auto kNumKeys = 100;
+
+class MyCacheListener : public CacheListener {
+ std::shared_ptr m_allKeysUpdatedLatch;
Review comment:
Why are these `std::shared_ptr`? Just make them public and await on them
directly?
Also, style guide says `camelCaseFollowedByUnderscore_` for members names.
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -575,4 +605,223 @@ TEST(RegisterKeysTest, RegisterAnyWithProxyRegion) {
cache.close();
}
+apache::geode::client::Cache createCache() {
+ return apache::geode::client::CacheFactory()
+ .set("log-level", "debug")
+ .set("log-file", "c:/temp/RegisterKeysTest.log")
+ .set("statistic-sampling-enabled", "false")
+ .create();
+}
+
+std::shared_ptr createPool(
+Cluster& cluster, apache::geode::client::Cache& cache) {
+ auto poolFactory = cache.getPoolManager().createFactory();
+ cluster.applyLocators(poolFactory);
+ poolFactory.setSubscriptionEnabled(true); // Per the customer.
+ return poolFactory.create("default");
+}
+
+std::shared_ptr setupRegion(
+apache::geode::client::Cache& cache,
+const std::shared_ptr& pool) {
+ auto region =
+ cache
+ .createRegionFactory(apache::geode::client::RegionShortcut::
+ CACHING_PROXY) // Per the customer.
+ .setPoolName(pool->getName())
+ .create("region");
+
+ return region;
+}
+
+TEST(RegisterKeysTest, DontReceiveValues) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+
+ cluster.start();
+
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("PARTITION")
+ .execute();
+
+ auto cache1 = createCache();
+ auto pool1 = createPool(cluster, cache1);
+ auto region1 = setupRegion(cache1, pool1);
+ auto attrMutator = region1->getAttributesMutator();
+
+ auto allKeysUpdatedLatch = std::make_shared(kNumKeys);
+ auto allKeysInvalidLatch = std::make_shared(kNumKeys);
+ auto listener = std::make_shared(allKeysUpdatedLatch,
+allKeysInvalidLatch);
+ attrMutator->setCacheListener(listener);
+
+ auto cache2 = createCache();
+ auto pool2 = createPool(cluster, cache2);
+ auto region2 = setupRegion(cache2, pool2);
+
+ for (int i = 0; i < kNumKeys; i++) {
+region2->put(CacheableInt32::create(i), CacheableInt32::create(i));
+ }
+
+ region1->registerAllKeys(false, false, false);
+
+ for (int i = 0; i < kNumKeys; i++) {
+auto hasKey = region1->containsKey(CacheableInt32::create(i));
+EXPECT_FALSE(hasKey);
+ }
+
+ for (int i = 0; i < kNumKeys; i++) {
+auto value = region1->get(CacheableInt32::create(i));
+ }
+
+ allKeysInvalidLatch->reset(kNumKeys);
+ listener->reset();
+
+ for (int i = 0; i < kNumKeys; i++) {
+region2->put(CacheableInt32::create(i), CacheableInt32::create(i + 1000));
+ }
+
+ allKeysInvalidLatch->wait();
Review comment:
Should use `wait_for` and assert that it didn't timeout otherwise this
test will hang FOREVER if the latch is never satisfied.
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -575,4 +605,223 @@ TEST(RegisterKeysTest, RegisterAnyWithProxyRegion) {
cache.close();
}
+apache::geode::client::Cache createCache() {
+ return apache::geode::client::CacheFactory()
+ .set("log-level", "debug")
+ .set("log-file", "c:/temp/RegisterKeysTest.log")
+ .set("statistic-sampling-enabled", "false")
+ .create();
+}
+
+std::shared_ptr createPool(
+Cluster& cluster, apache::geode::client::Cache& cache) {
+ auto poolFactory = cache.getPoolManager().createFactory();
+ cluster.applyLocators(poolFactory);
+ poolFactory.setSubscriptionEnabled(true); // Per the
[jira] [Updated] (GEODE-9822) Split-brain Possible During Network Partition in Two-Locator Cluster
[ https://issues.apache.org/jira/browse/GEODE-9822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9822: -- Labels: pull-request-available (was: ) > Split-brain Possible During Network Partition in Two-Locator Cluster > > > Key: GEODE-9822 > URL: https://issues.apache.org/jira/browse/GEODE-9822 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Bill Burcham >Priority: Major > Labels: pull-request-available > > In a two-locator cluster with default member weights and default setting > (true) of enable-network-partition-detection, if a long-lived network > partition separates the two members, a split-brain will arise: there will be > two coordinators at the same time. > The reason for this can be found in the GMSJoinLeave.isNetworkPartition() > method. That method's name is misleading. A name like majorityLost() would > probably be more apt. It needs to return true iff the weight of "crashed" > members (in the prospective view) is greater-than-or-equal-to 50% of the > total weight (of all members in the current view). > What the method actually does is return true iff the weight of "crashed" > members is greater-than 51% of the total weight. As a result, if we have two > members of equal weight, and the coordinator sees that the non-coordinator is > "crashed", the coordinator will keep running. If a network partition is > happening, and the non-coordinator is still running, then it will become a > coordinator and start producing views. Now we'll have two coordinators > producing views concurrently. > For this discussion "crashed" members are members for which the coordinator > has received a RemoveMemberRequest message. These are members that the > failure detector has deemed failed. Keep in mind the failure detector is > imperfect (it's not always right), and that's kind of the whole point of this > ticket: we've lost contact with the non-coordinator member, but that doesn't > mean it can't still be running (on the other side of the partition). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9821) Remove use of local docker-compose from Radish native tests
[
https://issues.apache.org/jira/browse/GEODE-9821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9821:
--
Labels: pull-request-available (was: )
> Remove use of local docker-compose from Radish native tests
> ---
>
> Key: GEODE-9821
> URL: https://issues.apache.org/jira/browse/GEODE-9821
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> Recent updates to Docker Desktop have introduced docker compose V2 which does
> not appear to be compatible with testcontainers
> ([https://github.com/testcontainers/testcontainers-java/issues/4565).] This
> causes startup to fail with:
> {noformat}
> org.testcontainers.containers.ContainerLaunchException: Container startup
> failed at
> org.testcontainers.containers.GenericContainer.doStart(GenericContainer.java:330)
> at
> org.testcontainers.containers.GenericContainer.start(GenericContainer.java:311)
> at
> org.testcontainers.containers.DockerComposeContainer.startAmbassadorContainers(DockerComposeContainer.java:330)
> at
> org.testcontainers.containers.DockerComposeContainer.start(DockerComposeContainer.java:178)
> at
> org.apache.geode.redis.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:90)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:235)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54)
> Caused by: org.rnorth.ducttape.RetryCountExceededException: Retry limit hit
> with exception
> at
> org.rnorth.ducttape.unreliables.Unreliables.retryUntilSuccess(Unreliables.java:88)
> at
> org.testcontainers.containers.GenericContainer.doStart(GenericContainer.java:323)
> ... 14 more
> Caused by: org.testcontainers.containers.ContainerLaunchException: Could not
> create/start container
> at
> org.testcontainers.containers.GenericContainer.tryStart(GenericContainer.java:497)
> at
> org.testcontainers.containers.GenericContainer.lambda$doStart$0(GenericContainer.java:325)
> at
> org.rnorth.ducttape.unreliables.Unreliables.retryUntilSuccess(Unreliables.java:81)
> ... 15 more
> Caused by: org.testcontainers.containers.ContainerLaunchException: Aborting
> attempt to link to container acceptancet7mloa_redis-node-1_1 as it is not
> running
> at
> org.testcontainers.containers.GenericContainer.applyConfiguration(GenericContainer.java:779)
> at
> org.testcontainers.containers.GenericContainer.tryStart(GenericContainer.java:359)
> ... 17 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9815) Recovering persistent members can result in extra copies of a bucket or two copies in the same redundancy zone
[ https://issues.apache.org/jira/browse/GEODE-9815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9815: -- Labels: GeodeOperationAPI needsTriage pull-request-available (was: GeodeOperationAPI needsTriage) > Recovering persistent members can result in extra copies of a bucket or two > copies in the same redundancy zone > -- > > Key: GEODE-9815 > URL: https://issues.apache.org/jira/browse/GEODE-9815 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.15.0 >Reporter: Dan Smith >Assignee: Mark Hanson >Priority: Major > Labels: GeodeOperationAPI, needsTriage, pull-request-available > > The fix in GEODE-9554 is incomplete for some cases, and it also introduces a > new issue when removing buckets that are over redundancy. > GEODE-9554 and these new issues are all related to using redundancy zones and > having persistent members. > With persistence, when we start up a member with persisted buckets, we always > recover the persisted buckets on startup, regardless of whether redundancy is > already met or what zone the existing buckets are on. This is necessary to > ensure that we can recover all colocated buckets that might be persisted on > the member. > Because recovering these persistent buckets may cause us to go over > redundancy, after we recover from disk, we run a "restore redundancy" task > that actually removes copies of buckets that are over redundancy. > GEODE-9554 addressed one case where we end up removing the last copy of a > bucket from one redundancy zone while leaving two copies in another > redundancy zone. It did so by disallowing the removal of a bucket if it is > the last copy in a redundancy zone. > There are a couple of issues with this approach. > *Problem 1:* We may end up with two copies of the bucket in one zone in some > cases > With a slight tweak to the scenario fixed with GEODE-9554 we can end up never > getting out of the situation where we have two copies of a bucket in the same > zone. > Steps: > 1. Start two redundancy zones A and B with two members each. Bucket 0 is on > member A1 and B1. > 2. Shutdown member A1. > 3. Rebalance - this will create bucket 0 on A2. > 4. Shutdown B1. Revoke it's disk store and delete the data > 5. Startup A1 - it will recover bucket 0. > 6. At this point, bucket 0 is on A1 and A2, and nothing will resolve that > situation. > *Problem 2:* We may never delete extra copies of a bucket > The fix for GEODE-9554 introduces a new problem if we have more than 2 > redundancy zones > Steps > 1. Start three redundancy zones A,B,C with one member each. Bucket 0 is on A1 > and B1 > 2. Shutdown A1 > 3. Rebalance - this will create Bucket 0 on C1 > 4. Startup A1 - this will recreate bucket 0 > 5. Now we have bucket 0 on A1, B1, and C1. Nothing will remove the extra copy. > I think the overall fix is probably to do something different than prevent > removing the last copy of a bucket from a redundancy zone. Instead, I think > we should do something like this: > 1. Change PartitionRegionLoadModel.getOverRedundancyBuckets to return *any* > buckets that have two copies in the same zone, as well as any buckets that > are actually over redundancy. > 2. Change PartitionRegionLoadModel.findBestRemove to always remove extra > copies of a bucket in the same zone first > 3. Back out the changes for GEODE-9554 and let the last copy be deleted from > a zone. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9816) Implement Radish CLIENT command
[
https://issues.apache.org/jira/browse/GEODE-9816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9816:
--
Labels: pull-request-available (was: )
> Implement Radish CLIENT command
> ---
>
> Key: GEODE-9816
> URL: https://issues.apache.org/jira/browse/GEODE-9816
> Project: Geode
> Issue Type: New Feature
> Components: redis
>Reporter: Jens Deppe
>Assignee: Kristen
>Priority: Major
> Labels: pull-request-available
>
> It appears that using {{JedisCluster}} with security requires the {{CLIENT}}
> command to exist. Using {{JedisCluster}} as:
> {noformat}
> JedisCluster jedis = new JedisCluster(new HostAndPort(BIND_ADDRESS,
> redisServerPort),
> REDIS_CLIENT_TIMEOUT, SO_TIMEOUT, DEFAULT_MAX_ATTEMPTS, "user", "user",
> "client",
> new GenericObjectPoolConfig<>()); {noformat}
> Results in connection errors:
> {noformat}
> Caused by: redis.clients.jedis.exceptions.JedisDataException: ERR unknown
> command `CLIENT`, with args beginning with: `setname`, `client`,
> {noformat}
> We will need to decide which subcommands to implement. At a minimum:
> - {{SETNAME}} (https://redis.io/commands/client-setname)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9820) stopCQ does not trigger re-authentication
[ https://issues.apache.org/jira/browse/GEODE-9820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9820: -- Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI) > stopCQ does not trigger re-authentication > - > > Key: GEODE-9820 > URL: https://issues.apache.org/jira/browse/GEODE-9820 > Project: Geode > Issue Type: Sub-task > Components: cq >Affects Versions: 1.14.0 >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > after credential expires, when user execute `stopCQ` operation, > re-authentication does not get triggered. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9817) Allow analyze serializables tests to provide custom source set paths to ClassAnalysisRule
[ https://issues.apache.org/jira/browse/GEODE-9817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9817: -- Labels: pull-request-available (was: ) > Allow analyze serializables tests to provide custom source set paths to > ClassAnalysisRule > - > > Key: GEODE-9817 > URL: https://issues.apache.org/jira/browse/GEODE-9817 > Project: Geode > Issue Type: Wish > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > > In order to make SanctionedSerializablesService and the related tests to be > more pluggable by external modules, I need to make changes to allow analyze > serializables tests to provide custom source set paths to ClassAnalysisRule. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[ https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17444936#comment-17444936 ] ASF GitHub Bot commented on GEODE-9804: --- mmartell edited a comment on pull request #894: URL: https://github.com/apache/geode-native/pull/894#issuecomment-971172824 **NOTE:** The integration test failure on ubuntu 16.04 debug is not related to this PR. -- 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 > Both registerAllKeys and registerRegex always fetch initial entries. > > > Key: GEODE-9804 > URL: https://issues.apache.org/jira/browse/GEODE-9804 > Project: Geode > Issue Type: Bug >Reporter: Jacob Barrett >Priority: Major > Labels: needsTriage, pull-request-available > > A inconsistency and bug in how the two regex interest methods configure the > initial interest policy results in the both registerAllKeys and registerRegex > fetching all initial entries despite the boolean parameter to get initial > entries. Furthermore the misconfiguration results in none of the entries > actually getting sent to the cache listener. The result is unnecessarily long > registration times, network traffic and load on the servers. On servers with > say millions of keys this can result in long GC pauses to unintentionally > iterate over all those keys. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[ https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17444935#comment-17444935 ] ASF GitHub Bot commented on GEODE-9804: --- mmartell commented on pull request #894: URL: https://github.com/apache/geode-native/pull/894#issuecomment-971172824 **NOTE:** The integration test failure on ubuntu 16.04 debug is not related to this PR: -- 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 > Both registerAllKeys and registerRegex always fetch initial entries. > > > Key: GEODE-9804 > URL: https://issues.apache.org/jira/browse/GEODE-9804 > Project: Geode > Issue Type: Bug >Reporter: Jacob Barrett >Priority: Major > Labels: needsTriage, pull-request-available > > A inconsistency and bug in how the two regex interest methods configure the > initial interest policy results in the both registerAllKeys and registerRegex > fetching all initial entries despite the boolean parameter to get initial > entries. Furthermore the misconfiguration results in none of the entries > actually getting sent to the cache listener. The result is unnecessarily long > registration times, network traffic and load on the servers. On servers with > say millions of keys this can result in long GC pauses to unintentionally > iterate over all those keys. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9449) remove 'b' prefix from constants
[ https://issues.apache.org/jira/browse/GEODE-9449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9449: -- Labels: pull-request-available (was: ) > remove 'b' prefix from constants > > > Key: GEODE-9449 > URL: https://issues.apache.org/jira/browse/GEODE-9449 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Priority: Minor > Labels: pull-request-available > > I number of constants in the redis packages have a 'b' prefix on their name. > This might have been a use of Hungarian notation but that is not clear. The > convention for constant names in geode is all upper case with underscore > between words. So the 'b' prefix should be removed. See StringBytesGlossary > for the location of many of these constants. Most of the constants in > StringBytesGlossary contains bytes, one or more, but if a few of the > constants in it are actually String instances. Consider renaming them to have > _STRING suffix or moving them to another class like StringGlossary. > The byte array constants in this class are marked with the MakeImmutable > annotation. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9803) CI Failure: AuthExpirationDUnitTest > registeredInterest_slowReAuth_policyDefault fails after user is expired
[
https://issues.apache.org/jira/browse/GEODE-9803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9803:
--
Labels: GeodeOperationAPI flaky needsTriage pull-request-available (was:
GeodeOperationAPI flaky needsTriage)
> CI Failure: AuthExpirationDUnitTest >
> registeredInterest_slowReAuth_policyDefault fails after user is expired
> -
>
> Key: GEODE-9803
> URL: https://issues.apache.org/jira/browse/GEODE-9803
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Jinmei Liao
>Priority: Major
> Labels: GeodeOperationAPI, flaky, needsTriage,
> pull-request-available
> Fix For: 1.15.0
>
>
> Originally seen in the distributed mass test run:
> {noformat}
> > Task :geode-core:distributedTest
> AuthExpirationDUnitTest > registeredInterest_slowReAuth_policyDefault FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.AuthExpirationDUnitTest$$Lambda$580/141775835.run
> in VM 0 running on Host
> heavy-lifter-2a24cff8-0d64-55e0-9585-2d6391f92533.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:96)
> at
> org.apache.geode.security.AuthExpirationDUnitTest.registeredInterest_slowReAuth_policyDefault(AuthExpirationDUnitTest.java:156)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.security.AuthExpirationDUnitTest that uses
> org.apache.geode.cache.Region
> Expected size: 100 but was: 0 in:
> [] within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.security.AuthExpirationDUnitTest.lambda$registeredInterest_slowReAuth_policyDefault$bb17a952$2(AuthExpirationDUnitTest.java:158)
> Caused by:
> java.lang.AssertionError:
> Expected size: 100 but was: 0 in:
> []
> at
> org.apache.geode.security.AuthExpirationDUnitTest.lambda$null$3(AuthExpirationDUnitTest.java:159)
> 8334 tests completed, 1 failed, 414 skipped
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0646/test-results/distributedTest/1636236082/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0646/test-artifacts/1636236082/distributedtestfiles-openjdk8-1.15.0-build.0646.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[
https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17444841#comment-17444841
]
ASF GitHub Bot commented on GEODE-9804:
---
mmartell commented on a change in pull request #894:
URL: https://github.com/apache/geode-native/pull/894#discussion_r750706205
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -39,19 +42,56 @@ namespace {
using apache::geode::client::binary_semaphore;
using apache::geode::client::Cache;
using apache::geode::client::CacheableInt16;
+using apache::geode::client::CacheableInt32;
using apache::geode::client::CacheableKey;
using apache::geode::client::CacheableString;
using apache::geode::client::CacheFactory;
using apache::geode::client::CacheListenerMock;
+using apache::geode::client::EntryEvent;
using apache::geode::client::IllegalStateException;
using apache::geode::client::Region;
+using apache::geode::client::RegionEvent;
using apache::geode::client::RegionShortcut;
+using apache::geode::client::CacheListener;
using ::testing::_;
using ::testing::DoAll;
using ::testing::InvokeWithoutArgs;
using ::testing::Return;
+const int NUMKEYS = 100;
+
+class MyCacheListener : public CacheListener {
Review comment:
You agreed a real CacheListener with count_down latches was appropriate.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Both registerAllKeys and registerRegex always fetch initial entries.
>
>
> Key: GEODE-9804
> URL: https://issues.apache.org/jira/browse/GEODE-9804
> Project: Geode
> Issue Type: Bug
>Reporter: Jacob Barrett
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> A inconsistency and bug in how the two regex interest methods configure the
> initial interest policy results in the both registerAllKeys and registerRegex
> fetching all initial entries despite the boolean parameter to get initial
> entries. Furthermore the misconfiguration results in none of the entries
> actually getting sent to the cache listener. The result is unnecessarily long
> registration times, network traffic and load on the servers. On servers with
> say millions of keys this can result in long GC pauses to unintentionally
> iterate over all those keys.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[
https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17444842#comment-17444842
]
ASF GitHub Bot commented on GEODE-9804:
---
mmartell commented on a change in pull request #894:
URL: https://github.com/apache/geode-native/pull/894#discussion_r750706390
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -575,4 +615,233 @@ TEST(RegisterKeysTest, RegisterAnyWithProxyRegion) {
cache.close();
}
+apache::geode::client::Cache createCache() {
+ return apache::geode::client::CacheFactory()
+ .set("log-level", "none")
+ .set("statistic-sampling-enabled", "false")
+ .create();
+}
+
+std::shared_ptr createPool(
+Cluster& cluster, apache::geode::client::Cache& cache) {
+ auto poolFactory = cache.getPoolManager().createFactory();
+ cluster.applyLocators(poolFactory);
+ poolFactory.setSubscriptionEnabled(true); // Per the customer.
+ return poolFactory.create("default");
+}
+
+std::shared_ptr setupRegion(
+apache::geode::client::Cache& cache,
+const std::shared_ptr& pool) {
+ auto region =
+ cache
+ .createRegionFactory(apache::geode::client::RegionShortcut::
+ CACHING_PROXY) // Per the customer.
+ .setPoolName(pool->getName())
+ .create("region");
+
+ return region;
+}
+
+TEST(RegisterKeysTest, DontReceiveValues) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+
+ cluster.start();
+
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("PARTITION")
+ .execute();
+
+ auto cache1 = createCache();
+ auto pool1 = createPool(cluster, cache1);
+ auto region1 = setupRegion(cache1, pool1);
+ auto attrMutator = region1->getAttributesMutator();
+ auto listener = std::make_shared();
+ attrMutator->setCacheListener(listener);
+
+ auto cache2 = createCache();
+ auto pool2 = createPool(cluster, cache2);
+ auto region2 = setupRegion(cache2, pool2);
+
+ for (int i = 0; i < NUMKEYS; i++) {
+region2->put(apache::geode::client::CacheableInt32::create(i),
Review comment:
Good catch. Done.
--
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
> Both registerAllKeys and registerRegex always fetch initial entries.
>
>
> Key: GEODE-9804
> URL: https://issues.apache.org/jira/browse/GEODE-9804
> Project: Geode
> Issue Type: Bug
>Reporter: Jacob Barrett
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> A inconsistency and bug in how the two regex interest methods configure the
> initial interest policy results in the both registerAllKeys and registerRegex
> fetching all initial entries despite the boolean parameter to get initial
> entries. Furthermore the misconfiguration results in none of the entries
> actually getting sent to the cache listener. The result is unnecessarily long
> registration times, network traffic and load on the servers. On servers with
> say millions of keys this can result in long GC pauses to unintentionally
> iterate over all those keys.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9811) When a node is stopped using nice_exit or its cache is closing, client may fail due to UnavailableSecurityManagerException
[ https://issues.apache.org/jira/browse/GEODE-9811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9811: -- Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI) > When a node is stopped using nice_exit or its cache is closing, client may > fail due to UnavailableSecurityManagerException > -- > > Key: GEODE-9811 > URL: https://issues.apache.org/jira/browse/GEODE-9811 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.14.0 >Reporter: Joris Melchior >Assignee: Joris Melchior >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > Due to the sequence of events occurring when a server is shutting down it's > possible for some transactions to not be able to get the security manager > while performing an operation. > Currently the operation fails without retry while the correct behaviour would > be to try and retry the operation at least once on another member. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9812) Kill multiple Radish servers expecting operations to continue
[ https://issues.apache.org/jira/browse/GEODE-9812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9812: -- Labels: pull-request-available (was: ) > Kill multiple Radish servers expecting operations to continue > - > > Key: GEODE-9812 > URL: https://issues.apache.org/jira/browse/GEODE-9812 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Priority: Major > Labels: pull-request-available > > Kill more than one server and expect the distributed system to recover. Data > loss is expected. The motivation behind this test is to ensure that, in a > situation where both the primary and secondary buckets are not available, > Redis clients are able to continue doing ops without getting stuck or hitting > loops of MOVED responses etc. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9809) Memory leak in PersistentBucketRecoverer
[ https://issues.apache.org/jira/browse/GEODE-9809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9809: -- Labels: needsTriage pull-request-available (was: needsTriage) > Memory leak in PersistentBucketRecoverer > > > Key: GEODE-9809 > URL: https://issues.apache.org/jira/browse/GEODE-9809 > Project: Geode > Issue Type: Bug > Components: memcached >Affects Versions: 1.14.0 >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: needsTriage, pull-request-available > > When performing consecutive create/destroy colocated persistent partitioned > regions, memory leak is observed. In our test, in cluster with 50 servers, > memory leak is observed in previous scenario. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-1537) DurableRegistrationDUnitTest.testDurableClientWithRegistrationHA
[ https://issues.apache.org/jira/browse/GEODE-1537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-1537: -- Labels: CI pull-request-available (was: CI) > DurableRegistrationDUnitTest.testDurableClientWithRegistrationHA > > > Key: GEODE-1537 > URL: https://issues.apache.org/jira/browse/GEODE-1537 > Project: Geode > Issue Type: Bug > Components: client queues >Reporter: Jinmei Liao >Assignee: Jens Deppe >Priority: Major > Labels: CI, pull-request-available > > Geode_develop_DistributedTests/2883 > Error Message > com.gemstone.gemfire.test.dunit.RMIException: While invoking > com.gemstone.gemfire.internal.cache.tier.sockets.DurableRegistrationDUnitTest$$Lambda$373/449639279.run > in VM 1 running on Host timor.gemstone.com with 4 VMs > Stacktrace > com.gemstone.gemfire.test.dunit.RMIException: While invoking > com.gemstone.gemfire.internal.cache.tier.sockets.DurableRegistrationDUnitTest$$Lambda$373/449639279.run > in VM 1 running on Host timor.gemstone.com with 4 VMs > at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:389) > at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:355) > at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:293) > at > com.gemstone.gemfire.internal.cache.tier.sockets.DurableRegistrationDUnitTest.testDurableClientWithRegistrationHA(DurableRegistrationDUnitTest.java:421) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.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:112) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.GeneratedMethodAccessor426.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32) > at > org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93) > at com.sun.proxy.$Proxy2.processTestClass(Unknown Source) > at > org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109) > at sun.reflect.GeneratedMethodAccessor425.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at
[jira] [Updated] (GEODE-9090) Suspect Strings in Logs DeploymentManagementRedployDUnitTest > redeployJarsWithNewVersionsOfFunctions
[
https://issues.apache.org/jira/browse/GEODE-9090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9090:
--
Labels: pull-request-available (was: )
> Suspect Strings in Logs DeploymentManagementRedployDUnitTest >
> redeployJarsWithNewVersionsOfFunctions
> -
>
> Key: GEODE-9090
> URL: https://issues.apache.org/jira/browse/GEODE-9090
> Project: Geode
> Issue Type: Task
> Components: management
>Reporter: Bill Burcham
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> Suspect strings in logs in this CI run
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/107:
> {code:java}
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest
> > redeployJarsWithNewVersionsOfFunctions 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 'dunit_suspect-vm0.log' at line 691
>
> PK\u0003\u0004\u0014\u\u0008\u0008\u0008\u{4}R\u\u\u\u\u\u\u\u\u\u\u\u)\u\u0004\uDeployCommandRedeployDUnitFunctionA.class\u\u~~n~~@\u0010~~?~~IhChh~~:
> ~~Bp+B~~\u0012E
> EP5P$nJ~~r~~h~~F~~g~~\u\u0017P9~~\u<\u0014b~~qUp~~H\u000fw~~~y\u000f\uO~~ `~~?~~2G\u0006~~%%~~^
> O~~C
>
> i\u0008?~~.w~~Y~~\u000c~~My;~~K\u0006~~\u001c
>
> dl~~\u001a8~~\u0003u1~~OZB#~~mandRedeployDUnitFunctionA.class\u\uPK\u0005\u0006\u\u\u\u\u0001\u\u0001\u[\u\u\uj\u0002\u\u\u\u
> --uWbis1NkO9dSY3pUDEYgZgkx4bh2w52
> Content-Disposition: form-data; name="config"
> Content-Type: application/json
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 710
>
> PK\u0003\u0004\u0014\u\u0008\u0008\u0008\u{4}R\u\u\u\u\u\u\u\u\u\u\u\u:\u\u0004\ujddunit/function/DeployCommandRedeployDUnitFunctionB.class\u\u~~RMo~~@\u0010}~~/\u001b!$\u0016Z'~~j!z+B*~~"~~"~~\u001a(\u0012\u001b9vd~~Q~~7q~~\u000b~~\u001c~~\u0001~~(~~*~~\u0007R~~4~~;\u0007~~=~~\u000c]G\u001b\u001d\u001dw~~X\u00064aC~~\u0026C\u000c~~z~~P~~\u000c~
>
> ~~\u000cd:\u0016~~+>~~Is~~G"N|~~A~~2h~~T8~~"~~#k\u0018Fg~~9\u0011~~'(d~~\u001cb\u000fQ2\u000c~~aOSU=~~\u000c-~~;~~y#\u0015~~gh~~3%~~\u0018~~H~~y*2~vC?x~~\u0016IN~~(L"G\u000cdZ~~u(f~\uS\u001e~~GzL\u0018~~k~~o~~\u0001~~\u0018~~c\u0011~~d|~~a~~.\u001c~~L4q~~ao
>
> wx"\u001c~~y{NR\u0019v~~F?3\u0008\\\u00111~~D~@\\~~\\\u0001Ny\u0017h~~\u001a\u0016:\u000e~~5~~_~~n~~
>
> I~t3~~o`_p~~d-S~~H.`1sh[\u0026~~\u001c~~C~~\u000es~~\u0012C~~|~~J
> \u0017~~w~~44~~/7\u000b
> ~~H~~.\u0017R.\u0016~~Ari\u000e~~V\u0012/_+j)\u0007 X~~
>
> PK\u0007\u0008~~w7\u0001\u\u\u0001\u0004\u\uPK\u0001\u0002\u0014\u\u0014\u\u0008\u0008\u0008\u{4}R~~w7\u0001\u\u\u0001\u0004\u\u:\u\u0004\u\u\u\u\u\u\u\u\u\u\u\u\u\u\ujddunit/function/DeployCommandRedeployDUnitFunctionB.class\u\uPK\u0005\u0006\u\u\u\u\u0001\u\u0001\ul\u\u\uZ\u0002\u\u\u\u
> --XADbzFelszjYv8QsixUwkKt2kmAJrXT6W
> Content-Disposition: form-data; name="config"
> Content-Type: application/json
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 729
>
>
[jira] [Commented] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[ https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17444066#comment-17444066 ] ASF GitHub Bot commented on GEODE-9804: --- pivotal-jbarrett commented on pull request #892: URL: https://github.com/apache/geode-native/pull/892#issuecomment-969247534 Closing in favor of https://github.com/apache/geode-native/pull/894 -- 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 > Both registerAllKeys and registerRegex always fetch initial entries. > > > Key: GEODE-9804 > URL: https://issues.apache.org/jira/browse/GEODE-9804 > Project: Geode > Issue Type: Bug >Reporter: Jacob Barrett >Priority: Major > Labels: needsTriage, pull-request-available > > A inconsistency and bug in how the two regex interest methods configure the > initial interest policy results in the both registerAllKeys and registerRegex > fetching all initial entries despite the boolean parameter to get initial > entries. Furthermore the misconfiguration results in none of the entries > actually getting sent to the cache listener. The result is unnecessarily long > registration times, network traffic and load on the servers. On servers with > say millions of keys this can result in long GC pauses to unintentionally > iterate over all those keys. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[ https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17444065#comment-17444065 ] ASF GitHub Bot commented on GEODE-9804: --- pivotal-jbarrett closed pull request #892: URL: https://github.com/apache/geode-native/pull/892 -- 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 > Both registerAllKeys and registerRegex always fetch initial entries. > > > Key: GEODE-9804 > URL: https://issues.apache.org/jira/browse/GEODE-9804 > Project: Geode > Issue Type: Bug >Reporter: Jacob Barrett >Priority: Major > Labels: needsTriage, pull-request-available > > A inconsistency and bug in how the two regex interest methods configure the > initial interest policy results in the both registerAllKeys and registerRegex > fetching all initial entries despite the boolean parameter to get initial > entries. Furthermore the misconfiguration results in none of the entries > actually getting sent to the cache listener. The result is unnecessarily long > registration times, network traffic and load on the servers. On servers with > say millions of keys this can result in long GC pauses to unintentionally > iterate over all those keys. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[
https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17444050#comment-17444050
]
ASF GitHub Bot commented on GEODE-9804:
---
pivotal-jbarrett commented on a change in pull request #894:
URL: https://github.com/apache/geode-native/pull/894#discussion_r749612922
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -575,4 +615,233 @@ TEST(RegisterKeysTest, RegisterAnyWithProxyRegion) {
cache.close();
}
+apache::geode::client::Cache createCache() {
+ return apache::geode::client::CacheFactory()
+ .set("log-level", "none")
+ .set("statistic-sampling-enabled", "false")
+ .create();
+}
+
+std::shared_ptr createPool(
+Cluster& cluster, apache::geode::client::Cache& cache) {
+ auto poolFactory = cache.getPoolManager().createFactory();
+ cluster.applyLocators(poolFactory);
+ poolFactory.setSubscriptionEnabled(true); // Per the customer.
+ return poolFactory.create("default");
+}
+
+std::shared_ptr setupRegion(
+apache::geode::client::Cache& cache,
+const std::shared_ptr& pool) {
+ auto region =
+ cache
+ .createRegionFactory(apache::geode::client::RegionShortcut::
+ CACHING_PROXY) // Per the customer.
+ .setPoolName(pool->getName())
+ .create("region");
+
+ return region;
+}
+
+TEST(RegisterKeysTest, DontReceiveValues) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+
+ cluster.start();
+
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("PARTITION")
+ .execute();
+
+ auto cache1 = createCache();
+ auto pool1 = createPool(cluster, cache1);
+ auto region1 = setupRegion(cache1, pool1);
+ auto attrMutator = region1->getAttributesMutator();
+ auto listener = std::make_shared();
+ attrMutator->setCacheListener(listener);
+
+ auto cache2 = createCache();
+ auto pool2 = createPool(cluster, cache2);
+ auto region2 = setupRegion(cache2, pool2);
+
+ for (int i = 0; i < NUMKEYS; i++) {
+region2->put(apache::geode::client::CacheableInt32::create(i),
Review comment:
The using statements above mean you can just invoke
`CacheableInt32::create`, otherwise delete the using statements.
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -39,19 +42,56 @@ namespace {
using apache::geode::client::binary_semaphore;
using apache::geode::client::Cache;
using apache::geode::client::CacheableInt16;
+using apache::geode::client::CacheableInt32;
using apache::geode::client::CacheableKey;
using apache::geode::client::CacheableString;
using apache::geode::client::CacheFactory;
using apache::geode::client::CacheListenerMock;
+using apache::geode::client::EntryEvent;
using apache::geode::client::IllegalStateException;
using apache::geode::client::Region;
+using apache::geode::client::RegionEvent;
using apache::geode::client::RegionShortcut;
+using apache::geode::client::CacheListener;
using ::testing::_;
using ::testing::DoAll;
using ::testing::InvokeWithoutArgs;
using ::testing::Return;
+const int NUMKEYS = 100;
+
+class MyCacheListener : public CacheListener {
Review comment:
For future reference you should learn and use gmock for this sort of
thing. You can mock up the `CacheListener` interface and register the mock with
the cache. Then you can assert that specific methods on the mock were invoked.
--
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
> Both registerAllKeys and registerRegex always fetch initial entries.
>
>
> Key: GEODE-9804
> URL: https://issues.apache.org/jira/browse/GEODE-9804
> Project: Geode
> Issue Type: Bug
>Reporter: Jacob Barrett
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> A inconsistency and bug in how the two regex interest methods configure the
> initial interest policy results in the both registerAllKeys and registerRegex
> fetching all initial entries despite the boolean parameter to get initial
> entries. Furthermore the misconfiguration results in none of the entries
> actually getting sent to the cache listener. The result is unnecessarily long
> registration times, network traffic and load on the servers. On servers with
> say millions of keys this can result in long GC pauses to unintentionally
> iterate over all those keys.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9324) Remove ACE_Task references
[
https://issues.apache.org/jira/browse/GEODE-9324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17443900#comment-17443900
]
ASF GitHub Bot commented on GEODE-9324:
---
pdxcodemonkey commented on a change in pull request #812:
URL: https://github.com/apache/geode-native/pull/812#discussion_r749424688
##
File path: cppcache/integration-test/ThinClientSecurityHelper.hpp
##
@@ -170,20 +170,20 @@ void initClientAuth(char UserType) {
}
}
-// This putThread class is used in
+// This PutThread class is used in
// testThinClientTracking,testThinClientTicket304, testThinClientTicket317
-class putThread : public ACE_Task_Base {
+class PutThread {
public:
- explicit putThread(std::shared_ptr r, bool regInt = false,
- int waitTime = 0) {
-m_reg = r;
-m_regInt = regInt;
-m_numthreads = 1;
-m_numops = 0;
-m_isCallBack = false;
-m_sameKey = false;
-m_waitTime = waitTime;
+ explicit PutThread(std::shared_ptr r, bool regInt = false,
+ int waitTime = 0)
+ : m_reg{r},
Review comment:
Often when refactoring things in a class these days, I will take a few
minutes and rename the member variables to conform to the style guide. Your
call, just would be nice as long as you're in here mucking about.
--
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
> Remove ACE_Task references
> --
>
> Key: GEODE-9324
> URL: https://issues.apache.org/jira/browse/GEODE-9324
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Major
> Labels: obliterate-ace, pull-request-available
>
> *AS A* native client contributor
> *I WANT TO* remove all remaining references to ACE_Task
> *SO THAT* eventually we can get rid of ACE library
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[
https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17443174#comment-17443174
]
ASF GitHub Bot commented on GEODE-9804:
---
mmartell commented on a change in pull request #894:
URL: https://github.com/apache/geode-native/pull/894#discussion_r748755961
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -575,4 +581,257 @@ TEST(RegisterKeysTest, RegisterAnyWithProxyRegion) {
cache.close();
}
+apache::geode::client::Cache createCache() {
+ return apache::geode::client::CacheFactory()
+ .set("log-level", "none")
+ .set("statistic-sampling-enabled", "false")
+ .create();
+}
+
+std::shared_ptr createPool(
+Cluster& cluster, apache::geode::client::Cache& cache) {
+ auto poolFactory = cache.getPoolManager().createFactory();
+ cluster.applyLocators(poolFactory);
+ poolFactory.setSubscriptionEnabled(true); // Per the customer.
+ return poolFactory.create("default");
+}
+
+std::shared_ptr setupRegion(
+apache::geode::client::Cache& cache,
+const std::shared_ptr& pool) {
+ auto region =
+ cache
+ .createRegionFactory(apache::geode::client::RegionShortcut::
+ CACHING_PROXY) // Per the customer.
+ .setPoolName(pool->getName())
+ .create("region");
+
+ return region;
+}
+
+TEST(RegisterKeysTest, DontReceiveValues) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+
+ cluster.start();
+
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("PARTITION")
+ .execute();
+
+ auto cache1 = createCache();
+ auto pool1 = createPool(cluster, cache1);
+ auto region1 = setupRegion(cache1, pool1);
+ auto attrMutator = region1->getAttributesMutator();
+
+ // put key/value pairs in the region using cache2
+
+ auto cache2 = createCache();
+ auto pool2 = createPool(cluster, cache2);
+ auto region2 = setupRegion(cache2, pool2);
+
+ const int NUMKEYS = 100;
+ for (int i = 0; i < NUMKEYS; i++) {
+region2->put(apache::geode::client::CacheableInt32::create(i),
+ apache::geode::client::CacheableInt32::create(i));
+ }
+
+ // register for all keys, but don't get any data
+
+ region1->registerAllKeys(false, false, false);
+
+ // verify we didn't get any data
+
+ for (int i = 0; i < NUMKEYS; i++) {
+auto hasKey =
+region1->containsKey(apache::geode::client::CacheableInt32::create(i));
+EXPECT_FALSE(hasKey);
+
+auto hasValue = region1->containsValueForKey(
+apache::geode::client::CacheableInt32::create(i));
+EXPECT_FALSE(hasValue);
+ }
+
+ // load cache1 with data
+
+ for (int i = 0; i < NUMKEYS; i++) {
+auto value =
region1->get(apache::geode::client::CacheableInt32::create(i));
+ }
+
+ // put new values in the region using cache2
+
+ for (int i = 0; i < NUMKEYS; i++) {
+region2->put(apache::geode::client::CacheableInt32::create(i),
+ apache::geode::client::CacheableInt32::create(i + 1000));
+ }
+
+ // wait for cache1 invalidates due to receiveValues=false, and verify
+
+ std::this_thread::sleep_for(5000ms);
+
+ for (int i = 0; i < NUMKEYS; i++) {
+auto hasKey =
+region1->containsKey(apache::geode::client::CacheableInt32::create(i));
+EXPECT_TRUE(hasKey);
+
+auto hasValue = region1->containsValueForKey(
+apache::geode::client::CacheableInt32::create(i));
+EXPECT_FALSE(hasValue);
+ }
+}
+
+TEST(RegisterKeysTest, ReceiveValuesLocalInvalidate) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+
+ cluster.start();
+
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("PARTITION")
+ .execute();
+
+ auto cache1 = createCache();
+ auto pool1 = createPool(cluster, cache1);
+ auto region1 = setupRegion(cache1, pool1);
+ auto attrMutator = region1->getAttributesMutator();
+
+ // put key/value pairs in the region using cache2
+
+ auto cache2 = createCache();
+ auto pool2 = createPool(cluster, cache2);
+ auto region2 = setupRegion(cache2, pool2);
+
+ const int NUMKEYS = 100;
+ for (int i = 0; i < NUMKEYS; i++) {
+region2->put(apache::geode::client::CacheableInt32::create(i),
+ apache::geode::client::CacheableInt32::create(i));
+ }
+
+ // register for all keys and get data now and future updates
+
+ region1->registerAllKeys(false, true, true);
+
+ // verify we now have data in cache1
+
+ for (int i = 0; i < NUMKEYS; i++) {
+auto hasKey =
+region1->containsKey(apache::geode::client::CacheableInt32::create(i));
+EXPECT_TRUE(hasKey);
+
+auto hasValue = region1->containsValueForKey(
+apache::geode::client::CacheableInt32::create(i));
+EXPECT_TRUE(hasValue);
+ }
+
+ // invalidate data in cache1
+
+ for (int i = 0; i < NUMKEYS; i++) {
+
[jira] [Commented] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[
https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17443173#comment-17443173
]
ASF GitHub Bot commented on GEODE-9804:
---
mmartell commented on a change in pull request #894:
URL: https://github.com/apache/geode-native/pull/894#discussion_r748755921
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -575,4 +581,257 @@ TEST(RegisterKeysTest, RegisterAnyWithProxyRegion) {
cache.close();
}
+apache::geode::client::Cache createCache() {
+ return apache::geode::client::CacheFactory()
+ .set("log-level", "none")
+ .set("statistic-sampling-enabled", "false")
+ .create();
+}
+
+std::shared_ptr createPool(
+Cluster& cluster, apache::geode::client::Cache& cache) {
+ auto poolFactory = cache.getPoolManager().createFactory();
+ cluster.applyLocators(poolFactory);
+ poolFactory.setSubscriptionEnabled(true); // Per the customer.
+ return poolFactory.create("default");
+}
+
+std::shared_ptr setupRegion(
+apache::geode::client::Cache& cache,
+const std::shared_ptr& pool) {
+ auto region =
+ cache
+ .createRegionFactory(apache::geode::client::RegionShortcut::
+ CACHING_PROXY) // Per the customer.
+ .setPoolName(pool->getName())
+ .create("region");
+
+ return region;
+}
+
+TEST(RegisterKeysTest, DontReceiveValues) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+
+ cluster.start();
+
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("PARTITION")
+ .execute();
+
+ auto cache1 = createCache();
+ auto pool1 = createPool(cluster, cache1);
+ auto region1 = setupRegion(cache1, pool1);
+ auto attrMutator = region1->getAttributesMutator();
+
+ // put key/value pairs in the region using cache2
Review comment:
I agree comments in general are a liability, just like code. They help
while debugging the test, but I'm OK removing now.
--
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
> Both registerAllKeys and registerRegex always fetch initial entries.
>
>
> Key: GEODE-9804
> URL: https://issues.apache.org/jira/browse/GEODE-9804
> Project: Geode
> Issue Type: Bug
>Reporter: Jacob Barrett
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> A inconsistency and bug in how the two regex interest methods configure the
> initial interest policy results in the both registerAllKeys and registerRegex
> fetching all initial entries despite the boolean parameter to get initial
> entries. Furthermore the misconfiguration results in none of the entries
> actually getting sent to the cache listener. The result is unnecessarily long
> registration times, network traffic and load on the servers. On servers with
> say millions of keys this can result in long GC pauses to unintentionally
> iterate over all those keys.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[
https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17443128#comment-17443128
]
ASF GitHub Bot commented on GEODE-9804:
---
pdxcodemonkey commented on a change in pull request #892:
URL: https://github.com/apache/geode-native/pull/892#discussion_r748733902
##
File path: cppcache/integration/benchmark/RegionBM.cpp
##
@@ -19,17 +19,16 @@
#include
#include
-// Disable warning for "extra qualifications" here. One of the boost log
-// headers triggers this warning. Note: use of disable pragma here is
-// intentional - attempts to use push/pop as you ordinarily should just
-// yielded a gripe from the MS tools that "warning number '4596' is not a
-// valid compiler warning". re-enabling the warning after the include
-// fails in the same way, so just leave it disabled for the rest of the
Review comment:
I take it from the change that this comment is no longer applicable?
Just double-checking
##
File path: cppcache/integration/benchmark/RegisterInterestBM.cpp
##
@@ -0,0 +1,162 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#include
+#include
+#include
+
+#ifdef _MSC_VER
+#pragma warning(push)
+#pragma warning(disable : 4596)
+#endif
+#include
+#include
+#include
+#ifdef _MSC_VER
+#pragma warning(pop)
+#endif
+
+#include
+#include
+#include
+#include
+#include
+
+namespace {
+
+using apache::geode::client::Cache;
+using apache::geode::client::CacheableString;
+using apache::geode::client::HashMapOfCacheable;
+using apache::geode::client::Region;
+using apache::geode::client::RegionShortcut;
+
+class RegisterInterestBM : public benchmark::Fixture {
+ public:
+ RegisterInterestBM() {
+boost::log::core::get()->set_filter(boost::log::trivial::severity >=
+boost::log::trivial::debug);
+
+BOOST_LOG_TRIVIAL(info) << "constructed";
+ }
+
+ ~RegisterInterestBM() noexcept override {
+BOOST_LOG_TRIVIAL(info) << "destructed";
+ }
+
+ using benchmark::Fixture::SetUp;
+ void SetUp(benchmark::State& state) override {
+BOOST_LOG_TRIVIAL(info) << "starting cluster";
+cluster = std::unique_ptr(
+new Cluster(::Name{name_}, LocatorCount{1}, ServerCount{4}));
+cluster->start();
+cluster->getGfsh()
+.create()
+.region()
+.withName("region")
+.withType("PARTITION")
+.execute();
+
+cache = std::unique_ptr(new Cache(cluster->createCache(
+{{"log-level", "finer"}}, Cluster::SubscriptionState::Enabled)));
+region = cache->createRegionFactory(RegionShortcut::PROXY)
+ .setPoolName("default")
+ .setCachingEnabled(true)
+ .create("region");
+
+BOOST_LOG_TRIVIAL(info)
+<< "filling region with " << state.range(0) << " keys";
+HashMapOfCacheable map;
+const auto batchSize = 1;
+map.reserve(batchSize);
+for (auto i = 0; i < state.range(0); ++i) {
+ map.emplace(
+ std::make_shared("key" + std::to_string(i)),
+ std::make_shared("value" + std::to_string(i)));
+ if (0 == i % batchSize) {
+region->putAll(map);
+map.clear();
+ }
+}
+if (!map.empty()) {
+ region->putAll(map);
+ map.clear();
+}
+BOOST_LOG_TRIVIAL(info) << "region ready";
+ }
+
+ using benchmark::Fixture::TearDown;
+ void TearDown(benchmark::State&) override {
+BOOST_LOG_TRIVIAL(info) << "stopping cluster";
+region = nullptr;
+cache = nullptr;
+cluster = nullptr;
+ }
+
+ protected:
+ void SetName(const char* name) {
+name_ = name;
+
+Benchmark::SetName(name);
+ }
+
+ void unregisterInterestAllKeys(benchmark::State& state) {
+state.PauseTiming();
+region->unregisterAllKeys();
+state.ResumeTiming();
+ }
+
+ std::unique_ptr cluster;
+ std::unique_ptr cache;
+ std::shared_ptr region;
+
+ private:
+ std::string name_;
+};
+
+BENCHMARK_DEFINE_F(RegisterInterestBM, registerInterestAllKeys)
+(benchmark::State& state) {
+ for (auto _ : state) {
+region->registerAllKeys();
+unregisterInterestAllKeys(state);
+ }
[jira] [Updated] (GEODE-9807) Gfsh stop gateway sender command in parallel
[ https://issues.apache.org/jira/browse/GEODE-9807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9807: -- Labels: pull-request-available (was: ) > Gfsh stop gateway sender command in parallel > > > Key: GEODE-9807 > URL: https://issues.apache.org/jira/browse/GEODE-9807 > Project: Geode > Issue Type: Improvement > Components: gfsh, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > Currently, the gfsh stop gateway sender command stops serially the gateway > sender on each server. > The higher the number of Geode servers in the system, the longer the command > will take. > This process can take very long specially in deployments with a lot of Geode > servers and this can be aggravated if the receiving side is not available > (connections to the remote site are timing out). > It is proposed to implement the stopping of gateway senders in gfsh in > parallel just as it is done by the start gateway sender gfsh command. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[
https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17442560#comment-17442560
]
ASF GitHub Bot commented on GEODE-9804:
---
pivotal-jbarrett commented on a change in pull request #894:
URL: https://github.com/apache/geode-native/pull/894#discussion_r747957402
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -575,4 +581,257 @@ TEST(RegisterKeysTest, RegisterAnyWithProxyRegion) {
cache.close();
}
+apache::geode::client::Cache createCache() {
+ return apache::geode::client::CacheFactory()
+ .set("log-level", "none")
+ .set("statistic-sampling-enabled", "false")
+ .create();
+}
+
+std::shared_ptr createPool(
+Cluster& cluster, apache::geode::client::Cache& cache) {
+ auto poolFactory = cache.getPoolManager().createFactory();
+ cluster.applyLocators(poolFactory);
+ poolFactory.setSubscriptionEnabled(true); // Per the customer.
+ return poolFactory.create("default");
+}
+
+std::shared_ptr setupRegion(
+apache::geode::client::Cache& cache,
+const std::shared_ptr& pool) {
+ auto region =
+ cache
+ .createRegionFactory(apache::geode::client::RegionShortcut::
+ CACHING_PROXY) // Per the customer.
+ .setPoolName(pool->getName())
+ .create("region");
+
+ return region;
+}
+
+TEST(RegisterKeysTest, DontReceiveValues) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+
+ cluster.start();
+
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("PARTITION")
+ .execute();
+
+ auto cache1 = createCache();
+ auto pool1 = createPool(cluster, cache1);
+ auto region1 = setupRegion(cache1, pool1);
+ auto attrMutator = region1->getAttributesMutator();
+
+ // put key/value pairs in the region using cache2
+
+ auto cache2 = createCache();
+ auto pool2 = createPool(cluster, cache2);
+ auto region2 = setupRegion(cache2, pool2);
+
+ const int NUMKEYS = 100;
+ for (int i = 0; i < NUMKEYS; i++) {
+region2->put(apache::geode::client::CacheableInt32::create(i),
+ apache::geode::client::CacheableInt32::create(i));
+ }
+
+ // register for all keys, but don't get any data
+
+ region1->registerAllKeys(false, false, false);
+
+ // verify we didn't get any data
+
+ for (int i = 0; i < NUMKEYS; i++) {
+auto hasKey =
+region1->containsKey(apache::geode::client::CacheableInt32::create(i));
+EXPECT_FALSE(hasKey);
+
+auto hasValue = region1->containsValueForKey(
+apache::geode::client::CacheableInt32::create(i));
+EXPECT_FALSE(hasValue);
+ }
+
+ // load cache1 with data
+
+ for (int i = 0; i < NUMKEYS; i++) {
+auto value =
region1->get(apache::geode::client::CacheableInt32::create(i));
+ }
+
+ // put new values in the region using cache2
+
+ for (int i = 0; i < NUMKEYS; i++) {
+region2->put(apache::geode::client::CacheableInt32::create(i),
+ apache::geode::client::CacheableInt32::create(i + 1000));
+ }
+
+ // wait for cache1 invalidates due to receiveValues=false, and verify
+
+ std::this_thread::sleep_for(5000ms);
+
+ for (int i = 0; i < NUMKEYS; i++) {
+auto hasKey =
+region1->containsKey(apache::geode::client::CacheableInt32::create(i));
+EXPECT_TRUE(hasKey);
+
+auto hasValue = region1->containsValueForKey(
+apache::geode::client::CacheableInt32::create(i));
+EXPECT_FALSE(hasValue);
+ }
+}
+
+TEST(RegisterKeysTest, ReceiveValuesLocalInvalidate) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+
+ cluster.start();
+
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("PARTITION")
+ .execute();
+
+ auto cache1 = createCache();
+ auto pool1 = createPool(cluster, cache1);
+ auto region1 = setupRegion(cache1, pool1);
+ auto attrMutator = region1->getAttributesMutator();
+
+ // put key/value pairs in the region using cache2
+
+ auto cache2 = createCache();
+ auto pool2 = createPool(cluster, cache2);
+ auto region2 = setupRegion(cache2, pool2);
+
+ const int NUMKEYS = 100;
+ for (int i = 0; i < NUMKEYS; i++) {
+region2->put(apache::geode::client::CacheableInt32::create(i),
+ apache::geode::client::CacheableInt32::create(i));
+ }
+
+ // register for all keys and get data now and future updates
+
+ region1->registerAllKeys(false, true, true);
+
+ // verify we now have data in cache1
+
+ for (int i = 0; i < NUMKEYS; i++) {
+auto hasKey =
+region1->containsKey(apache::geode::client::CacheableInt32::create(i));
+EXPECT_TRUE(hasKey);
+
+auto hasValue = region1->containsValueForKey(
+apache::geode::client::CacheableInt32::create(i));
+EXPECT_TRUE(hasValue);
+ }
+
+ // invalidate data in cache1
+
+ for (int i = 0; i < NUMKEYS; i++) {
+
[jira] [Commented] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[
https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17442559#comment-17442559
]
ASF GitHub Bot commented on GEODE-9804:
---
pivotal-jbarrett commented on a change in pull request #894:
URL: https://github.com/apache/geode-native/pull/894#discussion_r747955671
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -575,4 +581,257 @@ TEST(RegisterKeysTest, RegisterAnyWithProxyRegion) {
cache.close();
}
+apache::geode::client::Cache createCache() {
+ return apache::geode::client::CacheFactory()
+ .set("log-level", "none")
+ .set("statistic-sampling-enabled", "false")
+ .create();
+}
+
+std::shared_ptr createPool(
+Cluster& cluster, apache::geode::client::Cache& cache) {
+ auto poolFactory = cache.getPoolManager().createFactory();
+ cluster.applyLocators(poolFactory);
+ poolFactory.setSubscriptionEnabled(true); // Per the customer.
+ return poolFactory.create("default");
+}
+
+std::shared_ptr setupRegion(
+apache::geode::client::Cache& cache,
+const std::shared_ptr& pool) {
+ auto region =
+ cache
+ .createRegionFactory(apache::geode::client::RegionShortcut::
+ CACHING_PROXY) // Per the customer.
+ .setPoolName(pool->getName())
+ .create("region");
+
+ return region;
+}
+
+TEST(RegisterKeysTest, DontReceiveValues) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+
+ cluster.start();
+
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("PARTITION")
+ .execute();
+
+ auto cache1 = createCache();
+ auto pool1 = createPool(cluster, cache1);
+ auto region1 = setupRegion(cache1, pool1);
+ auto attrMutator = region1->getAttributesMutator();
+
+ // put key/value pairs in the region using cache2
Review comment:
If a block of code needs a comment it should be refactored to be
readable or extracted into a method with a descriptive name. This test is
getting pretty long.
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -575,4 +581,257 @@ TEST(RegisterKeysTest, RegisterAnyWithProxyRegion) {
cache.close();
}
+apache::geode::client::Cache createCache() {
+ return apache::geode::client::CacheFactory()
+ .set("log-level", "none")
+ .set("statistic-sampling-enabled", "false")
+ .create();
+}
+
+std::shared_ptr createPool(
+Cluster& cluster, apache::geode::client::Cache& cache) {
+ auto poolFactory = cache.getPoolManager().createFactory();
+ cluster.applyLocators(poolFactory);
+ poolFactory.setSubscriptionEnabled(true); // Per the customer.
+ return poolFactory.create("default");
+}
+
+std::shared_ptr setupRegion(
+apache::geode::client::Cache& cache,
+const std::shared_ptr& pool) {
+ auto region =
+ cache
+ .createRegionFactory(apache::geode::client::RegionShortcut::
+ CACHING_PROXY) // Per the customer.
+ .setPoolName(pool->getName())
+ .create("region");
+
+ return region;
+}
+
+TEST(RegisterKeysTest, DontReceiveValues) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+
+ cluster.start();
+
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("PARTITION")
+ .execute();
+
+ auto cache1 = createCache();
+ auto pool1 = createPool(cluster, cache1);
+ auto region1 = setupRegion(cache1, pool1);
+ auto attrMutator = region1->getAttributesMutator();
+
+ // put key/value pairs in the region using cache2
+
+ auto cache2 = createCache();
+ auto pool2 = createPool(cluster, cache2);
+ auto region2 = setupRegion(cache2, pool2);
+
+ const int NUMKEYS = 100;
+ for (int i = 0; i < NUMKEYS; i++) {
+region2->put(apache::geode::client::CacheableInt32::create(i),
+ apache::geode::client::CacheableInt32::create(i));
+ }
+
+ // register for all keys, but don't get any data
+
+ region1->registerAllKeys(false, false, false);
+
+ // verify we didn't get any data
+
+ for (int i = 0; i < NUMKEYS; i++) {
+auto hasKey =
+region1->containsKey(apache::geode::client::CacheableInt32::create(i));
+EXPECT_FALSE(hasKey);
+
+auto hasValue = region1->containsValueForKey(
+apache::geode::client::CacheableInt32::create(i));
+EXPECT_FALSE(hasValue);
+ }
+
+ // load cache1 with data
+
+ for (int i = 0; i < NUMKEYS; i++) {
+auto value =
region1->get(apache::geode::client::CacheableInt32::create(i));
+ }
+
+ // put new values in the region using cache2
+
+ for (int i = 0; i < NUMKEYS; i++) {
+region2->put(apache::geode::client::CacheableInt32::create(i),
+ apache::geode::client::CacheableInt32::create(i + 1000));
+ }
+
+ // wait for cache1 invalidates due to receiveValues=false, and verify
+
+ std::this_thread::sleep_for(5000ms);
+
+ for (int i =
[jira] [Updated] (GEODE-9806) Skip recovery of already recovered bucket
[ https://issues.apache.org/jira/browse/GEODE-9806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9806: -- Labels: pull-request-available (was: ) > Skip recovery of already recovered bucket > -- > > Key: GEODE-9806 > URL: https://issues.apache.org/jira/browse/GEODE-9806 > Project: Geode > Issue Type: Improvement > Components: persistence, regions >Affects Versions: 1.14.0 >Reporter: Mario Ivanac >Priority: Major > Labels: pull-request-available > > In case we are creating collocated region to persistent region, geode will > try to recover already recovered buckets. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[ https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17442446#comment-17442446 ] ASF GitHub Bot commented on GEODE-9804: --- mmartell closed pull request #893: URL: https://github.com/apache/geode-native/pull/893 -- 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 > Both registerAllKeys and registerRegex always fetch initial entries. > > > Key: GEODE-9804 > URL: https://issues.apache.org/jira/browse/GEODE-9804 > Project: Geode > Issue Type: Bug >Reporter: Jacob Barrett >Priority: Major > Labels: needsTriage, pull-request-available > > A inconsistency and bug in how the two regex interest methods configure the > initial interest policy results in the both registerAllKeys and registerRegex > fetching all initial entries despite the boolean parameter to get initial > entries. Furthermore the misconfiguration results in none of the entries > actually getting sent to the cache listener. The result is unnecessarily long > registration times, network traffic and load on the servers. On servers with > say millions of keys this can result in long GC pauses to unintentionally > iterate over all those keys. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[
https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17442409#comment-17442409
]
ASF GitHub Bot commented on GEODE-9804:
---
pivotal-jbarrett commented on a change in pull request #893:
URL: https://github.com/apache/geode-native/pull/893#discussion_r747751294
##
File path: cppcache/include/geode/DataInput.hpp
##
@@ -381,7 +381,7 @@ class APACHE_GEODE_EXPORT DataInput {
} else {
int8_t** tmpArray;
int32_t* tmpLengtharr;
- _GEODE_NEW(tmpArray, int8_t* [arrLen]);
+ _GEODE_NEW(tmpArray, int8_t * [arrLen]);
Review comment:
Unrelated incorrect format change.
##
File path: cppcache/include/geode/CacheableString.hpp
##
@@ -54,11 +54,11 @@ class APACHE_GEODE_EXPORT CacheableString
: m_str(std::move(value)), m_hashcode(0) {
bool ascii = isAscii(m_str);
-m_type = m_str.length() > (std::numeric_limits::max)()
- ? ascii ? DSCode::CacheableASCIIStringHuge
- : DSCode::CacheableStringHuge
- : ascii ? DSCode::CacheableASCIIString
- : DSCode::CacheableString;
+m_type =
Review comment:
Unrelated formatting change.
##
File path: cppcache/integration-test/testThinClientClearRegion.cpp
##
@@ -79,7 +80,30 @@ DUNIT_TASK(CLIENT1, SetupClient1)
auto wter = std::make_shared();
mtor->setCacheListener(lster);
mtor->setCacheWriter(wter);
-regPtr->registerAllKeys();
+// regPtr->registerAllKeys();
Review comment:
Commented out code needs to be deleted.
##
File path: cppcache/integration-test/testThinClientPdxTests.cpp
##
@@ -4435,12 +4435,14 @@ DUNIT_MAIN
// PDXReaderWriterInvalidUsage
{
- // disable see bug 999 for more details.
- // testReaderWriterInvalidUsage();
+// disable see bug 999 for more details.
Review comment:
Incorrect formatting changes.
##
File path: cppcache/integration-test/testThinClientSecurityPostAuthorization.cpp
##
@@ -89,9 +89,7 @@ void initClientAuth(char userType, int clientNum = 1) {
config->insert("security-password", "geode1");
break;
}
-default: {
- break;
-}
+default: { break; }
Review comment:
Incorrect formatting changes.
##
File path: cppcache/integration-test/testThinClientClearRegion.cpp
##
@@ -79,7 +80,30 @@ DUNIT_TASK(CLIENT1, SetupClient1)
auto wter = std::make_shared();
mtor->setCacheListener(lster);
mtor->setCacheWriter(wter);
-regPtr->registerAllKeys();
+// regPtr->registerAllKeys();
+
+//*** Mike
+int NUMKEYS = 500;
+int BLKSIZE = 500;
+// auto keyPtr = CacheableKey::create("key01");
+// auto valPtr = CacheableBytes::create(
+//std::vector{'v', 'a', 'l', 'u', 'e', '0', '1'});
+// for (int i = 0; i < NUMKEYS; i++) {
+// auto keyPtr = CacheableKey::create(i);
+// regPtr->put(keyPtr, valPtr);
+//}
+
+HashMapOfCacheable map0;
+map0.clear();
+auto valPtr = CacheableBytes::create(
Review comment:
This change appears unrelated to the issue being addressed. What is the
purpose of this modified legacy test?
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -575,4 +581,257 @@ TEST(RegisterKeysTest, RegisterAnyWithProxyRegion) {
cache.close();
}
+apache::geode::client::Cache createCache() {
+ return apache::geode::client::CacheFactory()
+ .set("log-level", "none")
+ .set("statistic-sampling-enabled", "false")
+ .create();
+}
+
+std::shared_ptr createPool(
+Cluster& cluster, apache::geode::client::Cache& cache) {
+ auto poolFactory = cache.getPoolManager().createFactory();
+ cluster.applyLocators(poolFactory);
+ poolFactory.setSubscriptionEnabled(true); // Per the customer.
+ return poolFactory.create("default");
+}
+
+std::shared_ptr setupRegion(
+apache::geode::client::Cache& cache,
+const std::shared_ptr& pool) {
+ auto region =
+ cache
+ .createRegionFactory(apache::geode::client::RegionShortcut::
+ CACHING_PROXY) // Per the customer.
+ .setPoolName(pool->getName())
+ .create("region");
+
+ return region;
+}
+
+TEST(RegisterKeysTest, DontReceiveValues) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+
+ cluster.start();
+
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("PARTITION")
+ .execute();
+
+ auto cache1 = createCache();
+ auto pool1 = createPool(cluster, cache1);
+ auto region1 = setupRegion(cache1, pool1);
+ auto attrMutator = region1->getAttributesMutator();
+
+ // put key/value pairs in the region using cache2
+
+ auto cache2 = createCache();
+ auto pool2 = createPool(cluster, cache2);
+ auto region2 = setupRegion(cache2, pool2);
[jira] [Commented] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[ https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17442376#comment-17442376 ] ASF GitHub Bot commented on GEODE-9804: --- mmartell opened a new pull request #893: URL: https://github.com/apache/geode-native/pull/893 Adds new integration tests for register interest and new unit tests for TcrMessage::registerInterest -- 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 > Both registerAllKeys and registerRegex always fetch initial entries. > > > Key: GEODE-9804 > URL: https://issues.apache.org/jira/browse/GEODE-9804 > Project: Geode > Issue Type: Bug >Reporter: Jacob Barrett >Priority: Major > Labels: needsTriage, pull-request-available > > A inconsistency and bug in how the two regex interest methods configure the > initial interest policy results in the both registerAllKeys and registerRegex > fetching all initial entries despite the boolean parameter to get initial > entries. Furthermore the misconfiguration results in none of the entries > actually getting sent to the cache listener. The result is unnecessarily long > registration times, network traffic and load on the servers. On servers with > say millions of keys this can result in long GC pauses to unintentionally > iterate over all those keys. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9323) Remove ACE references from tests/cpp
[ https://issues.apache.org/jira/browse/GEODE-9323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17442025#comment-17442025 ] ASF GitHub Bot commented on GEODE-9323: --- gaussianrecurrence commented on pull request #811: URL: https://github.com/apache/geode-native/pull/811#issuecomment-965902365 @pdxcodemonkey @pivotal-jbarrett @echobravopapa @mkevo @jvarenina @mivanac @albertogpz Finally got some time to dedicate on ACE removal PR's so feel free to review them as they are marked as ready for review, like this one :) -- 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 > Remove ACE references from tests/cpp > > > Key: GEODE-9323 > URL: https://issues.apache.org/jira/browse/GEODE-9323 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: obliterate-ace, pull-request-available > > *AS A* native client contributor > *I WANT TO* remove all remaining references to ACE in tests/cpp projects > *SO THAT* eventually we can get rid of ACE library > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9772) RedisString should consistently use a DeltaInfo for all write ops that update a RedisString
[ https://issues.apache.org/jira/browse/GEODE-9772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9772: -- Labels: pull-request-available (was: ) > RedisString should consistently use a DeltaInfo for all write ops that update > a RedisString > --- > > Key: GEODE-9772 > URL: https://issues.apache.org/jira/browse/GEODE-9772 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > > Currently RedisString generates a DeltaInfo instance when it does an "append" > to an existing RedisString. But for all the other write ops on RedisString > the implementation does not generate a DeltaInfo instance. This causes the > entire RedisString instance to be serialized to the secondary. But the ops > that do this tend to change the entire string (for example "set" get rid of > the old value of the string and adds a brand new value). But even for these > types of ops being consistent about generating a DeltaInfo has the following > benefits: > 1. the memory usage on the region will be consistent between the primary and > secondary because the value will be stored in the same form on both of them. > Understand that for value classes that implement the Delta interface (which > all RedisData classes do) the primary will always store the value in > deserialized form. But it gets stored on the secondary in serialized from > until a value arrives on the secondary that is just the delta bytes. By > generating a DeltaInfo instance the secondary will receive data bytes. > 2. By keeping the values stored in the region in object form it causes > updates to not produce "old garbage". What happens when a DeltaInfo is sent > is that it modifies in place an object that is already in the JVM heap > memory. But without a DeltaInfo a whole new value is created and the old > value becomes garbage. That old value may have already been promoted to the > older generation and now the JVM may have to do more work to get it garbage > collected. It is best if object die young (sad but true). > RedisString has a number of ops that do not use generate a DeltaInfo. But > they could easily be changed to just generate a DeltaInfo that contains a > byte array that is the new value of the RedisString. This would even work for > "setrange" and "setbit" but those could be further optimized to only add a > subset of the bytes to the DeltaInfo along with an index. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9769) add pubsub stats to geode-for-redis INFO command
[ https://issues.apache.org/jira/browse/GEODE-9769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9769: -- Labels: pull-request-available (was: ) > add pubsub stats to geode-for-redis INFO command > > > Key: GEODE-9769 > URL: https://issues.apache.org/jira/browse/GEODE-9769 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > > Standard redis has the following on the INFO command: > pubsub_channels: Global number of pub/sub channels with client subscriptions > pubsub_patterns: Global number of pub/sub pattern with client subscriptions > geode-for-redis has some stats that correspond to these but the stats are > only available from geode's existing stat tools. The two geode stats that > correspond to these are: uniqueChannelSubscriptions and > uniquePatternSubscriptions -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9675) CI: ClusterDistributionManagerDUnitTest > testConnectAfterBeingShunned FAILED
[
https://issues.apache.org/jira/browse/GEODE-9675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9675:
--
Labels: pull-request-available (was: )
> CI: ClusterDistributionManagerDUnitTest > testConnectAfterBeingShunned FAILED
> -
>
> Key: GEODE-9675
> URL: https://issues.apache.org/jira/browse/GEODE-9675
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.15.0
>Reporter: Xiaojian Zhou
>Priority: Major
> Labels: pull-request-available
> Attachments: screenshot-1.png
>
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1983
> {code:java}
> ClusterDistributionManagerDUnitTest > testConnectAfterBeingShunned FAILED
> org.apache.geode.SystemConnectException: Problem starting up membership
> services
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:186)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:466)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:499)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:328)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:757)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:133)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3013)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:283)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:209)
> at
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:159)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.getSystem(JUnit4DistributedTestCase.java:180)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.getSystem(JUnit4DistributedTestCase.java:256)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManagerDUnitTest.testConnectAfterBeingShunned(ClusterDistributionManagerDUnitTest.java:170)
> Caused by:
>
> org.apache.geode.distributed.internal.membership.api.MemberStartupException:
> unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.start(JGroupsMessenger.java:401)
> at
> org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:203)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.start(GMSMembership.java:1642)
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:171)
> ... 13 more
> Caused by:
> java.lang.Exception: failed to open a port in range 41003-41003
> at
> org.jgroups.protocols.UDP.createMulticastSocketWithBindPort(UDP.java:503)
> at org.jgroups.protocols.UDP.createSockets(UDP.java:348)
> at org.jgroups.protocols.UDP.start(UDP.java:266)
> at
> org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966)
> at org.jgroups.JChannel.startStack(JChannel.java:889)
> at org.jgroups.JChannel._preConnect(JChannel.java:553)
> at org.jgroups.JChannel.connect(JChannel.java:288)
> at org.jgroups.JChannel.connect(JChannel.java:279)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.start(JGroupsMessenger.java:397)
> ... 16 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9805) Debug logging of Radish AUTH command in ExecutionHandlerContext.executeCommand() reveals sensitive information
[ https://issues.apache.org/jira/browse/GEODE-9805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9805: -- Labels: blocks-1.15.0 pull-request-available (was: blocks-1.15.0) > Debug logging of Radish AUTH command in > ExecutionHandlerContext.executeCommand() reveals sensitive information > -- > > Key: GEODE-9805 > URL: https://issues.apache.org/jira/browse/GEODE-9805 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: blocks-1.15.0, pull-request-available > > With debug logging enabled, the ExecutionHandlerContext.executeCommand() > method logs every command executed along with its arguments. In the case of > the AUTH command, this results in un-redacted userId and/or password being > logged, which represents a serious security issue. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9747) CI failure: PersistentPartitionedRegionDistributedTest sees wrong kind of exception
[
https://issues.apache.org/jira/browse/GEODE-9747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9747:
--
Labels: GeodeOperationAPI needsTriage pull-request-available (was:
GeodeOperationAPI needsTriage)
> CI failure: PersistentPartitionedRegionDistributedTest sees wrong kind of
> exception
> ---
>
> Key: GEODE-9747
> URL: https://issues.apache.org/jira/browse/GEODE-9747
> Project: Geode
> Issue Type: Bug
> Components: core, tests
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage, pull-request-available
>
> May be the same issue as GEODE-7030 but it's hard to tell since that other
> ticket is short on details.
> {noformat}
> PersistentPartitionedRegionDistributedTest >
> cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionDistributedTest$$Lambda$331/778323733.run
> in VM 0 running on Host
> heavy-lifter-2597c5be-686f-56ce-ab29-4c643f8174ba.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at
> org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionDistributedTest.cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown(PersistentPartitionedRegionDistributedTest.java:1129)
> Caused by:
> org.opentest4j.AssertionFailedError:
> Expecting value to be true but was false
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionDistributedTest.lambda$cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown$bb17a952$4(PersistentPartitionedRegionDistributedTest.java:1136)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[ https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9804: -- Labels: needsTriage pull-request-available (was: needsTriage) > Both registerAllKeys and registerRegex always fetch initial entries. > > > Key: GEODE-9804 > URL: https://issues.apache.org/jira/browse/GEODE-9804 > Project: Geode > Issue Type: Bug >Reporter: Jacob Barrett >Priority: Major > Labels: needsTriage, pull-request-available > > A inconsistency and bug in how the two regex interest methods configure the > initial interest policy results in the both registerAllKeys and registerRegex > fetching all initial entries despite the boolean parameter to get initial > entries. Furthermore the misconfiguration results in none of the entries > actually getting sent to the cache listener. The result is unnecessarily long > registration times, network traffic and load on the servers. On servers with > say millions of keys this can result in long GC pauses to unintentionally > iterate over all those keys. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[ https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17440746#comment-17440746 ] ASF GitHub Bot commented on GEODE-9804: --- pivotal-jbarrett opened a new pull request #892: URL: https://github.com/apache/geode-native/pull/892 * Makes InterestResultPolicy a proper enum. * Adds integration benchmark for register interest. * Cleanup methods unused arguments. -- 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 > Both registerAllKeys and registerRegex always fetch initial entries. > > > Key: GEODE-9804 > URL: https://issues.apache.org/jira/browse/GEODE-9804 > Project: Geode > Issue Type: Bug >Reporter: Jacob Barrett >Priority: Major > Labels: needsTriage > > A inconsistency and bug in how the two regex interest methods configure the > initial interest policy results in the both registerAllKeys and registerRegex > fetching all initial entries despite the boolean parameter to get initial > entries. Furthermore the misconfiguration results in none of the entries > actually getting sent to the cache listener. The result is unnecessarily long > registration times, network traffic and load on the servers. On servers with > say millions of keys this can result in long GC pauses to unintentionally > iterate over all those keys. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9802) LoggingWithReconnectDistributedTest uses ephemeral port to create servers, leading to occasional failures with java.net.BindException: Address already in use
[
https://issues.apache.org/jira/browse/GEODE-9802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9802:
--
Labels: flaky pull-request-available (was: flaky)
> LoggingWithReconnectDistributedTest uses ephemeral port to create servers,
> leading to occasional failures with java.net.BindException: Address already
> in use
> -
>
> Key: GEODE-9802
> URL: https://issues.apache.org/jira/browse/GEODE-9802
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: flaky, pull-request-available
>
> Seen originally in distributed mass test run:
> {noformat}
> > Task :geode-core:distributedTest
> LoggingWithReconnectDistributedTest > logFileContainsBannerOnlyOnce FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.logging.internal.LoggingWithReconnectDistributedTest$$Lambda$547/1860776670.run
> in VM -1 running on Host
> heavy-lifter-e58d94dc-0688-534f-8361-75ac377b5300.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at
> org.apache.geode.logging.internal.LoggingWithReconnectDistributedTest.logFileContainsBannerOnlyOnce(LoggingWithReconnectDistributedTest.java:141)
> Caused by:
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Reconnect attempts terminated due to exception, caused by
> org.apache.geode.GemFireIOException: While starting cache server CacheServer
> on port=46103 client subscription config policy=none client subscription
> config capacity=1 client subscription config overflow directory=.
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.waitUntilReconnected(InternalDistributedSystem.java:2916)
> at
> org.apache.geode.logging.internal.LoggingWithReconnectDistributedTest.lambda$logFileContainsBannerOnlyOnce$bb17a952$2(LoggingWithReconnectDistributedTest.java:147)
> 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
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:628)
> ... 2 more
> Caused by:
> org.apache.geode.GemFireIOException: While starting cache server
> CacheServer on port=46103 client subscription config policy=none client
> subscription config capacity=1 client subscription config overflow directory=.
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.createAndStartCacheServers(InternalDistributedSystem.java:2773)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2653)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2408)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1254)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:2329)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.uncleanShutdown(GMSMembership.java:1190)
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.lambda$uncleanShutdownDS$0(GMSMembership.java:1794)
> at java.lang.Thread.run(Thread.java:748)
> Caused by:
> java.net.BindException: Failed to create server socket on
> 10.0.0.107[46103]
> 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.internal.net.SocketCreator.createServerSocket(SocketCreator.java:524)
> at
>
[jira] [Updated] (GEODE-9517) Update all tests to use org.assertj.core.api.Assertions
[ https://issues.apache.org/jira/browse/GEODE-9517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9517: -- Labels: pull-request-available (was: ) > Update all tests to use org.assertj.core.api.Assertions > --- > > Key: GEODE-9517 > URL: https://issues.apache.org/jira/browse/GEODE-9517 > Project: Geode > Issue Type: Bug >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: pull-request-available > > Refactor all tests to use org.assertj.core.api.Assertions instead of all the > deprecated alternatives like assertTrue etc. > > This ticket will remain open till all the tests are refactored. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9291) Develop Benchmarking Tests for Leaderboard API
[
https://issues.apache.org/jira/browse/GEODE-9291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17439492#comment-17439492
]
ASF GitHub Bot commented on GEODE-9291:
---
ezoerner commented on a change in pull request #160:
URL: https://github.com/apache/geode-benchmarks/pull/160#discussion_r743258356
##
File path:
geode-benchmarks/src/main/java/org/apache/geode/benchmark/redis/tasks/ZaddAndZremRedisTask.java
##
@@ -0,0 +1,72 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.geode.benchmark.redis.tasks;
+
+
+import static org.apache.geode.benchmark.redis.tasks.RedisSplitKey.toKey;
+import static org.apache.geode.benchmark.redis.tasks.RedisSplitKey.toPart;
+
+import java.io.Serializable;
+import java.util.Map;
+
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+import org.yardstickframework.BenchmarkConfiguration;
+import org.yardstickframework.BenchmarkDriverAdapter;
+
+import org.apache.geode.benchmark.LongRange;
+
+public class ZaddAndZremRedisTask extends BenchmarkDriverAdapter implements
Serializable {
+ private static final Logger logger =
LoggerFactory.getLogger(ZaddAndZremRedisTask.class);
+
+ private final RedisClientManager redisClientManager;
+ private final LongRange keyRange;
+
+ private transient LongStringCache keyCache;
+ private transient RedisClient redisClient;
+
+ public ZaddAndZremRedisTask(final RedisClientManager redisClientManager,
+ final LongRange keyRange) {
+logger.info("Initialized: keyRange={}", keyRange);
+this.redisClientManager = redisClientManager;
+this.keyRange = keyRange;
+ }
+
+ @Override
+ public void setUp(final BenchmarkConfiguration cfg) throws Exception {
+super.setUp(cfg);
+
+keyCache = new LongStringCache(keyRange);
+redisClient = redisClientManager.get();
+ }
+
+ private static String NEXT_KEY = "N";
+
+ @Override
+ public boolean test(final Map ctx) throws Exception {
+final long k = keyRange.random();
+
+final String key = keyCache.valueOf(toKey(k));
+final long score = toPart(k);
+final String value = keyCache.valueOf(score);
+redisClient.zadd(key, score, value);
+redisClient.zrem(key, value);
Review comment:
> Have you considered adding a random key and then removing a random
key?
This is what is actually happening. A random long is being fetched from the
entire key range, but that long is then broken apart using `toKey` and `toPart`
to get a top-level key and a value which is the value that goes into the sorted
set itself. The `RedisSplitKey` class used to be named `RedisHash` because it
was used for hashes to split the long value into a top-level key and a
hash-key. I re-used this code for sorted sets. I renamed it to "split key" so
that it wasn't specific to hashes but can be used for any kind of container
data type that contains values. It essentially splits a random long value into
a key and a sub-part. I struggled a little bit to find a good name for this
that would be self-evident without requiring a bunch of extra comments in the
code, but maybe more explanation about is going on here in code comments would
help(?)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Develop Benchmarking Tests for Leaderboard API
> --
>
> Key: GEODE-9291
> URL: https://issues.apache.org/jira/browse/GEODE-9291
> Project: Geode
> Issue Type: Test
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Wayne
>Assignee: Eric Zoerner
>Priority: Major
> Labels: pull-request-available, redis
> Fix For: 1.15.0
>
>
> Develop a suite of benchmarking tests for the Leaderboard API that benchmark
> the comparison between native Redis and the compatibility with Redis layer.
[jira] [Commented] (GEODE-9753) Coredump during PdxSerializable object serialization
[ https://issues.apache.org/jira/browse/GEODE-9753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17439491#comment-17439491 ] ASF GitHub Bot commented on GEODE-9753: --- gaussianrecurrence opened a new pull request #891: URL: https://github.com/apache/geode-native/pull/891 - While serializing a PdxSerializable object, there is a possible race condition which might cause the client to crash. This race-condition happens whenever the cluster is restarted during the serialization process and if on-client-disconnect-clear-pdxType-Ids is set to true, meaning the PdxTypeRegistry will be cleaned up if the connection towards the cluster is lost. - This issue has been solved by using the previously fetched local PDX type. - In order to properly test this solution, PdxRemoteWriterFactory has been added, so the race-condition can be force at test-time. - A new IT has been added to test that the solution is working fine. - make_unique was needed inside cppcache/src, so it was moved to utils/cxx_extensions.hpp - Also in order to ease the use of newer C++ standard a preprocessor check was added to make_unique, so if the used standard >= C++14, the standard implementation of make_unique will be used instead. -- 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 > Coredump during PdxSerializable object serialization > > > Key: GEODE-9753 > URL: https://issues.apache.org/jira/browse/GEODE-9753 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: needsTriage, pull-request-available > > *GIVEN* **a single server and locator cluster with 1 PdxSerializable class > registered, named Order > *AND* a geode-native client with 1 PdxSerializable 1 PdxSerializable class > registered, named Order > *WHEN* a Order object is tried to be serialized > *WHILE* the cluster is being restarted > *THEN* a coredump happens due to PdxType=nullptr > — > *Additional information*. As seen by early troubleshooting, the coredump > happens because the pdx type is tried to be fetched from the PdxTypeRegist by > its class name, but the PdxTypeRegistry is cleaned up during serialization > given that subscription redundancy was lost. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9291) Develop Benchmarking Tests for Leaderboard API
[
https://issues.apache.org/jira/browse/GEODE-9291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17439487#comment-17439487
]
ASF GitHub Bot commented on GEODE-9291:
---
nonbinaryprogrammer commented on a change in pull request #160:
URL: https://github.com/apache/geode-benchmarks/pull/160#discussion_r743246628
##
File path:
geode-benchmarks/src/main/java/org/apache/geode/benchmark/redis/tasks/ZaddAndZremRedisTask.java
##
@@ -0,0 +1,72 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.geode.benchmark.redis.tasks;
+
+
+import static org.apache.geode.benchmark.redis.tasks.RedisSplitKey.toKey;
+import static org.apache.geode.benchmark.redis.tasks.RedisSplitKey.toPart;
+
+import java.io.Serializable;
+import java.util.Map;
+
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+import org.yardstickframework.BenchmarkConfiguration;
+import org.yardstickframework.BenchmarkDriverAdapter;
+
+import org.apache.geode.benchmark.LongRange;
+
+public class ZaddAndZremRedisTask extends BenchmarkDriverAdapter implements
Serializable {
+ private static final Logger logger =
LoggerFactory.getLogger(ZaddAndZremRedisTask.class);
+
+ private final RedisClientManager redisClientManager;
+ private final LongRange keyRange;
+
+ private transient LongStringCache keyCache;
+ private transient RedisClient redisClient;
+
+ public ZaddAndZremRedisTask(final RedisClientManager redisClientManager,
+ final LongRange keyRange) {
+logger.info("Initialized: keyRange={}", keyRange);
+this.redisClientManager = redisClientManager;
+this.keyRange = keyRange;
+ }
+
+ @Override
+ public void setUp(final BenchmarkConfiguration cfg) throws Exception {
+super.setUp(cfg);
+
+keyCache = new LongStringCache(keyRange);
+redisClient = redisClientManager.get();
+ }
+
+ private static String NEXT_KEY = "N";
+
+ @Override
+ public boolean test(final Map ctx) throws Exception {
+final long k = keyRange.random();
+
+final String key = keyCache.valueOf(toKey(k));
+final long score = toPart(k);
+final String value = keyCache.valueOf(score);
+redisClient.zadd(key, score, value);
+redisClient.zrem(key, value);
Review comment:
I'm not a huge fan of creating a sorted set then turning around and
deleting that same sorted set. Have you considered adding a random key and then
removing a random key? There are definitely some potential issues there (ie
always getting unlucky and removing a key that doesn't exist, resulting in more
creates than deletes, or conversely getting unlucky when adding a sorted set
and colliding with one that exists already, causing more removes than adds), I
just want to make sure that this is the best test that we can do given these
issues.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Develop Benchmarking Tests for Leaderboard API
> --
>
> Key: GEODE-9291
> URL: https://issues.apache.org/jira/browse/GEODE-9291
> Project: Geode
> Issue Type: Test
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Wayne
>Assignee: Eric Zoerner
>Priority: Major
> Labels: pull-request-available, redis
> Fix For: 1.15.0
>
>
> Develop a suite of benchmarking tests for the Leaderboard API that benchmark
> the comparison between native Redis and the compatibility with Redis layer.
> +Acceptance Criteria+
> A benchmark should be developed that provides acceptable coverage (TBD) of
> the Leaderboard API that allows us to monitor the performance over time and
> compared to native Redis.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9291) Develop Benchmarking Tests for Leaderboard API
[ https://issues.apache.org/jira/browse/GEODE-9291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17439480#comment-17439480 ] ASF GitHub Bot commented on GEODE-9291: --- DonalEvans merged pull request #160: URL: https://github.com/apache/geode-benchmarks/pull/160 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Develop Benchmarking Tests for Leaderboard API > -- > > Key: GEODE-9291 > URL: https://issues.apache.org/jira/browse/GEODE-9291 > Project: Geode > Issue Type: Test > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Assignee: Eric Zoerner >Priority: Major > Labels: pull-request-available, redis > Fix For: 1.15.0 > > > Develop a suite of benchmarking tests for the Leaderboard API that benchmark > the comparison between native Redis and the compatibility with Redis layer. > +Acceptance Criteria+ > A benchmark should be developed that provides acceptable coverage (TBD) of > the Leaderboard API that allows us to monitor the performance over time and > compared to native Redis. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9291) Develop Benchmarking Tests for Leaderboard API
[
https://issues.apache.org/jira/browse/GEODE-9291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17439453#comment-17439453
]
ASF GitHub Bot commented on GEODE-9291:
---
ezoerner commented on a change in pull request #160:
URL: https://github.com/apache/geode-benchmarks/pull/160#discussion_r743258356
##
File path:
geode-benchmarks/src/main/java/org/apache/geode/benchmark/redis/tasks/ZaddAndZremRedisTask.java
##
@@ -0,0 +1,72 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.geode.benchmark.redis.tasks;
+
+
+import static org.apache.geode.benchmark.redis.tasks.RedisSplitKey.toKey;
+import static org.apache.geode.benchmark.redis.tasks.RedisSplitKey.toPart;
+
+import java.io.Serializable;
+import java.util.Map;
+
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+import org.yardstickframework.BenchmarkConfiguration;
+import org.yardstickframework.BenchmarkDriverAdapter;
+
+import org.apache.geode.benchmark.LongRange;
+
+public class ZaddAndZremRedisTask extends BenchmarkDriverAdapter implements
Serializable {
+ private static final Logger logger =
LoggerFactory.getLogger(ZaddAndZremRedisTask.class);
+
+ private final RedisClientManager redisClientManager;
+ private final LongRange keyRange;
+
+ private transient LongStringCache keyCache;
+ private transient RedisClient redisClient;
+
+ public ZaddAndZremRedisTask(final RedisClientManager redisClientManager,
+ final LongRange keyRange) {
+logger.info("Initialized: keyRange={}", keyRange);
+this.redisClientManager = redisClientManager;
+this.keyRange = keyRange;
+ }
+
+ @Override
+ public void setUp(final BenchmarkConfiguration cfg) throws Exception {
+super.setUp(cfg);
+
+keyCache = new LongStringCache(keyRange);
+redisClient = redisClientManager.get();
+ }
+
+ private static String NEXT_KEY = "N";
+
+ @Override
+ public boolean test(final Map ctx) throws Exception {
+final long k = keyRange.random();
+
+final String key = keyCache.valueOf(toKey(k));
+final long score = toPart(k);
+final String value = keyCache.valueOf(score);
+redisClient.zadd(key, score, value);
+redisClient.zrem(key, value);
Review comment:
> Have you considered adding a random key and then removing a random
key?
This is what is actually happening. A random long is being fetched from the
entire key range, but that long is then broken apart using `toKey` and `toPart`
to get a top-level key and a value which is the value that goes into the sorted
set itself. The `RedisSplitKey` class used to be named `RedisHash` because it
was used for hashes to split the long value into a top-level key and a
hash-key. I re-used this code for sorted sets. I renamed it to "split key" so
that it wasn't specific to hashes but can be used for any kind of container
data type that contains values. It essentially splits a random long value into
a key and a sub-part. I struggled a little bit to find a good name for this
that would be self-evident without requiring a bunch of extra comments in the
code, but maybe more explanation about is going on here in code comments would
help(?)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Develop Benchmarking Tests for Leaderboard API
> --
>
> Key: GEODE-9291
> URL: https://issues.apache.org/jira/browse/GEODE-9291
> Project: Geode
> Issue Type: Test
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Wayne
>Assignee: Eric Zoerner
>Priority: Major
> Labels: pull-request-available, redis
> Fix For: 1.15.0
>
>
> Develop a suite of benchmarking tests for the Leaderboard API that benchmark
> the comparison between native Redis and the compatibility with Redis layer.
[jira] [Commented] (GEODE-9753) Coredump during PdxSerializable object serialization
[ https://issues.apache.org/jira/browse/GEODE-9753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17439451#comment-17439451 ] ASF GitHub Bot commented on GEODE-9753: --- gaussianrecurrence opened a new pull request #891: URL: https://github.com/apache/geode-native/pull/891 - While serializing a PdxSerializable object, there is a possible race condition which might cause the client to crash. This race-condition happens whenever the cluster is restarted during the serialization process and if on-client-disconnect-clear-pdxType-Ids is set to true, meaning the PdxTypeRegistry will be cleaned up if the connection towards the cluster is lost. - This issue has been solved by using the previously fetched local PDX type. - In order to properly test this solution, PdxRemoteWriterFactory has been added, so the race-condition can be force at test-time. - A new IT has been added to test that the solution is working fine. - make_unique was needed inside cppcache/src, so it was moved to utils/cxx_extensions.hpp - Also in order to ease the use of newer C++ standard a preprocessor check was added to make_unique, so if the used standard >= C++14, the standard implementation of make_unique will be used instead. -- 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 > Coredump during PdxSerializable object serialization > > > Key: GEODE-9753 > URL: https://issues.apache.org/jira/browse/GEODE-9753 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: needsTriage, pull-request-available > > *GIVEN* **a single server and locator cluster with 1 PdxSerializable class > registered, named Order > *AND* a geode-native client with 1 PdxSerializable 1 PdxSerializable class > registered, named Order > *WHEN* a Order object is tried to be serialized > *WHILE* the cluster is being restarted > *THEN* a coredump happens due to PdxType=nullptr > — > *Additional information*. As seen by early troubleshooting, the coredump > happens because the pdx type is tried to be fetched from the PdxTypeRegist by > its class name, but the PdxTypeRegistry is cleaned up during serialization > given that subscription redundancy was lost. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9291) Develop Benchmarking Tests for Leaderboard API
[
https://issues.apache.org/jira/browse/GEODE-9291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17439447#comment-17439447
]
ASF GitHub Bot commented on GEODE-9291:
---
nonbinaryprogrammer commented on a change in pull request #160:
URL: https://github.com/apache/geode-benchmarks/pull/160#discussion_r743246628
##
File path:
geode-benchmarks/src/main/java/org/apache/geode/benchmark/redis/tasks/ZaddAndZremRedisTask.java
##
@@ -0,0 +1,72 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.geode.benchmark.redis.tasks;
+
+
+import static org.apache.geode.benchmark.redis.tasks.RedisSplitKey.toKey;
+import static org.apache.geode.benchmark.redis.tasks.RedisSplitKey.toPart;
+
+import java.io.Serializable;
+import java.util.Map;
+
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+import org.yardstickframework.BenchmarkConfiguration;
+import org.yardstickframework.BenchmarkDriverAdapter;
+
+import org.apache.geode.benchmark.LongRange;
+
+public class ZaddAndZremRedisTask extends BenchmarkDriverAdapter implements
Serializable {
+ private static final Logger logger =
LoggerFactory.getLogger(ZaddAndZremRedisTask.class);
+
+ private final RedisClientManager redisClientManager;
+ private final LongRange keyRange;
+
+ private transient LongStringCache keyCache;
+ private transient RedisClient redisClient;
+
+ public ZaddAndZremRedisTask(final RedisClientManager redisClientManager,
+ final LongRange keyRange) {
+logger.info("Initialized: keyRange={}", keyRange);
+this.redisClientManager = redisClientManager;
+this.keyRange = keyRange;
+ }
+
+ @Override
+ public void setUp(final BenchmarkConfiguration cfg) throws Exception {
+super.setUp(cfg);
+
+keyCache = new LongStringCache(keyRange);
+redisClient = redisClientManager.get();
+ }
+
+ private static String NEXT_KEY = "N";
+
+ @Override
+ public boolean test(final Map ctx) throws Exception {
+final long k = keyRange.random();
+
+final String key = keyCache.valueOf(toKey(k));
+final long score = toPart(k);
+final String value = keyCache.valueOf(score);
+redisClient.zadd(key, score, value);
+redisClient.zrem(key, value);
Review comment:
I'm not a huge fan of creating a sorted set then turning around and
deleting that same sorted set. Have you considered adding a random key and then
removing a random key? There are definitely some potential issues there (ie
always getting unlucky and removing a key that doesn't exist, resulting in more
creates than deletes, or conversely getting unlucky when adding a sorted set
and colliding with one that exists already, causing more removes than adds), I
just want to make sure that this is the best test that we can do given these
issues.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Develop Benchmarking Tests for Leaderboard API
> --
>
> Key: GEODE-9291
> URL: https://issues.apache.org/jira/browse/GEODE-9291
> Project: Geode
> Issue Type: Test
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Wayne
>Assignee: Eric Zoerner
>Priority: Major
> Labels: pull-request-available, redis
> Fix For: 1.15.0
>
>
> Develop a suite of benchmarking tests for the Leaderboard API that benchmark
> the comparison between native Redis and the compatibility with Redis layer.
> +Acceptance Criteria+
> A benchmark should be developed that provides acceptable coverage (TBD) of
> the Leaderboard API that allows us to monitor the performance over time and
> compared to native Redis.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9291) Develop Benchmarking Tests for Leaderboard API
[ https://issues.apache.org/jira/browse/GEODE-9291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17439442#comment-17439442 ] ASF GitHub Bot commented on GEODE-9291: --- DonalEvans merged pull request #160: URL: https://github.com/apache/geode-benchmarks/pull/160 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Develop Benchmarking Tests for Leaderboard API > -- > > Key: GEODE-9291 > URL: https://issues.apache.org/jira/browse/GEODE-9291 > Project: Geode > Issue Type: Test > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Assignee: Eric Zoerner >Priority: Major > Labels: pull-request-available, redis > Fix For: 1.15.0 > > > Develop a suite of benchmarking tests for the Leaderboard API that benchmark > the comparison between native Redis and the compatibility with Redis layer. > +Acceptance Criteria+ > A benchmark should be developed that provides acceptable coverage (TBD) of > the Leaderboard API that allows us to monitor the performance over time and > compared to native Redis. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9797) User guide typo repairs
[ https://issues.apache.org/jira/browse/GEODE-9797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9797: -- Labels: needsTriage pull-request-available (was: needsTriage) > User guide typo repairs > --- > > Key: GEODE-9797 > URL: https://issues.apache.org/jira/browse/GEODE-9797 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.12.5, 1.13.4, 1.14.0 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Minor > Labels: needsTriage, pull-request-available > > An eagle-eyed community member reports the following typographical errors: > http://geode.apache.org/docs/guide/114/managing/security/authentication_examples.html > Paragraph 3: "intialization" should be "initialization" > http://geode.apache.org/docs/guide/114/managing/security/implementing_authentication.html > Paragraph 6 (or so): "in the clear" should be "in cleartext" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9291) Develop Benchmarking Tests for Leaderboard API
[ https://issues.apache.org/jira/browse/GEODE-9291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17439322#comment-17439322 ] ASF GitHub Bot commented on GEODE-9291: --- DonalEvans merged pull request #160: URL: https://github.com/apache/geode-benchmarks/pull/160 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Develop Benchmarking Tests for Leaderboard API > -- > > Key: GEODE-9291 > URL: https://issues.apache.org/jira/browse/GEODE-9291 > Project: Geode > Issue Type: Test > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Assignee: Eric Zoerner >Priority: Major > Labels: pull-request-available, redis > > Develop a suite of benchmarking tests for the Leaderboard API that benchmark > the comparison between native Redis and the compatibility with Redis layer. > +Acceptance Criteria+ > A benchmark should be developed that provides acceptable coverage (TBD) of > the Leaderboard API that allows us to monitor the performance over time and > compared to native Redis. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9753) Coredump during PdxSerializable object serialization
[ https://issues.apache.org/jira/browse/GEODE-9753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17439191#comment-17439191 ] ASF GitHub Bot commented on GEODE-9753: --- gaussianrecurrence opened a new pull request #891: URL: https://github.com/apache/geode-native/pull/891 - While serializing a PdxSerializable object, there is a possible race condition which might cause the client to crash. This race-condition happens whenever the cluster is restarted during the serialization process and if on-client-disconnect-clear-pdxType-Ids is set to true, meaning the PdxTypeRegistry will be cleaned up if the connection towards the cluster is lost. - This issue has been solved by using the previously fetched local PDX type. - In order to properly test this solution, PdxRemoteWriterFactory has been added, so the race-condition can be force at test-time. - A new IT has been added to test that the solution is working fine. - make_unique was needed inside cppcache/src, so it was moved to utils/cxx_extensions.hpp - Also in order to ease the use of newer C++ standard a preprocessor check was added to make_unique, so if the used standard >= C++14, the standard implementation of make_unique will be used instead. -- 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 > Coredump during PdxSerializable object serialization > > > Key: GEODE-9753 > URL: https://issues.apache.org/jira/browse/GEODE-9753 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: needsTriage > > *GIVEN* **a single server and locator cluster with 1 PdxSerializable class > registered, named Order > *AND* a geode-native client with 1 PdxSerializable 1 PdxSerializable class > registered, named Order > *WHEN* a Order object is tried to be serialized > *WHILE* the cluster is being restarted > *THEN* a coredump happens due to PdxType=nullptr > — > *Additional information*. As seen by early troubleshooting, the coredump > happens because the pdx type is tried to be fetched from the PdxTypeRegist by > its class name, but the PdxTypeRegistry is cleaned up during serialization > given that subscription redundancy was lost. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9753) Coredump during PdxSerializable object serialization
[ https://issues.apache.org/jira/browse/GEODE-9753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9753: -- Labels: needsTriage pull-request-available (was: needsTriage) > Coredump during PdxSerializable object serialization > > > Key: GEODE-9753 > URL: https://issues.apache.org/jira/browse/GEODE-9753 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: needsTriage, pull-request-available > > *GIVEN* **a single server and locator cluster with 1 PdxSerializable class > registered, named Order > *AND* a geode-native client with 1 PdxSerializable 1 PdxSerializable class > registered, named Order > *WHEN* a Order object is tried to be serialized > *WHILE* the cluster is being restarted > *THEN* a coredump happens due to PdxType=nullptr > — > *Additional information*. As seen by early troubleshooting, the coredump > happens because the pdx type is tried to be fetched from the PdxTypeRegist by > its class name, but the PdxTypeRegistry is cleaned up during serialization > given that subscription redundancy was lost. -- This message was sent by Atlassian Jira (v8.3.4#803005)
