[jira] [Commented] (GEODE-8963) separate client/server compatibility from server/server version compatibility
[
https://issues.apache.org/jira/browse/GEODE-8963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294298#comment-17294298
]
ASF GitHub Bot commented on GEODE-8963:
---
onichols-pivotal opened a new pull request #6081:
URL: https://github.com/apache/geode/pull/6081
also fix the comment in KnownVersion to match the new policy in the release
scripts to increment by 10 per minor instead of 5
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> separate client/server compatibility from server/server version compatibility
> -
>
> Key: GEODE-8963
> URL: https://issues.apache.org/jira/browse/GEODE-8963
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> A client's version is used for deserializing data received from the client
> and for serializing data sent to the client. It is also used to locate the
> map of Commands used to process client requests. Every time we cut a new
> release we bump this version in KnownVersions and create a new map of
> Commands, even though client/server communications protocols rarely change.
> We should have each KnownVersion hold a client/server compatibility number
> that is used to identify clients rather than the KnownVersion's ordinal.
> For instance,
> {code:java}
> public static final KnownVersion GEODE_1_15_0 =
> new KnownVersion("GEODE", "1.15.0", (byte) 1, (byte) 15, (byte) 0,
> (byte) 0,
> /*server/server version*/GEODE_1_15_0_ORDINAL,
> /*client/server version*/GEODE_1_15_0_ORDINAL);
>
> public static final KnownVersion GEODE_1_16_0 =
> new KnownVersion("GEODE", "1.16.0", (byte) 1, (byte) 16, (byte) 0,
> (byte) 0,
> /*server/server version*/GEODE_1_16_0_ORDINAL,
> /*client/server version*/GEODE_1_15_0_ORDINAL);
> public static final KnownVersion GEODE_1_17_0 =
> new KnownVersion("GEODE", "1.17.0", (byte) 1, (byte) 17, (byte) 0,
> (byte) 0,
> /*server/server version*/GEODE_1_17_0_ORDINAL,
> /*client/server version*/GEODE_1_15_0_ORDINAL);
> {code}
> In the above KnownVersions the client/server serialization is known to have
> not changed since v1.15.0 and so there is no need to use a newer KnownVersion
> for clients.
> Client handshake code will need to be changed to use the client/server
> ordinal when identifying clients and servers.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8980) bump dependencies for 1.15.0 [PERMANENT]
[ https://issues.apache.org/jira/browse/GEODE-8980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-8980: Summary: bump dependencies for 1.15.0 [PERMANENT] (was: bump dependencies for 1.15.0) > bump dependencies for 1.15.0 [PERMANENT] > > > Key: GEODE-8980 > URL: https://issues.apache.org/jira/browse/GEODE-8980 > Project: Geode > Issue Type: Improvement > Components: build >Affects Versions: 1.15.0 >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > > keeping up with the latest versions of 3rd-party libraries used by Geode is a > proactive way to reduce bugs and avoid security vulnerabilities. this ticket > will be used for ~monthly dependency bumps on develop until we get close to > cutting support/1.15 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8996) Rebalance GFSH commands and restore redundancy commands were not backward compatible
[ https://issues.apache.org/jira/browse/GEODE-8996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294279#comment-17294279 ] ASF GitHub Bot commented on GEODE-8996: --- nabarunnag opened a new pull request #6080: URL: https://github.com/apache/geode/pull/6080 * Moved new child RebalanceFunction and CacheRealizationFunction to pre 1.12.0 locations. * While talking to pre-1.12.0 servers, the locators send the function from the old package. * While talking to 1.12.0 server, the new package function is used. * For RebalanceFunction and CacheRealizationFunction the serialVersionUID is set to the one create by 1.11.0 for old package location and serialVersionUID created by 1.12.0 for the later. Thank you for submitting a contribution to Apache Geode. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Has your PR been rebased against the latest commit within the target branch (typically `develop`)? - [ ] Is your initial contribution a single, squashed commit? - [ ] Does `gradlew build` run cleanly? - [ ] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? ### Note: Please ensure that once the PR is submitted, check Concourse for build issues and submit an update to your PR as soon as possible. If you need help, please send an email to d...@geode.apache.org. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Rebalance GFSH commands and restore redundancy commands were not backward > compatible > > > Key: GEODE-8996 > URL: https://issues.apache.org/jira/browse/GEODE-8996 > Project: Geode > Issue Type: Bug > Components: gfsh, rest (admin) >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > > Issue: > * Rebalance command when executed with 1.12.0+ locator and older servers, > the command failed > * This was because the Rebalance function moved to a new package > * Similar problem with REST calls because of moving CacheRealizationFunction > to a new package > * There was another problem where Serializable classes with UIDs were > changed in couple of releases > * The variation of the UIDs caused deserialization issues when REST commands > were executed from new locators and old servers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8996) Rebalance GFSH commands and restore redundancy commands were not backward compatible
[ https://issues.apache.org/jira/browse/GEODE-8996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8996: -- Labels: pull-request-available (was: ) > Rebalance GFSH commands and restore redundancy commands were not backward > compatible > > > Key: GEODE-8996 > URL: https://issues.apache.org/jira/browse/GEODE-8996 > Project: Geode > Issue Type: Bug > Components: gfsh, rest (admin) >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: pull-request-available > > Issue: > * Rebalance command when executed with 1.12.0+ locator and older servers, > the command failed > * This was because the Rebalance function moved to a new package > * Similar problem with REST calls because of moving CacheRealizationFunction > to a new package > * There was another problem where Serializable classes with UIDs were > changed in couple of releases > * The variation of the UIDs caused deserialization issues when REST commands > were executed from new locators and old servers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8996) Rebalance GFSH commands and restore redundancy commands were not backward compatible
Nabarun Nag created GEODE-8996: -- Summary: Rebalance GFSH commands and restore redundancy commands were not backward compatible Key: GEODE-8996 URL: https://issues.apache.org/jira/browse/GEODE-8996 Project: Geode Issue Type: Bug Components: gfsh, rest (admin) Reporter: Nabarun Nag Issue: * Rebalance command when executed with 1.12.0+ locator and older servers, the command failed * This was because the Rebalance function moved to a new package * Similar problem with REST calls because of moving CacheRealizationFunction to a new package * There was another problem where Serializable classes with UIDs were changed in couple of releases * The variation of the UIDs caused deserialization issues when REST commands were executed from new locators and old servers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8996) Rebalance GFSH commands and restore redundancy commands were not backward compatible
[ https://issues.apache.org/jira/browse/GEODE-8996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nabarun Nag reassigned GEODE-8996: -- Assignee: Nabarun Nag > Rebalance GFSH commands and restore redundancy commands were not backward > compatible > > > Key: GEODE-8996 > URL: https://issues.apache.org/jira/browse/GEODE-8996 > Project: Geode > Issue Type: Bug > Components: gfsh, rest (admin) >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > > Issue: > * Rebalance command when executed with 1.12.0+ locator and older servers, > the command failed > * This was because the Rebalance function moved to a new package > * Similar problem with REST calls because of moving CacheRealizationFunction > to a new package > * There was another problem where Serializable classes with UIDs were > changed in couple of releases > * The variation of the UIDs caused deserialization issues when REST commands > were executed from new locators and old servers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8864) finish implementation of Redis HScan Command
[
https://issues.apache.org/jira/browse/GEODE-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294248#comment-17294248
]
ASF GitHub Bot commented on GEODE-8864:
---
sabbey37 commented on a change in pull request #5954:
URL: https://github.com/apache/geode/pull/5954#discussion_r586037142
##
File path:
geode-redis/src/integrationTest/java/org/apache/geode/redis/internal/executor/hash/AbstractHScanIntegrationTest.java
##
@@ -219,13 +298,13 @@ public void
givenCount_returnsAllEntriesWithoutDuplicates() {
cursor = result.getCursor();
} while (!result.isCompleteIteration());
-assertThat(allEntries).hasSize(3);
-assertThat(new HashSet<>(allEntries)).isEqualTo(entryMap.entrySet());
+assertThat(allEntries.size()).isCloseTo(3, Offset.offset(1));
Review comment:
A few thoughts:
- The test name is kinda misleading, since we say
`returnsAllEntriesWithoutDuplicates`, but we are admitting the possibility of
duplicates.
- You could use lambdas (like you did in another part of the code) to remove
any duplicates before the assertion, something like:
```
List> allEntriesWithoutDuplicates =
allEntries.stream().distinct().collect(Collectors.toList());
```
- But really none of the above matters because, thinking about it more, I
realize that for most of our tests, the data is so small that native Redis is
always going to return all the entries at once (per the `Why SCAN may return
all the items of an aggregate data type in a single call?` section of the SCAN
documentation as well as the Redis code (see `db.c` file, `scanGenericCommand`
method)). So we can actually check that the size and entries match exactly what
we expect.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> finish implementation of Redis HScan Command
>
>
> Key: GEODE-8864
> URL: https://issues.apache.org/jira/browse/GEODE-8864
> Project: Geode
> Issue Type: New Feature
> Components: redis
>Reporter: John Hutchison
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8864) finish implementation of Redis HScan Command
[
https://issues.apache.org/jira/browse/GEODE-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294217#comment-17294217
]
ASF GitHub Bot commented on GEODE-8864:
---
sabbey37 commented on a change in pull request #5954:
URL: https://github.com/apache/geode/pull/5954#discussion_r586040291
##
File path:
geode-redis/src/main/java/org/apache/geode/redis/internal/data/RedisHash.java
##
@@ -46,19 +53,88 @@
public class RedisHash extends AbstractRedisData {
public static final RedisHash NULL_REDIS_HASH = new NullRedisHash();
private HashMap hash;
+ private ConcurrentHashMap> hScanSnapShots;
+ private ConcurrentHashMap hScanSnapShotCreationTimes;
+ private ScheduledExecutorService HSCANSnapshotExpirationExecutor = null;
+
+ private static int default_hscan_snapshots_expire_check_frequency =
+ Integer.getInteger("redis.hscan-snapshot-cleanup-interval", 3);
+
+ private static int default_hscan_snapshots_milliseconds_to_live =
+ Integer.getInteger("redis.hscan-snapshot-expiry", 3);
+
+ private int HSCAN_SNAPSHOTS_EXPIRE_CHECK_FREQUENCY_MILLISECONDS;
+ private int MINIMUM_MILLISECONDS_FOR_HSCAN_SNAPSHOTS_TO_LIVE;
+
+ @VisibleForTesting
+ public RedisHash(List fieldsToSet, int
hscanSnapShotExpirationCheckFrequency,
+ int minimumLifeForHscanSnaphot) {
+this();
+
+this.HSCAN_SNAPSHOTS_EXPIRE_CHECK_FREQUENCY_MILLISECONDS =
+hscanSnapShotExpirationCheckFrequency;
+this.MINIMUM_MILLISECONDS_FOR_HSCAN_SNAPSHOTS_TO_LIVE =
minimumLifeForHscanSnaphot;
- public RedisHash(List fieldsToSet) {
-hash = new HashMap<>();
Iterator iterator = fieldsToSet.iterator();
while (iterator.hasNext()) {
hashPut(iterator.next(), iterator.next());
}
}
+ public RedisHash(List fieldsToSet) {
+this(fieldsToSet,
+default_hscan_snapshots_expire_check_frequency,
+default_hscan_snapshots_milliseconds_to_live);
+ }
+
+ // for serialization
public RedisHash() {
-// for serialization
+this.hash = new HashMap<>();
+this.hScanSnapShots = new ConcurrentHashMap<>();
+this.hScanSnapShotCreationTimes = new ConcurrentHashMap<>();
+
+this.HSCAN_SNAPSHOTS_EXPIRE_CHECK_FREQUENCY_MILLISECONDS =
+this.default_hscan_snapshots_expire_check_frequency;
+
+this.MINIMUM_MILLISECONDS_FOR_HSCAN_SNAPSHOTS_TO_LIVE =
+this.default_hscan_snapshots_milliseconds_to_live;
}
+
+ private void expireHScanSnapshots() {
+
+this.hScanSnapShotCreationTimes.entrySet().forEach(entry -> {
Review comment:
I was confused for a second, but then realized the above comment went
with the comment that was in the `createKeySnapshot` method. Those changes look
good!
The conversation didn't propagate to this area, so here it is:
```
@sabbey37
You could actually do this.hScanSnapShotCreationTimes.forEach((entry,
creationTime) -> {...}, that way you wouldn't have to do the entry.getValue();
on the next line. Not necessary, just something cool IntelliJ suggested.
Tip
@jhutchison
o, wow- that's because I'm not making a copy like I thought I was- changed
to this:
List keySnapShot = new ArrayList<>();
List hashKeysAsList = Arrays.asList(hash.keySet().toArray());
Collections.copy(keySnapShot, hashKeysAsList);
```
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> finish implementation of Redis HScan Command
>
>
> Key: GEODE-8864
> URL: https://issues.apache.org/jira/browse/GEODE-8864
> Project: Geode
> Issue Type: New Feature
> Components: redis
>Reporter: John Hutchison
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8864) finish implementation of Redis HScan Command
[
https://issues.apache.org/jira/browse/GEODE-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294214#comment-17294214
]
ASF GitHub Bot commented on GEODE-8864:
---
sabbey37 commented on a change in pull request #5954:
URL: https://github.com/apache/geode/pull/5954#discussion_r586017202
##
File path:
geode-redis/src/test/java/org/apache/geode/redis/internal/data/RedisHashTest.java
##
@@ -161,4 +163,109 @@ public void
setExpirationTimestamp_stores_delta_that_is_stable() throws IOExcept
o2.fromDelta(in);
assertThat(o2).isEqualTo(o1);
}
+
+ @Test
+ public void hscanSnaphots_shouldBeEmpty_givenHscanHasNotBeenCalled() {
+RedisHash subject = createRedisHash(100);
+assertThat(subject.getHscanSnapShots()).isEmpty();
+ }
+
+ @Test
+ public void hscanSnaphots_shouldContainSnapshot_givenHscanHasBeenCalled() {
+
+final List FIELDS_AND_VALUES_FOR_HASH =
createListOfDataElements(100);
+RedisHash subject = new RedisHash(FIELDS_AND_VALUES_FOR_HASH);
+UUID clientID = UUID.randomUUID();
+
+subject.hscan(clientID, null, 10, BigInteger.valueOf(0));
+
+ConcurrentHashMap> hscanSnapShotMap =
subject.getHscanSnapShots();
+
+assertThat(hscanSnapShotMap.containsKey(clientID)).isTrue();
+
+List keyList = hscanSnapShotMap.get(clientID);
+assertThat(keyList).isNotEmpty();
+
+FIELDS_AND_VALUES_FOR_HASH.forEach((entry) -> {
+ if (entry.toString().contains("field")) {
+assertThat(keyList.contains(entry)).isTrue();
+ } else if (entry.toString().contains("value")) {
+assertThat(keyList.contains(entry)).isFalse();
Review comment:
I think this got updated for the test below it, but not this one.
the conversation wasn't propagated, so adding it here:
```
you could do the following:
if (entry.toString().contains("field")) {
assertThat(keyList).contains(entry);
} else if (entry.toString().contains("value")) {
assertThat(keyList).doesNotContain(entry);
}
this will result in clearer failure messages.
```
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> finish implementation of Redis HScan Command
>
>
> Key: GEODE-8864
> URL: https://issues.apache.org/jira/browse/GEODE-8864
> Project: Geode
> Issue Type: New Feature
> Components: redis
>Reporter: John Hutchison
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8864) finish implementation of Redis HScan Command
[
https://issues.apache.org/jira/browse/GEODE-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294212#comment-17294212
]
ASF GitHub Bot commented on GEODE-8864:
---
sabbey37 commented on a change in pull request #5954:
URL: https://github.com/apache/geode/pull/5954#discussion_r585937669
##
File path:
geode-redis/src/main/java/org/apache/geode/redis/internal/executor/hash/HScanExecutor.java
##
@@ -44,26 +45,29 @@
@Override
public RedisResponse executeCommand(Command command,
ExecutionHandlerContext context) {
+
+final UUID CLIENT_ID = context.getClientUUID();
+
List commandElems = command.getProcessedCommand();
String cursorString = Coder.bytesToString(commandElems.get(2));
-BigInteger cursor;
+int cursor;
Pattern matchPattern;
String globPattern = null;
int count = DEFAULT_COUNT;
try {
- cursor = new BigInteger(cursorString).abs();
+ cursor = Integer.valueOf(cursorString);
} catch (NumberFormatException e) {
return RedisResponse.error(ERROR_CURSOR);
}
-if (cursor.compareTo(UNSIGNED_LONG_CAPACITY) > 0) {
+if (cursor > Integer.MAX_VALUE) {
return RedisResponse.error(ERROR_CURSOR);
}
Review comment:
You can actually remove this conditional block now. We needed it before
because the capacity of `BigInteger` is greater than the unsigned long capacity.
##
File path:
geode-redis/src/distributedTest/java/org/apache/geode/redis/internal/executor/hash/HScanDunitTest.java
##
@@ -0,0 +1,241 @@
+/*
+ * 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.redis.internal.executor.hash;
+
+import static
org.apache.geode.distributed.ConfigurationProperties.MAX_WAIT_TIME_RECONNECT;
+import static org.apache.geode.test.dunit.IgnoredException.addIgnoredException;
+import static org.assertj.core.api.Assertions.assertThat;
+
+import java.util.ArrayList;
+import java.util.HashMap;
+import java.util.List;
+import java.util.Map;
+import java.util.Properties;
+import java.util.concurrent.ExecutionException;
+import java.util.concurrent.Future;
+import java.util.concurrent.atomic.AtomicBoolean;
+import java.util.concurrent.atomic.AtomicInteger;
+
+import io.lettuce.core.ClientOptions;
+import io.lettuce.core.MapScanCursor;
+import io.lettuce.core.RedisClient;
+import io.lettuce.core.RedisCommandExecutionException;
+import io.lettuce.core.RedisException;
+import io.lettuce.core.ScanCursor;
+import io.lettuce.core.api.StatefulRedisConnection;
+import io.lettuce.core.api.sync.RedisCommands;
+import io.lettuce.core.resource.ClientResources;
+import org.junit.AfterClass;
+import org.junit.Before;
+import org.junit.BeforeClass;
+import org.junit.ClassRule;
+import org.junit.Rule;
+import org.junit.Test;
+
+import org.apache.geode.cache.control.RebalanceFactory;
+import org.apache.geode.cache.control.ResourceManager;
+import org.apache.geode.cache.execute.FunctionException;
+import org.apache.geode.internal.AvailablePortHelper;
+import
org.apache.geode.redis.session.springRedisTestApplication.config.DUnitSocketAddressResolver;
+import org.apache.geode.test.dunit.rules.ClusterStartupRule;
+import org.apache.geode.test.dunit.rules.MemberVM;
+import org.apache.geode.test.dunit.rules.RedisClusterStartupRule;
+import org.apache.geode.test.junit.rules.ExecutorServiceRule;
+import org.apache.geode.test.junit.rules.GfshCommandRule;
+
+public class HScanDunitTest {
+
+ @ClassRule
+ public static RedisClusterStartupRule redisClusterStartupRule = new
RedisClusterStartupRule(4);
+
+ @Rule
+ public ExecutorServiceRule executor = new ExecutorServiceRule();
+
+ @ClassRule
+ public static GfshCommandRule gfsh = new GfshCommandRule();
+
+ private static RedisCommands commands;
+ private RedisClient redisClient;
+ private StatefulRedisConnection connection;
+ private static Properties locatorProperties;
+
+ private static MemberVM locator;
+ private static MemberVM server1;
+ private static MemberVM server2;
+ private static MemberVM server3;
+
+ static final String HASH_KEY = "key";
+ static final String BASE_FIELD = "baseField_";
[jira] [Commented] (GEODE-8864) finish implementation of Redis HScan Command
[
https://issues.apache.org/jira/browse/GEODE-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294207#comment-17294207
]
ASF GitHub Bot commented on GEODE-8864:
---
sabbey37 commented on a change in pull request #5954:
URL: https://github.com/apache/geode/pull/5954#discussion_r583054944
##
File path:
geode-redis/src/integrationTest/java/org/apache/geode/redis/internal/executor/hash/AbstractHScanIntegrationTest.java
##
@@ -237,15 +316,40 @@ public void
givenMultipleCounts_returnsAllEntriesWithoutDuplicates() {
String cursor = "0";
do {
- result = (List) jedis.sendCommand(Protocol.Command.HSCAN,
"colors", cursor, "COUNT",
- "2", "COUNT", "1");
+ result = (List) jedis.sendCommand(Protocol.Command.HSCAN,
+ "colors",
+ cursor,
+ "COUNT", "2",
+ "COUNT", "1");
+
allEntries.addAll((List) result.get(1));
cursor = new String((byte[]) result.get(0));
} while (!Arrays.equals((byte[]) result.get(0), "0".getBytes()));
assertThat((byte[]) result.get(0)).isEqualTo("0".getBytes());
-assertThat(allEntries).containsExactlyInAnyOrder("1".getBytes(),
"yellow".getBytes(),
-"12".getBytes(), "green".getBytes(), "3".getBytes(),
"grey".getBytes());
+ }
+
+ @Test
+ public void givenCompleteIteration_shouldReturnCursorWithValueOfZero() {
+Map entryMap = new HashMap<>();
+entryMap.put("1", "yellow");
+entryMap.put("2", "green");
+entryMap.put("3", "orange");
+jedis.hmset("colors", entryMap);
+
+ScanParams scanParams = new ScanParams();
+scanParams.count(1);
+ScanResult> result;
+List> allEntries = new ArrayList<>();
+String cursor = "0";
+
+do {
+ result = jedis.hscan("colors", cursor, scanParams);
+ allEntries.addAll(result.getResult());
+ cursor = result.getCursor();
+} while (!result.isCompleteIteration());
+
+assertThat(result.getCursor()).isEqualTo("0");
}
@Test
Review comment:
There are some other tests (that Darrel and I added) that check exact
matches between what's expected and what's returned. Given previous
comments/changes (and knowing that native Redis doesn't guarantee an element
will only be returned once), I'm wondering if it makes sense to change these as
well to check `containsAll()` vs. `containsExactlyInAnyOrder()` or `equals()`,
etc.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> finish implementation of Redis HScan Command
>
>
> Key: GEODE-8864
> URL: https://issues.apache.org/jira/browse/GEODE-8864
> Project: Geode
> Issue Type: New Feature
> Components: redis
>Reporter: John Hutchison
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8864) finish implementation of Redis HScan Command
[
https://issues.apache.org/jira/browse/GEODE-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294192#comment-17294192
]
ASF GitHub Bot commented on GEODE-8864:
---
sabbey37 commented on a change in pull request #5954:
URL: https://github.com/apache/geode/pull/5954#discussion_r583045619
##
File path:
geode-redis/src/integrationTest/java/org/apache/geode/redis/internal/executor/hash/AbstractHScanIntegrationTest.java
##
@@ -237,15 +316,40 @@ public void
givenMultipleCounts_returnsAllEntriesWithoutDuplicates() {
String cursor = "0";
do {
- result = (List) jedis.sendCommand(Protocol.Command.HSCAN,
"colors", cursor, "COUNT",
- "2", "COUNT", "1");
+ result = (List) jedis.sendCommand(Protocol.Command.HSCAN,
+ "colors",
+ cursor,
+ "COUNT", "2",
+ "COUNT", "1");
+
allEntries.addAll((List) result.get(1));
cursor = new String((byte[]) result.get(0));
} while (!Arrays.equals((byte[]) result.get(0), "0".getBytes()));
assertThat((byte[]) result.get(0)).isEqualTo("0".getBytes());
-assertThat(allEntries).containsExactlyInAnyOrder("1".getBytes(),
"yellow".getBytes(),
-"12".getBytes(), "green".getBytes(), "3".getBytes(),
"grey".getBytes());
Review comment:
I know this was removed entirely, but maybe we could just change this to
check that all the expected elements are there (`.containsAll()`)... since
there may be duplicates, but it is guaranteed that all elements present for the
full iteration will be returned at least once.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> finish implementation of Redis HScan Command
>
>
> Key: GEODE-8864
> URL: https://issues.apache.org/jira/browse/GEODE-8864
> Project: Geode
> Issue Type: New Feature
> Components: redis
>Reporter: John Hutchison
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8905) Introduce JarDeploymentService
[ https://issues.apache.org/jira/browse/GEODE-8905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294191#comment-17294191 ] ASF subversion and git services commented on GEODE-8905: Commit f2636e0fbfd898f8c213751381040500922ebdf8 in geode's branch refs/heads/develop from Udo Kohlmeyer [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f2636e0 ] Revert "GEODE-8905: Introduce JarDeploymentService (#5989)" (#6078) This reverts commit e32c3076 > Introduce JarDeploymentService > -- > > Key: GEODE-8905 > URL: https://issues.apache.org/jira/browse/GEODE-8905 > Project: Geode > Issue Type: Improvement > Components: gfsh, management >Reporter: Patrick Johnsn >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > > Introduce a JarDeploymentService interface that will allow us to interchange > the current way of deploying jars with the new modular approach. > > There will be an implementation that delegates to the existing JarDeployer > and will maintain current behavior. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8905) Introduce JarDeploymentService
[ https://issues.apache.org/jira/browse/GEODE-8905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294189#comment-17294189 ] ASF GitHub Bot commented on GEODE-8905: --- kohlmu-pivotal merged pull request #6078: URL: https://github.com/apache/geode/pull/6078 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Introduce JarDeploymentService > -- > > Key: GEODE-8905 > URL: https://issues.apache.org/jira/browse/GEODE-8905 > Project: Geode > Issue Type: Improvement > Components: gfsh, management >Reporter: Patrick Johnsn >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > > Introduce a JarDeploymentService interface that will allow us to interchange > the current way of deploying jars with the new modular approach. > > There will be an implementation that delegates to the existing JarDeployer > and will maintain current behavior. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8995) Redis-compatibility: comply with legal
Hale Bales created GEODE-8995: - Summary: Redis-compatibility: comply with legal Key: GEODE-8995 URL: https://issues.apache.org/jira/browse/GEODE-8995 Project: Geode Issue Type: Improvement Components: redis Affects Versions: 1.14.0 Reporter: Hale Bales change occurrences of "redis" to "redis-compatibility" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8979) CI Failure: SSLSocketHostNameVerificationIntegrationTest
[
https://issues.apache.org/jira/browse/GEODE-8979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294069#comment-17294069
]
ASF GitHub Bot commented on GEODE-8979:
---
echobravopapa commented on a change in pull request #6079:
URL: https://github.com/apache/geode/pull/6079#discussion_r586011011
##
File path:
geode-core/src/integrationTest/java/org/apache/geode/internal/net/SSLSocketHostNameVerificationIntegrationTest.java
##
@@ -211,18 +211,17 @@ private Thread startServerNIO(final ServerSocket
serverSocket, int timeoutMillis
} catch (Throwable throwable) {
serverException = throwable;
} finally {
-if (engine != null && socket != null) {
+if (engine != null) {
Review comment:
null check is no longer needed?
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> CI Failure: SSLSocketHostNameVerificationIntegrationTest
>
>
> Key: GEODE-8979
> URL: https://issues.apache.org/jira/browse/GEODE-8979
> Project: Geode
> Issue Type: Test
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
>
> This test failed in a CI IntegrationTest run with this exception:
> {noformat}
> org.apache.geode.internal.net.SSLSocketHostNameVerificationIntegrationTest >
> nioHandshakeValidatesHostName[hasSAN=true and doEndPointIdentification=true]
> FAILED
> org.apache.geode.GemFireIOException: exception closing SSL session
> at
> org.apache.geode.internal.net.NioSslEngine.close(NioSslEngine.java:409)
> at
> org.apache.geode.internal.net.SSLSocketHostNameVerificationIntegrationTest.lambda$startServerNIO$3(SSLSocketHostNameVerificationIntegrationTest.java:216)
> Caused by:
> java.io.IOException: Connection reset by peer
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:51)
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:470)
> at
> org.apache.geode.internal.net.NioSslEngine.close(NioSslEngine.java:403)
> ... 1 more
> {noformat}
> It looks like the test needs to have a try/catch for IOException when closing
> the NioSslEngine.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8671) Two threads calling get and retrieve the same PdxInstance, resulting in corruption
[ https://issues.apache.org/jira/browse/GEODE-8671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294066#comment-17294066 ] ASF GitHub Bot commented on GEODE-8671: --- kirklund edited a comment on pull request #5925: URL: https://github.com/apache/geode/pull/5925#issuecomment-789321362 > Looks like you have a few small changes to make but I'll give my approval now. Please consider adding unit test coverage for the changes in LocalRegion. There is an existing `LocalRegionTest` that uses Mockito. I also suggest you remove the `tearDown` since it's doing the same thing that the `DistributedBlackboard` Rule does after every test method. By the way, I verified that you don't need to invoke `DUnitBlackboard.initBlackboard()` in the `tearDown`. The Rule completely dereferences the instance of `DUnitBlackboard` and so it becomes available to GC. The Rule effectively handles the initialization and cleanup of `DUnitBlackboard` so that a test doesn't need to do this. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Two threads calling get and retrieve the same PdxInstance, resulting in > corruption > -- > > Key: GEODE-8671 > URL: https://issues.apache.org/jira/browse/GEODE-8671 > Project: Geode > Issue Type: Improvement > Components: regions >Reporter: Dan Smith >Assignee: Jianxia Chen >Priority: Major > Labels: blocks-1.14.0, pull-request-available > > Even if copy-on-read is set to true, two threads calling get on a partitioned > region can end up with the same PdxInstance object. > This is problematic because some PdxInstances methods are not thread safe. > Although the underlying bytes are immutatable, the PDXInstance has a > ByteSource with a position field that changes. That means two threads doing > serialization or calling toString on the PdxInstance could result in one or > more threads getting a corrupt read. > It looks like they are ending up with the same instance because of the > behavior in LocalRegion.optimizedGetObject. We use futures to make sure there > is only 1 get that goes through, and both threads receive the same value. > > Ending up in optimizedGetObject requires a race with the put, because if the > value was in the cache at the beginning of the get it would be returned > earlier in the get process. > I put a test that reproduces this issue here - > https://github.com/upthewaterspout/geode/pull/new/feature/pdx-instances-shared -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8671) Two threads calling get and retrieve the same PdxInstance, resulting in corruption
[ https://issues.apache.org/jira/browse/GEODE-8671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294064#comment-17294064 ] ASF GitHub Bot commented on GEODE-8671: --- kirklund commented on pull request #5925: URL: https://github.com/apache/geode/pull/5925#issuecomment-789321362 > Looks like you have a few small changes to make but I'll give my approval now. Please consider adding unit test coverage for the changes in LocalRegion. There is an existing `LocalRegionTest` that uses Mockito. I also suggest you remove the `tearDown` since it's doing the same thing that the `DistributedBlackboard` Rule does after every test method. By the way, I verified that you don't need to invoke `DUnitBlackboard.initBlackboard()` in the `tearDown`. The Rule completely dereferences the instance of `DUnitBlackboard` and so it becomes available to GC. The Rule handles the initialization and cleanup of `DUnitBlackboard`. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Two threads calling get and retrieve the same PdxInstance, resulting in > corruption > -- > > Key: GEODE-8671 > URL: https://issues.apache.org/jira/browse/GEODE-8671 > Project: Geode > Issue Type: Improvement > Components: regions >Reporter: Dan Smith >Assignee: Jianxia Chen >Priority: Major > Labels: blocks-1.14.0, pull-request-available > > Even if copy-on-read is set to true, two threads calling get on a partitioned > region can end up with the same PdxInstance object. > This is problematic because some PdxInstances methods are not thread safe. > Although the underlying bytes are immutatable, the PDXInstance has a > ByteSource with a position field that changes. That means two threads doing > serialization or calling toString on the PdxInstance could result in one or > more threads getting a corrupt read. > It looks like they are ending up with the same instance because of the > behavior in LocalRegion.optimizedGetObject. We use futures to make sure there > is only 1 get that goes through, and both threads receive the same value. > > Ending up in optimizedGetObject requires a race with the put, because if the > value was in the cache at the beginning of the get it would be returned > earlier in the get process. > I put a test that reproduces this issue here - > https://github.com/upthewaterspout/geode/pull/new/feature/pdx-instances-shared -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8097) ClientClusterManagementServiceTest expects 1 callback but gets 295
[
https://issues.apache.org/jira/browse/GEODE-8097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294050#comment-17294050
]
ASF subversion and git services commented on GEODE-8097:
Commit 8a0dc1aae8636a44c4fa4d5d30dcbc0efafb4430 in geode's branch
refs/heads/support/1.14 from Jinmei Liao
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=8a0dc1a ]
GEODE-8097: expects at least one callback (#6049)
(cherry picked from commit e08cad4d7198f9bd82614ca9b7e631df36b38757)
> ClientClusterManagementServiceTest expects 1 callback but gets 295
> --
>
> Key: GEODE-8097
> URL: https://issues.apache.org/jira/browse/GEODE-8097
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Bill Burcham
>Assignee: Jinmei Liao
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
>
> CI test failed here:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsUnitTestOpenJDK8/builds/138#A
> {code}
> org.apache.geode.management.internal.ClientClusterManagementServiceTest >
> getOperationCallsSubmitMessageAndReturnsFuture FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.internal.ClientClusterManagementServiceTest
> clusterManagementServiceTransport.submitMessageForGetOperation(
>
> same(org.apache.geode.management.operation.RebalanceOperation@6d6b2db0),
> same("opId")
> );
> Wanted 1 time:
> -> at
> org.apache.geode.management.internal.ClientClusterManagementServiceTest.lambda$getOperationCallsSubmitMessageAndReturnsFuture$1(ClientClusterManagementServiceTest.java:170)
> But was 295 times:
> -> at
> org.apache.geode.management.internal.ClientClusterManagementService.get(ClientClusterManagementService.java:114)
> -> at
> org.apache.geode.management.internal.ClientClusterManagementService.get(ClientClusterManagementService.java:114)
> -> at
> org.apache.geode.management.internal.ClientClusterManagementService.get(ClientClusterManagementService.java:114)
> …
> {code}
> Ran it 100 times in IntelliJ with no failures.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7309) Upgrade Lucene from 6.6.2 to 8.2.0
[
https://issues.apache.org/jira/browse/GEODE-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294042#comment-17294042
]
ASF GitHub Bot commented on GEODE-7309:
---
kirklund commented on a change in pull request #6076:
URL: https://github.com/apache/geode/pull/6076#discussion_r585984716
##
File path:
geode-lucene/src/upgradeTest/java/org/apache/geode/cache/lucene/LuceneQueryWithDifferentVersions.java
##
@@ -0,0 +1,103 @@
+/*
+ * 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.cache.lucene;
+
+import static org.apache.geode.test.awaitility.GeodeAwaitility.await;
+import static org.assertj.core.api.Assertions.assertThat;
+import static org.assertj.core.api.Assertions.catchThrowable;
+import static org.junit.Assert.assertTrue;
+
+import org.junit.Test;
+
+import org.apache.geode.cache.RegionShortcut;
+import org.apache.geode.distributed.internal.InternalLocator;
+import org.apache.geode.internal.AvailablePortHelper;
+import org.apache.geode.test.dunit.DistributedTestUtils;
+import org.apache.geode.test.dunit.Host;
+import org.apache.geode.test.dunit.NetworkUtils;
+import org.apache.geode.test.dunit.VM;
+
+public class LuceneQueryWithDifferentVersions
+extends LuceneSearchWithRollingUpgradeDUnit {
+
+ // 2 locator, 2 servers
+ @Test
+ public void luceneQueryCannotBeExecuted()
+ throws Exception {
+final Host host = Host.getHost(0);
+VM locator1 = host.getVM(oldVersion, 0);
+VM locator2 = host.getVM(oldVersion, 1);
+VM server1 = host.getVM(oldVersion, 2);
+VM server2 = host.getVM(oldVersion, 3);
+
+final String regionName = "aRegion";
+RegionShortcut shortcut = RegionShortcut.PARTITION_REDUNDANT;
+String regionType = "partitionedRedundant";
+
+int[] locatorPorts = AvailablePortHelper.getRandomAvailableTCPPorts(2);
+locator1.invoke(() ->
DistributedTestUtils.deleteLocatorStateFile(locatorPorts));
+locator2.invoke(() ->
DistributedTestUtils.deleteLocatorStateFile(locatorPorts));
+
+String hostName = NetworkUtils.getServerHostName(host);
+String locatorString = getLocatorString(locatorPorts);
+try {
+ locator1.invoke(
+ invokeStartLocator(hostName, locatorPorts[0],
getLocatorPropertiesPre91(locatorString)));
+ locator2.invoke(
+ invokeStartLocator(hostName, locatorPorts[1],
getLocatorPropertiesPre91(locatorString)));
+
invokeRunnableInVMs(invokeCreateCache(getSystemProperties(locatorPorts)),
server1, server2);
+
+ // Locators before 1.4 handled configuration asynchronously.
+ // We must wait for configuration configuration to be ready, or confirm
that it is disabled.
+ locator1.invoke(
+ () -> await()
Review comment:
I would get rid of the
`!InternalLocator.getLocator().getConfig().getEnableClusterConfiguration()`
unless you're parameterizing it to run both with and without cluster config.
Then you can simplify it to:
```
await().untilAsserted(() -> {
assertThat(InternalLocator.getLocator().isSharedConfigurationRunning()).isTrue();
}
```
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/InternalCacheForClientAccess.java
##
@@ -1225,6 +1226,14 @@ public void unlockDiskStore(String diskStoreName) {
}
+ @Override
+ public boolean hasMemberOlderThan(KnownVersion version) {
+return getMembers().stream()
Review comment:
Can you just have this method delegate to `delegate` like all the other
methods are doing?
```
@Override
public boolean hasMemberOlderThan(KnownVersion version) {
return delegate.hasMemberOlderThan(version);
}
```
You should not have to add the same method body to both `GemFireCacheImpl`
and `InternalCacheForClientAccess`.
##
File path:
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/repository/IndexRepositoryImpl.java
##
@@ -143,8 +145,35 @@ public void delete(Object key) throws IOException {
@Override
public void query(Query query, int limit, IndexResultCollector collector)
throws IOException {
long start = stats.startRepositoryQuery(
[jira] [Resolved] (GEODE-8986) change benchmarks baseline to version 1.13.1
[ https://issues.apache.org/jira/browse/GEODE-8986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hale Bales resolved GEODE-8986. --- Fix Version/s: 1.15.0 Resolution: Fixed > change benchmarks baseline to version 1.13.1 > > > Key: GEODE-8986 > URL: https://issues.apache.org/jira/browse/GEODE-8986 > Project: Geode > Issue Type: Task > Components: benchmarks, ci >Reporter: Hale Bales >Assignee: Hale Bales >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > In CI, the current baseline is 1.13.0. It should be changed to the most > recent version, which is currently 1.13.1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8872) Add client option, to request locators internal host addresses
[
https://issues.apache.org/jira/browse/GEODE-8872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294031#comment-17294031
]
ASF GitHub Bot commented on GEODE-8872:
---
DonalEvans commented on a change in pull request #5948:
URL: https://github.com/apache/geode/pull/5948#discussion_r585940678
##
File path: geode-core/src/main/java/org/apache/geode/cache/client/Pool.java
##
@@ -207,6 +207,13 @@ default boolean getThreadLocalConnections() {
*/
boolean getMultiuserAuthentication();
+ /**
+ * Returns true ir request locator internal address is enabled on this pool.
+ *
+ * @see PoolFactory#setRequestLocatorInternalAddress(boolean)
+ * @since Geode 1.14
+ */
+ boolean getRequestLocatorInternalAddress();
Review comment:
This method name is a little confusing, as it might be mistaken for a
getter for the locator internal address itself. It might be better as
"isRequestLocatorInternalAddressEnabled", and the corresponding setter as
"setRequestLocatorInternalAddressEnabled".
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/GridAdvisor.java
##
@@ -257,6 +257,9 @@ public Set adviseProfileRemove() {
private String host;
+/** valid only for ControllerProfile */
+private String internalHost;
Review comment:
It doesn't seem correct to have a field in a parent class that only
belongs to one of its child classes. Can this be moved into ControllerProfile?
##
File path:
geode-core/src/main/java/org/apache/geode/cache/client/PoolFactory.java
##
@@ -220,6 +220,14 @@
* @since GemFire 6.5
*/
boolean DEFAULT_MULTIUSER_AUTHENTICATION = false;
+ /**
+ * The default value for whether to request locator internal address.
Review comment:
Slightly more detail would be good here, explaining when exactly the
locator internal address would be requested if this was set to true.
##
File path: geode-core/src/main/java/org/apache/geode/cache/client/Pool.java
##
@@ -207,6 +207,13 @@ default boolean getThreadLocalConnections() {
*/
boolean getMultiuserAuthentication();
+ /**
+ * Returns true ir request locator internal address is enabled on this pool.
Review comment:
Typo here, should be "Returns true if..."
##
File path:
geode-dunit/src/main/java/org/apache/geode/cache/client/internal/LocatorTestBase.java
##
@@ -141,6 +141,34 @@ protected int startLocator(final String hostName, final
String otherLocators) th
return locator.getPort();
}
+ protected int startLocator(final String hostName, final String otherLocators,
Review comment:
This method is never used.
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/GridAdvisor.java
##
@@ -432,6 +447,17 @@ public boolean equals(Object obj) {
if (this.gp.getPort() == other.gp.getPort()) {
final String thisHost = this.gp.getHost();
final String otherHost = other.gp.getHost();
+ final String thisInternalHost = this.gp.getInternalHost();
Review comment:
If internalHost is being included in `equals()` calculations, it should
probably also be included in hashCode()`.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Add client option, to request locators internal host addresses
> ---
>
> Key: GEODE-8872
> URL: https://issues.apache.org/jira/browse/GEODE-8872
> Project: Geode
> Issue Type: New Feature
> Components: client/server
>Reporter: Mario Ivanac
>Assignee: Mario Ivanac
>Priority: Major
> Labels: pull-request-available
>
> Additional option for clients, when pool is created, to request locators
> internal host addresses.
> When sending LocatorListRequest in some cases we need to get internal host
> addresses.
> To describe use case:
> When deploying geode, for locator we define hostname-for-clients. This is
> external address used for WAN, and external clients.
> If we also deploy some clients in internal network (for example in the same
> kubernetes cluster as geode), then for those clients to connect with locator,
> communication will go from internal network to external, then from external
> to internal. This increases latency, and we should communicate over the
> shortest path.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8886) When performing a rolling upgrade to 1.14 from an older version some messages are not delivered
[ https://issues.apache.org/jira/browse/GEODE-8886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294024#comment-17294024 ] ASF subversion and git services commented on GEODE-8886: Commit dcb1096130925e2794010c7a7ab8accfbf49cb3e in geode's branch refs/heads/develop from mhansonp [ https://gitbox.apache.org/repos/asf?p=geode.git;h=dcb1096 ] GEODE-8886 fix (#6059) Getting rid of a write and a read in the wrong place... sanctionedDataSerializables.txt needed updating. New test for encoding and decoding of packets. New test for backwards compatibility > When performing a rolling upgrade to 1.14 from an older version some messages > are not delivered > --- > > Key: GEODE-8886 > URL: https://issues.apache.org/jira/browse/GEODE-8886 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.14.0 >Reporter: Mark Hanson >Assignee: Mark Hanson >Priority: Major > Labels: pull-request-available > > We are running a test where we are performing a rolling upgrade from an older > version to 1.14.0 and we are finding that for whatever reason in this test > that not all "updates" are being passed to all servers and clients while > using gateway senders. It is not clear that gateway senders are the cause, > but at this point, it is just an interesting point. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8886) When performing a rolling upgrade to 1.14 from an older version some messages are not delivered
[ https://issues.apache.org/jira/browse/GEODE-8886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294023#comment-17294023 ] ASF GitHub Bot commented on GEODE-8886: --- mhansonp merged pull request #6059: URL: https://github.com/apache/geode/pull/6059 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > When performing a rolling upgrade to 1.14 from an older version some messages > are not delivered > --- > > Key: GEODE-8886 > URL: https://issues.apache.org/jira/browse/GEODE-8886 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.14.0 >Reporter: Mark Hanson >Assignee: Mark Hanson >Priority: Major > Labels: pull-request-available > > We are running a test where we are performing a rolling upgrade from an older > version to 1.14.0 and we are finding that for whatever reason in this test > that not all "updates" are being passed to all servers and clients while > using gateway senders. It is not clear that gateway senders are the cause, > but at this point, it is just an interesting point. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8605) Alter some GW senders attributes in runtime
[
https://issues.apache.org/jira/browse/GEODE-8605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17294016#comment-17294016
]
ASF GitHub Bot commented on GEODE-8605:
---
bschuchardt commented on a change in pull request #5630:
URL: https://github.com/apache/geode/pull/5630#discussion_r566211293
##
File path:
geode-core/src/main/resources/org/apache/geode/internal/sanctioned-geode-core-serializables.txt
##
@@ -116,6 +116,7 @@
org/apache/geode/cache/client/internal/ContainsKeyOp$MODE,false
org/apache/geode/cache/client/internal/TXSynchronizationOp$CompletionType,false
org/apache/geode/cache/client/internal/pooling/ConnectionDestroyedException,true,-6918516787578041316
org/apache/geode/cache/configuration/CacheConfig$AsyncEventQueue,false,asyncEventListener:org/apache/geode/cache/configuration/DeclarableType,batchSize:java/lang/String,batchTimeInterval:java/lang/String,diskStoreName:java/lang/String,diskSynchronous:java/lang/Boolean,dispatcherThreads:java/lang/String,enableBatchConflation:java/lang/Boolean,forwardExpirationDestroy:java/lang/Boolean,gatewayEventFilters:java/util/List,gatewayEventSubstitutionFilter:org/apache/geode/cache/configuration/DeclarableType,id:java/lang/String,maximumQueueMemory:java/lang/String,orderPolicy:java/lang/String,parallel:java/lang/Boolean,pauseEventProcessing:java/lang/Boolean,persistent:java/lang/Boolean
+org/apache/geode/cache/configuration/CacheConfig$GatewaySender,false,alertThreshold:java/lang/String,batchSize:java/lang/String,batchTimeInterval:java/lang/String,diskStoreName:java/lang/String,diskSynchronous:java/lang/Boolean,dispatcherThreads:java/lang/String,enableBatchConflation:java/lang/Boolean,enablePersistence:java/lang/Boolean,enforceThreadsConnectSameReceiver:java/lang/Boolean,gatewayEventFilters:java/util/List,gatewayEventSubstitutionFilter:org/apache/geode/cache/configuration/DeclarableType,gatewayTransportFilters:java/util/List,groupTransactionEvents:java/lang/Boolean,id:java/lang/String,manualStart:java/lang/Boolean,maximumQueueMemory:java/lang/String,orderPolicy:java/lang/String,parallel:java/lang/Boolean,remoteDistributedSystemId:java/lang/String,socketBufferSize:java/lang/String,socketReadTimeout:java/lang/String
Review comment:
What are the circumstances where CacheConfig$GatewaySender is
serialized? Will this cause backward-compatibility issues during a rolling
upgrade?
Please add a serialversionuid field to GatewaySender.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Alter some GW senders attributes in runtime
> ---
>
> Key: GEODE-8605
> URL: https://issues.apache.org/jira/browse/GEODE-8605
> Project: Geode
> Issue Type: New Feature
> Components: docs, gfsh, wan
>Reporter: Mario Ivanac
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needs-review, pull-request-available
>
> We would like to introduce new command "alter gateway-sender" which would
> update some parameters in runtime. For now parameters of interest are:
> * {color:#6a8759}alert-threshold{color}
> * {color:#6a8759}batch-size{color}
> * {color:#6a8759}batch-time-interval{color}
> * {color:#6a8759}group-transaction-events{color}
> * {color:#6a8759}gateway-event-filter{color}
> * {color:#6a8759}gateway-transport-filter{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8994) Log line for EventId ctor potentially contains garbage string
[
https://issues.apache.org/jira/browse/GEODE-8994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293999#comment-17293999
]
ASF GitHub Bot commented on GEODE-8994:
---
pdxcodemonkey opened a new pull request #756:
URL: https://github.com/apache/geode-native/pull/756
- memId isn't a string, need to convert it first or we'll log garbage.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Log line for EventId ctor potentially contains garbage string
> -
>
> Key: GEODE-8994
> URL: https://issues.apache.org/jira/browse/GEODE-8994
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Blake Bender
>Assignee: Blake Bender
>Priority: Major
>
> The following logging was recently added to geode-native for debugging:
> ```
> LOGDEBUG("EventId::EventId(%p) - memId=%s, memIdLen=%d, thr=%" PRId64
> ", seq=%" PRId64, this, memId, memIdLen, thr, seq);
> ```
> The variable `memId` in this case is of type `char*` but is NOT a valid
> string, rather just a byte buffer. Logging it this way can potentially print
> out garbage, causing errors in parsing tools like gnmsg or other apps when
> attempting to read it. `memId` needs to be decoded into a string
> representation of the bytes, and that logged, rather than attempting to print
> it out raw.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8979) CI Failure: SSLSocketHostNameVerificationIntegrationTest
[
https://issues.apache.org/jira/browse/GEODE-8979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293998#comment-17293998
]
ASF GitHub Bot commented on GEODE-8979:
---
bschuchardt opened a new pull request #6079:
URL: https://github.com/apache/geode/pull/6079
This test was closing a client socket before ensuring that a thread it
had created was finished. If the socket is closed quickly enough it
could cause that thread to get an IOException and cause the test to
fail.
The fix is to ensure that the thread is finished before closing the
client socket.
@kamilla1201
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced in
the commit message?
- [x] Has your PR been rebased against the latest commit within the target
branch (typically `develop`)?
- [x] Is your initial contribution a single, squashed commit?
- [x] Does `gradlew build` run cleanly?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
### Note:
Please ensure that once the PR is submitted, check Concourse for build
issues and
submit an update to your PR as soon as possible. If you need help, please
send an
email to d...@geode.apache.org.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> CI Failure: SSLSocketHostNameVerificationIntegrationTest
>
>
> Key: GEODE-8979
> URL: https://issues.apache.org/jira/browse/GEODE-8979
> Project: Geode
> Issue Type: Test
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
>
> This test failed in a CI IntegrationTest run with this exception:
> {noformat}
> org.apache.geode.internal.net.SSLSocketHostNameVerificationIntegrationTest >
> nioHandshakeValidatesHostName[hasSAN=true and doEndPointIdentification=true]
> FAILED
> org.apache.geode.GemFireIOException: exception closing SSL session
> at
> org.apache.geode.internal.net.NioSslEngine.close(NioSslEngine.java:409)
> at
> org.apache.geode.internal.net.SSLSocketHostNameVerificationIntegrationTest.lambda$startServerNIO$3(SSLSocketHostNameVerificationIntegrationTest.java:216)
> Caused by:
> java.io.IOException: Connection reset by peer
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:51)
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:470)
> at
> org.apache.geode.internal.net.NioSslEngine.close(NioSslEngine.java:403)
> ... 1 more
> {noformat}
> It looks like the test needs to have a try/catch for IOException when closing
> the NioSslEngine.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8979) CI Failure: SSLSocketHostNameVerificationIntegrationTest
[
https://issues.apache.org/jira/browse/GEODE-8979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-8979:
--
Labels: pull-request-available (was: )
> CI Failure: SSLSocketHostNameVerificationIntegrationTest
>
>
> Key: GEODE-8979
> URL: https://issues.apache.org/jira/browse/GEODE-8979
> Project: Geode
> Issue Type: Test
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
>
> This test failed in a CI IntegrationTest run with this exception:
> {noformat}
> org.apache.geode.internal.net.SSLSocketHostNameVerificationIntegrationTest >
> nioHandshakeValidatesHostName[hasSAN=true and doEndPointIdentification=true]
> FAILED
> org.apache.geode.GemFireIOException: exception closing SSL session
> at
> org.apache.geode.internal.net.NioSslEngine.close(NioSslEngine.java:409)
> at
> org.apache.geode.internal.net.SSLSocketHostNameVerificationIntegrationTest.lambda$startServerNIO$3(SSLSocketHostNameVerificationIntegrationTest.java:216)
> Caused by:
> java.io.IOException: Connection reset by peer
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:51)
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:470)
> at
> org.apache.geode.internal.net.NioSslEngine.close(NioSslEngine.java:403)
> ... 1 more
> {noformat}
> It looks like the test needs to have a try/catch for IOException when closing
> the NioSslEngine.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8994) Log line for EventId ctor potentially contains garbage string
[
https://issues.apache.org/jira/browse/GEODE-8994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-8994:
--
Labels: pull-request-available (was: )
> Log line for EventId ctor potentially contains garbage string
> -
>
> Key: GEODE-8994
> URL: https://issues.apache.org/jira/browse/GEODE-8994
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Blake Bender
>Assignee: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> The following logging was recently added to geode-native for debugging:
> ```
> LOGDEBUG("EventId::EventId(%p) - memId=%s, memIdLen=%d, thr=%" PRId64
> ", seq=%" PRId64, this, memId, memIdLen, thr, seq);
> ```
> The variable `memId` in this case is of type `char*` but is NOT a valid
> string, rather just a byte buffer. Logging it this way can potentially print
> out garbage, causing errors in parsing tools like gnmsg or other apps when
> attempting to read it. `memId` needs to be decoded into a string
> representation of the bytes, and that logged, rather than attempting to print
> it out raw.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8994) Log line for EventId ctor potentially contains garbage string
[
https://issues.apache.org/jira/browse/GEODE-8994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Bender reassigned GEODE-8994:
---
Assignee: Blake Bender
> Log line for EventId ctor potentially contains garbage string
> -
>
> Key: GEODE-8994
> URL: https://issues.apache.org/jira/browse/GEODE-8994
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Blake Bender
>Assignee: Blake Bender
>Priority: Major
>
> The following logging was recently added to geode-native for debugging:
> ```
> LOGDEBUG("EventId::EventId(%p) - memId=%s, memIdLen=%d, thr=%" PRId64
> ", seq=%" PRId64, this, memId, memIdLen, thr, seq);
> ```
> The variable `memId` in this case is of type `char*` but is NOT a valid
> string, rather just a byte buffer. Logging it this way can potentially print
> out garbage, causing errors in parsing tools like gnmsg or other apps when
> attempting to read it. `memId` needs to be decoded into a string
> representation of the bytes, and that logged, rather than attempting to print
> it out raw.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8994) Log line for EventId ctor potentially contains garbage string
Blake Bender created GEODE-8994:
---
Summary: Log line for EventId ctor potentially contains garbage
string
Key: GEODE-8994
URL: https://issues.apache.org/jira/browse/GEODE-8994
Project: Geode
Issue Type: Bug
Components: native client
Reporter: Blake Bender
The following logging was recently added to geode-native for debugging:
```
LOGDEBUG("EventId::EventId(%p) - memId=%s, memIdLen=%d, thr=%" PRId64
", seq=%" PRId64, this, memId, memIdLen, thr, seq);
```
The variable `memId` in this case is of type `char*` but is NOT a valid string,
rather just a byte buffer. Logging it this way can potentially print out
garbage, causing errors in parsing tools like gnmsg or other apps when
attempting to read it. `memId` needs to be decoded into a string
representation of the bytes, and that logged, rather than attempting to print
it out raw.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8972) remove shunnedMembers collection from GMSMembership
[ https://issues.apache.org/jira/browse/GEODE-8972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kamilla Aslami reassigned GEODE-8972: - Assignee: Kamilla Aslami > remove shunnedMembers collection from GMSMembership > --- > > Key: GEODE-8972 > URL: https://issues.apache.org/jira/browse/GEODE-8972 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Bruce J Schuchardt >Assignee: Kamilla Aslami >Priority: Major > > GMSMembership has a _shunnedMembers_ collection that is used to track the IDs > of nodes that are no longer part of the cluster. This collection is no > longer needed since we can tell if a node is old by comparing the view ID in > its identifier to that of the current view (called _latestView_ in that > class. Checks like this are already in place in some parts of the code. > All uses of _shunnedMembers_ should be replaced with this check. > MembershipView view = latestView; > boolean shunned = memberId.getVmViewId() <= view.getViewId() && > !view.contains(memberId); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-8993) Need Access to BuildBot for Storing Daily Builds
[ https://issues.apache.org/jira/browse/GEODE-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Martell closed GEODE-8993. -- > Need Access to BuildBot for Storing Daily Builds > > > Key: GEODE-8993 > URL: https://issues.apache.org/jira/browse/GEODE-8993 > Project: Geode > Issue Type: Wish > Components: native client >Reporter: Michael Martell >Priority: Major > > The Apache geode-native project would like to host daily build artifacts at > ci.apache.org using Buildbot. > Refiled as INFRA ticket, so closing this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8993) Need Access to BuildBot for Storing Daily Builds
[ https://issues.apache.org/jira/browse/GEODE-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Martell updated GEODE-8993: --- Description: The Apache geode-native project would like to host daily build artifacts at ci.apache.org using Buildbot. Refiled as INFRA ticket, so closing this. was:The Apache geode-native project would like to host daily build artifacts at ci.apache.org using Buildbot. > Need Access to BuildBot for Storing Daily Builds > > > Key: GEODE-8993 > URL: https://issues.apache.org/jira/browse/GEODE-8993 > Project: Geode > Issue Type: Wish > Components: native client >Reporter: Michael Martell >Priority: Major > > The Apache geode-native project would like to host daily build artifacts at > ci.apache.org using Buildbot. > Refiled as INFRA ticket, so closing this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8993) Need Access to BuildBot for Storing Daily Builds
[ https://issues.apache.org/jira/browse/GEODE-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Martell resolved GEODE-8993. Resolution: Invalid > Need Access to BuildBot for Storing Daily Builds > > > Key: GEODE-8993 > URL: https://issues.apache.org/jira/browse/GEODE-8993 > Project: Geode > Issue Type: Wish > Components: native client >Reporter: Michael Martell >Priority: Major > > The Apache geode-native project would like to host daily build artifacts at > ci.apache.org using Buildbot. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8979) CI Failure: SSLSocketHostNameVerificationIntegrationTest
[
https://issues.apache.org/jira/browse/GEODE-8979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt reassigned GEODE-8979:
-
Assignee: Bruce J Schuchardt
> CI Failure: SSLSocketHostNameVerificationIntegrationTest
>
>
> Key: GEODE-8979
> URL: https://issues.apache.org/jira/browse/GEODE-8979
> Project: Geode
> Issue Type: Test
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
>
> This test failed in a CI IntegrationTest run with this exception:
> {noformat}
> org.apache.geode.internal.net.SSLSocketHostNameVerificationIntegrationTest >
> nioHandshakeValidatesHostName[hasSAN=true and doEndPointIdentification=true]
> FAILED
> org.apache.geode.GemFireIOException: exception closing SSL session
> at
> org.apache.geode.internal.net.NioSslEngine.close(NioSslEngine.java:409)
> at
> org.apache.geode.internal.net.SSLSocketHostNameVerificationIntegrationTest.lambda$startServerNIO$3(SSLSocketHostNameVerificationIntegrationTest.java:216)
> Caused by:
> java.io.IOException: Connection reset by peer
> at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> at sun.nio.ch.IOUtil.write(IOUtil.java:51)
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:470)
> at
> org.apache.geode.internal.net.NioSslEngine.close(NioSslEngine.java:403)
> ... 1 more
> {noformat}
> It looks like the test needs to have a try/catch for IOException when closing
> the NioSslEngine.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8905) Introduce JarDeploymentService
[ https://issues.apache.org/jira/browse/GEODE-8905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293949#comment-17293949 ] ASF GitHub Bot commented on GEODE-8905: --- kohlmu-pivotal opened a new pull request #6078: URL: https://github.com/apache/geode/pull/6078 This reverts commit e32c3076 Thank you for submitting a contribution to Apache Geode. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Has your PR been rebased against the latest commit within the target branch (typically `develop`)? - [ ] Is your initial contribution a single, squashed commit? - [ ] Does `gradlew build` run cleanly? - [ ] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? ### Note: Please ensure that once the PR is submitted, check Concourse for build issues and submit an update to your PR as soon as possible. If you need help, please send an email to d...@geode.apache.org. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Introduce JarDeploymentService > -- > > Key: GEODE-8905 > URL: https://issues.apache.org/jira/browse/GEODE-8905 > Project: Geode > Issue Type: Improvement > Components: gfsh, management >Reporter: Patrick Johnsn >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > > Introduce a JarDeploymentService interface that will allow us to interchange > the current way of deploying jars with the new modular approach. > > There will be an implementation that delegates to the existing JarDeployer > and will maintain current behavior. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8949) Create a Continuous Integration Pipeline
[ https://issues.apache.org/jira/browse/GEODE-8949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293944#comment-17293944 ] ASF GitHub Bot commented on GEODE-8949: --- pdxcodemonkey merged pull request #754: URL: https://github.com/apache/geode-native/pull/754 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Create a Continuous Integration Pipeline > > > Key: GEODE-8949 > URL: https://issues.apache.org/jira/browse/GEODE-8949 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > > This will be our open source CI for publishing to the Apache Software > Foundation. Two primary tenets are: > * based on Concourse > * PRs will trigger the CI pipeline and can't be merged until they pass the CI > Note: The bulk of this work has been completed in draft [PR > #716|http://github.com/apache/geode-native/pull/716]. See that PR for further > details. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8949) Create a Continuous Integration Pipeline
[ https://issues.apache.org/jira/browse/GEODE-8949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293943#comment-17293943 ] ASF subversion and git services commented on GEODE-8949: Commit 38fa9eef45da2a0743410d24c5852e8dd3a69494 in geode-native's branch refs/heads/develop from Jacob Barrett [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=38fa9ee ] GEODE-8949: Versioning improvements (#754) * Download latest Geode. * Don't bake Geode into images. * Trigger packer images. * Configurable version for semver and geode resource. * Adds version bump. * Uses geode latest in source checks. > Create a Continuous Integration Pipeline > > > Key: GEODE-8949 > URL: https://issues.apache.org/jira/browse/GEODE-8949 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > > This will be our open source CI for publishing to the Apache Software > Foundation. Two primary tenets are: > * based on Concourse > * PRs will trigger the CI pipeline and can't be merged until they pass the CI > Note: The bulk of this work has been completed in draft [PR > #716|http://github.com/apache/geode-native/pull/716]. See that PR for further > details. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8975) Correct naming in SnapshotOptions
[ https://issues.apache.org/jira/browse/GEODE-8975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett resolved GEODE-8975. -- Fix Version/s: 1.15.0 Resolution: Fixed > Correct naming in SnapshotOptions > - > > Key: GEODE-8975 > URL: https://issues.apache.org/jira/browse/GEODE-8975 > Project: Geode > Issue Type: Improvement > Components: snapshot >Reporter: Jacob Barrett >Assignee: Jacob Barrett >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > SnapshotOptions uses the pre-Geode product name. Correct this to use Geode. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8975) Correct naming in SnapshotOptions
[ https://issues.apache.org/jira/browse/GEODE-8975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293928#comment-17293928 ] ASF subversion and git services commented on GEODE-8975: Commit a9b25a14f71edcd4cf4072f5e2148c21abd64a02 in geode's branch refs/heads/develop from Jacob Barrett [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a9b25a14 ] GEODE-8975: Deprecate old format. (#6058) Deprecates old format name. Creates new format name. > Correct naming in SnapshotOptions > - > > Key: GEODE-8975 > URL: https://issues.apache.org/jira/browse/GEODE-8975 > Project: Geode > Issue Type: Improvement > Components: snapshot >Reporter: Jacob Barrett >Assignee: Jacob Barrett >Priority: Major > Labels: pull-request-available > > SnapshotOptions uses the pre-Geode product name. Correct this to use Geode. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8975) Correct naming in SnapshotOptions
[ https://issues.apache.org/jira/browse/GEODE-8975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293927#comment-17293927 ] ASF GitHub Bot commented on GEODE-8975: --- pivotal-jbarrett merged pull request #6058: URL: https://github.com/apache/geode/pull/6058 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Correct naming in SnapshotOptions > - > > Key: GEODE-8975 > URL: https://issues.apache.org/jira/browse/GEODE-8975 > Project: Geode > Issue Type: Improvement > Components: snapshot >Reporter: Jacob Barrett >Assignee: Jacob Barrett >Priority: Major > Labels: pull-request-available > > SnapshotOptions uses the pre-Geode product name. Correct this to use Geode. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8856) Persist gateway-sender state within Cluster Configuration
[ https://issues.apache.org/jira/browse/GEODE-8856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293925#comment-17293925 ] ASF GitHub Bot commented on GEODE-8856: --- mhansonp commented on pull request #6036: URL: https://github.com/apache/geode/pull/6036#issuecomment-789133902 Restarted concourse-ci/DistributedTestOpenJDK11 run. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Persist gateway-sender state within Cluster Configuration > - > > Key: GEODE-8856 > URL: https://issues.apache.org/jira/browse/GEODE-8856 > Project: Geode > Issue Type: Improvement >Reporter: Jakov Varenina >Assignee: Jakov Varenina >Priority: Major > Labels: pull-request-available > > More details in following RFC: > https://cwiki.apache.org/confluence/display/GEODE/Persist+gateway-sender+state+within+Cluster+Configuration?moved=true > All changes or findings during development will be reflected in above RFC. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8949) Create a Continuous Integration Pipeline
[ https://issues.apache.org/jira/browse/GEODE-8949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293919#comment-17293919 ] ASF GitHub Bot commented on GEODE-8949: --- pivotal-jbarrett commented on a change in pull request #754: URL: https://github.com/apache/geode-native/pull/754#discussion_r585822577 ## File path: ci/lib/templates.lib.txt ## @@ -90,7 +90,7 @@ run-clang-tidy -j $(nproc) -quiet (@ def clang_format_bash_task(): -@) set -ueo pipefail -export GEODE_HOME=$(pwd)/geode/expanded/apache-geode-$(cat geode/version) +export GEODE_HOME=$(pwd)/geode Review comment: Sort of out of scope for this PR. I agree making them consistent would be nice. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Create a Continuous Integration Pipeline > > > Key: GEODE-8949 > URL: https://issues.apache.org/jira/browse/GEODE-8949 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > > This will be our open source CI for publishing to the Apache Software > Foundation. Two primary tenets are: > * based on Concourse > * PRs will trigger the CI pipeline and can't be merged until they pass the CI > Note: The bulk of this work has been completed in draft [PR > #716|http://github.com/apache/geode-native/pull/716]. See that PR for further > details. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8993) Need Access to BuildBot for Storing Daily Builds
Michael Martell created GEODE-8993: -- Summary: Need Access to BuildBot for Storing Daily Builds Key: GEODE-8993 URL: https://issues.apache.org/jira/browse/GEODE-8993 Project: Geode Issue Type: Wish Components: native client Reporter: Michael Martell The Apache geode-native project would like to host daily build artifacts at ci.apache.org using Buildbot. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8950) Benchmark failure - P2pPartitionedPutLongBenchmark
[ https://issues.apache.org/jira/browse/GEODE-8950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293905#comment-17293905 ] Geode Integration commented on GEODE-8950: -- Seen in [Benchmark_base #45|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/45]. > Benchmark failure - P2pPartitionedPutLongBenchmark > -- > > Key: GEODE-8950 > URL: https://issues.apache.org/jira/browse/GEODE-8950 > Project: Geode > Issue Type: Bug > Components: benchmarks >Affects Versions: 1.15.0 >Reporter: Donal Evans >Assignee: Hale Bales >Priority: Major > > Multiple benchmark failures due to P2pPartitionedPutLongBenchmark have been > seen recently. > This run saw 3 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/16|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/16#L601ed52d:5552] > This run saw 1 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/20] > This run saw 4 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/27] > In all the above benchmarks, the other failed runs were due to EOFExceptions > rather than flagged degradations. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8862) DLockRecoverGrantorProcessor.recoverLockGrantor sometimes hangs
[
https://issues.apache.org/jira/browse/GEODE-8862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293902#comment-17293902
]
ASF GitHub Bot commented on GEODE-8862:
---
pivotal-eshu commented on a change in pull request #6051:
URL: https://github.com/apache/geode/pull/6051#discussion_r585803394
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/DistributedCacheOperation.java
##
@@ -1107,6 +1107,10 @@ protected void process(final ClusterDistributionManager
dm) {
final LocalRegion lclRgn = getLocalRegionForProcessing(dm);
sendReply = false;
+if (lclRgn != null && lclRgn.getScope().isDistributedNoAck()) {
+ dm.getExecutors().getWaitingThreadPool().execute(() ->
basicProcess(dm, lclRgn));
Review comment:
I believe it is intentional. We do not want to pollute the user logging.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> DLockRecoverGrantorProcessor.recoverLockGrantor sometimes hangs
> ---
>
> Key: GEODE-8862
> URL: https://issues.apache.org/jira/browse/GEODE-8862
> Project: Geode
> Issue Type: Bug
> Components: distributed lock service
>Affects Versions: 1.14.0
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
>
> "vm_9_thr_27_persist8_host1_29953" #1448 daemon prio=5 os_prio=0 cpu=45.99ms
> elapsed=698.42s tid=0x7f8d0c052800 nid=0x2ee8 waiting on condition
> [0x7f8c354f6000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at jdk.internal.misc.Unsafe.park(java.base@11.0.9/Native Method)
> - parking to wait for <0xfb7bb488> (a
> java.util.concurrent.CountDownLatch$Sync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(java.base@11.0.9/LockSupport.java:234)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(java.base@11.0.9/AbstractQueuedSynchronizer.java:1079)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(java.base@11.0.9/AbstractQueuedSynchronizer.java:1369)
> at
> java.util.concurrent.CountDownLatch.await(java.base@11.0.9/CountDownLatch.java:278)
> at
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:723)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:794)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:771)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:857)
> at
> org.apache.geode.distributed.internal.locks.DLockRecoverGrantorProcessor.recoverLockGrantor(DLockRecoverGrantorProcessor.java:100)
> at
> org.apache.geode.distributed.internal.locks.DLockService.makeLocalGrantor(DLockService.java:447)
> at
> org.apache.geode.distributed.internal.locks.DLockService.createLocalGrantor(DLockService.java:392)
> at
> org.apache.geode.distributed.internal.locks.DLockService.getLockGrantorId(DLockService.java:337)
> at
> org.apache.geode.distributed.internal.locks.DLockService.lockInterruptibly(DLockService.java:1445)
> at
> org.apache.geode.distributed.internal.locks.DLockService.lock(DLockService.java:1241)
> at
> org.apache.geode.distributed.internal.locks.DLockService.lock(DLockService.java:1232)
> at
> org.apache.geode.distributed.internal.locks.DLockService.lock(DLockService.java:1227)
> at
> org.apache.geode.distributed.internal.locks.DLockService.lock(DLockService.java:1223)
> at
> org.apache.geode.pdx.internal.PeerTypeRegistration.lock(PeerTypeRegistration.java:314)
> at
> org.apache.geode.pdx.internal.PeerTypeRegistration.defineEnum(PeerTypeRegistration.java:646)
> at
> org.apache.geode.pdx.internal.PeerTypeRegistration.getEnumId(PeerTypeRegistration.java:601)
> at
> org.apache.geode.pdx.internal.TypeRegistry.getEnumId(TypeRegistry.java:363)
> at
> org.apache.geode.internal.InternalDataSerializer.writePdxEnum(InternalDataSerializer.java:2071)
> at
> org.apache.geode.internal.InternalDataSerializer.writeUserObject(InternalDataSerializer.java:1610)
> at
> org
[jira] [Commented] (GEODE-8983) CI Failure: DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
[
https://issues.apache.org/jira/browse/GEODE-8983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293901#comment-17293901
]
Geode Integration commented on GEODE-8983:
--
Seen in [DistributedTestOpenJDK11
#52|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/52]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0024/test-results/distributedTest/1614650146/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0024/test-artifacts/1614650146/distributedtestfiles-OpenJDK11-1.15.0-build.0024.tgz].
> CI Failure:
> DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
> --
>
> Key: GEODE-8983
> URL: https://issues.apache.org/jira/browse/GEODE-8983
> Project: Geode
> Issue Type: Bug
> Components: functions, management
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Udo Kohlmeyer
>Priority: Major
> Labels: pull-request-available
>
> {noformat}
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest
> > hotDeployShouldNotResultInAnyFailedFunctionExecutions FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest$$Lambda$422/0x00010059f840.run
> in VM 1 running on Host 91f54af25dd2 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:94)
> at
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions(DeploymentManagementRedployDUnitTest.java:184)
> Caused by:
> org.apache.geode.cache.execute.FunctionException: Function named
> DeployCommandRedeployDUnitFunctionA is not registered to FunctionService
> 371 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614547395/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614547395/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
> This failure was also seen in a previous run, along with an instance of
> GEODE-8984. Artifacts for that failure can be found here:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614538872/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614538872/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8990) CI Failure: Jetty9CachingClientServerTest.shouldCacheSessionOnClient
[
https://issues.apache.org/jira/browse/GEODE-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293900#comment-17293900
]
Geode Integration commented on GEODE-8990:
--
Seen in [DistributedTestOpenJDK8
#47|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/47]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0024/test-results/distributedTest/1614649633/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0024/test-artifacts/1614649633/distributedtestfiles-OpenJDK8-1.15.0-build.0024.tgz].
> CI Failure: Jetty9CachingClientServerTest.shouldCacheSessionOnClient
>
>
> Key: GEODE-8990
> URL: https://issues.apache.org/jira/browse/GEODE-8990
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Priority: Major
>
> {noformat}
> org.apache.geode.session.tests.Jetty9CachingClientServerTest >
> shouldCacheSessionOnClient FAILED
> org.junit.ComparisonFailure: expected:<[Foo]> but was:<[bogus]>
> at org.junit.Assert.assertEquals(Assert.java:117)
> at org.junit.Assert.assertEquals(Assert.java:146)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.shouldCacheSessionOnClient(Jetty9CachingClientServerTest.java:65)
> 371 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0023/test-results/distributedTest/1614646829/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0023/test-artifacts/1614646829/distributedtestfiles-OpenJDK8-1.15.0-build.0023.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8963) separate client/server compatibility from server/server version compatibility
[
https://issues.apache.org/jira/browse/GEODE-8963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt resolved GEODE-8963.
---
Fix Version/s: 1.15.0
Resolution: Fixed
> separate client/server compatibility from server/server version compatibility
> -
>
> Key: GEODE-8963
> URL: https://issues.apache.org/jira/browse/GEODE-8963
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> A client's version is used for deserializing data received from the client
> and for serializing data sent to the client. It is also used to locate the
> map of Commands used to process client requests. Every time we cut a new
> release we bump this version in KnownVersions and create a new map of
> Commands, even though client/server communications protocols rarely change.
> We should have each KnownVersion hold a client/server compatibility number
> that is used to identify clients rather than the KnownVersion's ordinal.
> For instance,
> {code:java}
> public static final KnownVersion GEODE_1_15_0 =
> new KnownVersion("GEODE", "1.15.0", (byte) 1, (byte) 15, (byte) 0,
> (byte) 0,
> /*server/server version*/GEODE_1_15_0_ORDINAL,
> /*client/server version*/GEODE_1_15_0_ORDINAL);
>
> public static final KnownVersion GEODE_1_16_0 =
> new KnownVersion("GEODE", "1.16.0", (byte) 1, (byte) 16, (byte) 0,
> (byte) 0,
> /*server/server version*/GEODE_1_16_0_ORDINAL,
> /*client/server version*/GEODE_1_15_0_ORDINAL);
> public static final KnownVersion GEODE_1_17_0 =
> new KnownVersion("GEODE", "1.17.0", (byte) 1, (byte) 17, (byte) 0,
> (byte) 0,
> /*server/server version*/GEODE_1_17_0_ORDINAL,
> /*client/server version*/GEODE_1_15_0_ORDINAL);
> {code}
> In the above KnownVersions the client/server serialization is known to have
> not changed since v1.15.0 and so there is no need to use a newer KnownVersion
> for clients.
> Client handshake code will need to be changed to use the client/server
> ordinal when identifying clients and servers.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8963) separate client/server compatibility from server/server version compatibility
[
https://issues.apache.org/jira/browse/GEODE-8963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293898#comment-17293898
]
ASF subversion and git services commented on GEODE-8963:
Commit dc3ed8c1af4389f60c8ad8e35c43a72731869dcc in geode's branch
refs/heads/develop from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=dc3ed8c ]
GEODE-8963: separate client/server compatibility from server/server version
compatibility (#6050)
* GEODE-8963: separate client/server compatibility from server/server version
compatibility
A client's version is used for deserializing data received from the client and
for
serializing data sent to the client. It is also used to locate the map of
Commands
used to process client requests. Every time we cut a new release we bump this
version
in KnownVersions and create a new map of Commands, even though client/server
communications protocols rarely change.
This PR changes KnownVersions to hold a client/server protocol version that is
used to identify clients for command-table selection and serialization rather
than
the client's CURRENT_VERSION.
* Donal's comments addressed and WAN problem fixed
* refactored a method with Bill and made ServerConnection code clearer
Altered KnownVersions to just mark each version that has client/server
protocol changes rather than store the last one having changes in the
more recent instances. Release managers can continue to use the old
constructor and coders can change to the new constructor if necessary
during the course of a release.
> separate client/server compatibility from server/server version compatibility
> -
>
> Key: GEODE-8963
> URL: https://issues.apache.org/jira/browse/GEODE-8963
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> A client's version is used for deserializing data received from the client
> and for serializing data sent to the client. It is also used to locate the
> map of Commands used to process client requests. Every time we cut a new
> release we bump this version in KnownVersions and create a new map of
> Commands, even though client/server communications protocols rarely change.
> We should have each KnownVersion hold a client/server compatibility number
> that is used to identify clients rather than the KnownVersion's ordinal.
> For instance,
> {code:java}
> public static final KnownVersion GEODE_1_15_0 =
> new KnownVersion("GEODE", "1.15.0", (byte) 1, (byte) 15, (byte) 0,
> (byte) 0,
> /*server/server version*/GEODE_1_15_0_ORDINAL,
> /*client/server version*/GEODE_1_15_0_ORDINAL);
>
> public static final KnownVersion GEODE_1_16_0 =
> new KnownVersion("GEODE", "1.16.0", (byte) 1, (byte) 16, (byte) 0,
> (byte) 0,
> /*server/server version*/GEODE_1_16_0_ORDINAL,
> /*client/server version*/GEODE_1_15_0_ORDINAL);
> public static final KnownVersion GEODE_1_17_0 =
> new KnownVersion("GEODE", "1.17.0", (byte) 1, (byte) 17, (byte) 0,
> (byte) 0,
> /*server/server version*/GEODE_1_17_0_ORDINAL,
> /*client/server version*/GEODE_1_15_0_ORDINAL);
> {code}
> In the above KnownVersions the client/server serialization is known to have
> not changed since v1.15.0 and so there is no need to use a newer KnownVersion
> for clients.
> Client handshake code will need to be changed to use the client/server
> ordinal when identifying clients and servers.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8963) separate client/server compatibility from server/server version compatibility
[
https://issues.apache.org/jira/browse/GEODE-8963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293899#comment-17293899
]
ASF subversion and git services commented on GEODE-8963:
Commit dc3ed8c1af4389f60c8ad8e35c43a72731869dcc in geode's branch
refs/heads/develop from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=dc3ed8c ]
GEODE-8963: separate client/server compatibility from server/server version
compatibility (#6050)
* GEODE-8963: separate client/server compatibility from server/server version
compatibility
A client's version is used for deserializing data received from the client and
for
serializing data sent to the client. It is also used to locate the map of
Commands
used to process client requests. Every time we cut a new release we bump this
version
in KnownVersions and create a new map of Commands, even though client/server
communications protocols rarely change.
This PR changes KnownVersions to hold a client/server protocol version that is
used to identify clients for command-table selection and serialization rather
than
the client's CURRENT_VERSION.
* Donal's comments addressed and WAN problem fixed
* refactored a method with Bill and made ServerConnection code clearer
Altered KnownVersions to just mark each version that has client/server
protocol changes rather than store the last one having changes in the
more recent instances. Release managers can continue to use the old
constructor and coders can change to the new constructor if necessary
during the course of a release.
> separate client/server compatibility from server/server version compatibility
> -
>
> Key: GEODE-8963
> URL: https://issues.apache.org/jira/browse/GEODE-8963
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> A client's version is used for deserializing data received from the client
> and for serializing data sent to the client. It is also used to locate the
> map of Commands used to process client requests. Every time we cut a new
> release we bump this version in KnownVersions and create a new map of
> Commands, even though client/server communications protocols rarely change.
> We should have each KnownVersion hold a client/server compatibility number
> that is used to identify clients rather than the KnownVersion's ordinal.
> For instance,
> {code:java}
> public static final KnownVersion GEODE_1_15_0 =
> new KnownVersion("GEODE", "1.15.0", (byte) 1, (byte) 15, (byte) 0,
> (byte) 0,
> /*server/server version*/GEODE_1_15_0_ORDINAL,
> /*client/server version*/GEODE_1_15_0_ORDINAL);
>
> public static final KnownVersion GEODE_1_16_0 =
> new KnownVersion("GEODE", "1.16.0", (byte) 1, (byte) 16, (byte) 0,
> (byte) 0,
> /*server/server version*/GEODE_1_16_0_ORDINAL,
> /*client/server version*/GEODE_1_15_0_ORDINAL);
> public static final KnownVersion GEODE_1_17_0 =
> new KnownVersion("GEODE", "1.17.0", (byte) 1, (byte) 17, (byte) 0,
> (byte) 0,
> /*server/server version*/GEODE_1_17_0_ORDINAL,
> /*client/server version*/GEODE_1_15_0_ORDINAL);
> {code}
> In the above KnownVersions the client/server serialization is known to have
> not changed since v1.15.0 and so there is no need to use a newer KnownVersion
> for clients.
> Client handshake code will need to be changed to use the client/server
> ordinal when identifying clients and servers.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8963) separate client/server compatibility from server/server version compatibility
[
https://issues.apache.org/jira/browse/GEODE-8963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293897#comment-17293897
]
ASF GitHub Bot commented on GEODE-8963:
---
bschuchardt merged pull request #6050:
URL: https://github.com/apache/geode/pull/6050
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> separate client/server compatibility from server/server version compatibility
> -
>
> Key: GEODE-8963
> URL: https://issues.apache.org/jira/browse/GEODE-8963
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Minor
> Labels: pull-request-available
>
> A client's version is used for deserializing data received from the client
> and for serializing data sent to the client. It is also used to locate the
> map of Commands used to process client requests. Every time we cut a new
> release we bump this version in KnownVersions and create a new map of
> Commands, even though client/server communications protocols rarely change.
> We should have each KnownVersion hold a client/server compatibility number
> that is used to identify clients rather than the KnownVersion's ordinal.
> For instance,
> {code:java}
> public static final KnownVersion GEODE_1_15_0 =
> new KnownVersion("GEODE", "1.15.0", (byte) 1, (byte) 15, (byte) 0,
> (byte) 0,
> /*server/server version*/GEODE_1_15_0_ORDINAL,
> /*client/server version*/GEODE_1_15_0_ORDINAL);
>
> public static final KnownVersion GEODE_1_16_0 =
> new KnownVersion("GEODE", "1.16.0", (byte) 1, (byte) 16, (byte) 0,
> (byte) 0,
> /*server/server version*/GEODE_1_16_0_ORDINAL,
> /*client/server version*/GEODE_1_15_0_ORDINAL);
> public static final KnownVersion GEODE_1_17_0 =
> new KnownVersion("GEODE", "1.17.0", (byte) 1, (byte) 17, (byte) 0,
> (byte) 0,
> /*server/server version*/GEODE_1_17_0_ORDINAL,
> /*client/server version*/GEODE_1_15_0_ORDINAL);
> {code}
> In the above KnownVersions the client/server serialization is known to have
> not changed since v1.15.0 and so there is no need to use a newer KnownVersion
> for clients.
> Client handshake code will need to be changed to use the client/server
> ordinal when identifying clients and servers.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8905) Introduce JarDeploymentService
[ https://issues.apache.org/jira/browse/GEODE-8905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293896#comment-17293896 ] Geode Integration commented on GEODE-8905: -- Seen in [WindowsAcceptanceTestOpenJDK11 #44|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsAcceptanceTestOpenJDK11/builds/44] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0024/test-results/acceptanceTest/1614652592/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0024/test-artifacts/1614652592/windows-acceptancetestfiles-OpenJDK11-1.15.0-build.0024.tgz]. > Introduce JarDeploymentService > -- > > Key: GEODE-8905 > URL: https://issues.apache.org/jira/browse/GEODE-8905 > Project: Geode > Issue Type: Improvement > Components: gfsh, management >Reporter: Patrick Johnsn >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > > Introduce a JarDeploymentService interface that will allow us to interchange > the current way of deploying jars with the new modular approach. > > There will be an implementation that delegates to the existing JarDeployer > and will maintain current behavior. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8905) Introduce JarDeploymentService
[ https://issues.apache.org/jira/browse/GEODE-8905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293895#comment-17293895 ] Geode Integration commented on GEODE-8905: -- Seen in [WindowsAcceptanceTestOpenJDK8 #43|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsAcceptanceTestOpenJDK8/builds/43] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0024/test-results/acceptanceTest/1614649652/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0024/test-artifacts/1614649652/windows-acceptancetestfiles-OpenJDK8-1.15.0-build.0024.tgz]. > Introduce JarDeploymentService > -- > > Key: GEODE-8905 > URL: https://issues.apache.org/jira/browse/GEODE-8905 > Project: Geode > Issue Type: Improvement > Components: gfsh, management >Reporter: Patrick Johnsn >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > > Introduce a JarDeploymentService interface that will allow us to interchange > the current way of deploying jars with the new modular approach. > > There will be an implementation that delegates to the existing JarDeployer > and will maintain current behavior. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8920) Modify debug logging to make it easier to trace a message
[ https://issues.apache.org/jira/browse/GEODE-8920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kamilla Aslami updated GEODE-8920: -- Fix Version/s: 1.14.0 > Modify debug logging to make it easier to trace a message > - > > Key: GEODE-8920 > URL: https://issues.apache.org/jira/browse/GEODE-8920 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Bruce J Schuchardt >Assignee: Kamilla Aslami >Priority: Major > Labels: blocks-1.14.0, pull-request-available > Fix For: 1.14.0, 1.15.0 > > > Debug logging in DirectChannel lets us know the IDs of receivers of a message > and the toString of the message but it's very difficult to figure out what > thread on the receiving end is supposed to process that message. > Here's an example of what we currently have: > [debug 2021/02/01 16:15:17.492 PST persistgemfire8_host1_8586 > tid=0x4f0] Sending > (DLockRequestProcessor.DLockResponseMessage responding GRANT; > serviceName=__PDX(version 4); objectName=PDX_LOCK; responseCode=0; > keyIfFailed=null; leaseExpireTime=9223372036854775807; processorId=509; > lockId=509) to 1 peers > ([rs-GEM-3166-PL1535a2i32xlarge-hydra-client-36(persistgemfire9_host1_8517:8517):41005]) > via tcp/ip > This does not tell you anything about the receiver except its ID. On the > receiving side the thread that, in this run, would handle that message is > this: > persistgemfire9_host1_8517 rs-GEM-3166-PL1535a2i32xlarge-hydra-client-36(persistgemfire8_host1_8586:8586):41006 > unshared ordered *uid=1036* dom #1 local port=47207 remote port=42068> > tid=0x51 > I've highlighted the *uid* here because that is the _uniqueId_ of the sending > Connection. If you looked through the logs or stack traces of the receiver > and knew the uniqueId of the sending Connection you could easily locate the > thread that should receive this DLockResponseMessage. Currently this is much > harder than it needs to be because the DirectChannel _Sending_ log message > doesn't include the _uniqueId_ of the Connections it is using to send the > message. > Let's change that log message to include the _uniqueId_ of each outgoing > Connection. Maybe something like this: > Sending (message.toString()) to 1 peers (peer ID)*, uid=1036* via tcp/ip > and on the receiving side we could be clearer about what the *uid* in the > thread's name means: > persistgemfire9_host1_8517 rs-GEM-3166-PL1535a2i32xlarge-hydra-client-36(persistgemfire8_host1_8586:8586):41006 > unshared ordered *sender uid=1036* dom #1 local port=47207 remote > port=42068> tid=0x51 > or something like that. > Now we can look at the _Sending_ message and know that the receiving thread > will have _uid=1036_ in its name. Knowing this it ought to be possible to > write a program/script to trace a message and its consequences from one node > to another. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7245) Remove most uses of latestViewReadLock in GMSMembershipManager
[ https://issues.apache.org/jira/browse/GEODE-7245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kamilla Aslami resolved GEODE-7245. --- Fix Version/s: 1.15.0 Resolution: Fixed > Remove most uses of latestViewReadLock in GMSMembershipManager > -- > > Key: GEODE-7245 > URL: https://issues.apache.org/jira/browse/GEODE-7245 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Bruce J Schuchardt >Assignee: Kamilla Aslami >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Changes for GEODE-7196 made the latestView immutable so there is no reason, > in most cases, to use the latestViewReadlock when accessing the view. A > simple volatile read of the field & storing the value in a method variable > can replace most uses of the latestViewReadLock, especially those uses that > are in the path of sending or receiving messages. > Performance could be measured with our benchmarks to see if this change helps. > > latestViewReadLock is currently used in getCoordinator(), memberExists(), > getMembersNotShuttingDown(), getAllMembers(), isShunnedOrNew(), > isSurpriseMember(), doWithViewLocked(). > doWithViewLocked() is used to add membership listeners, and we don't want the > view to change until this operation completes. Therefore, we should keep the > lock in this method. > getCoordinator(), memberExists(), getMembersNotShuttingDown(), > getAllMembers() use latestViewReadLock to access latestView. In these methods > we can replace the lock with a volatile read of the latestView and storing > the value in a method variable. > isShunnedOrNew() accesses latestView, and 2 ConcurrentHashMaps - > shunnedMembers and surpriseMembers. Since the hashmaps are concurrent and > latestView is unmodifiable, a volatile read could replace the lock. Same for > isSurpriseMember(), which uses surpriseMembers hashmap. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7245) Remove most uses of latestViewReadLock in GMSMembershipManager
[ https://issues.apache.org/jira/browse/GEODE-7245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kamilla Aslami reassigned GEODE-7245: - Assignee: Kamilla Aslami > Remove most uses of latestViewReadLock in GMSMembershipManager > -- > > Key: GEODE-7245 > URL: https://issues.apache.org/jira/browse/GEODE-7245 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Bruce J Schuchardt >Assignee: Kamilla Aslami >Priority: Major > Labels: pull-request-available > > Changes for GEODE-7196 made the latestView immutable so there is no reason, > in most cases, to use the latestViewReadlock when accessing the view. A > simple volatile read of the field & storing the value in a method variable > can replace most uses of the latestViewReadLock, especially those uses that > are in the path of sending or receiving messages. > Performance could be measured with our benchmarks to see if this change helps. > > latestViewReadLock is currently used in getCoordinator(), memberExists(), > getMembersNotShuttingDown(), getAllMembers(), isShunnedOrNew(), > isSurpriseMember(), doWithViewLocked(). > doWithViewLocked() is used to add membership listeners, and we don't want the > view to change until this operation completes. Therefore, we should keep the > lock in this method. > getCoordinator(), memberExists(), getMembersNotShuttingDown(), > getAllMembers() use latestViewReadLock to access latestView. In these methods > we can replace the lock with a volatile read of the latestView and storing > the value in a method variable. > isShunnedOrNew() accesses latestView, and 2 ConcurrentHashMaps - > shunnedMembers and surpriseMembers. Since the hashmaps are concurrent and > latestView is unmodifiable, a volatile read could replace the lock. Same for > isSurpriseMember(), which uses surpriseMembers hashmap. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8920) Modify debug logging to make it easier to trace a message
[ https://issues.apache.org/jira/browse/GEODE-8920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293886#comment-17293886 ] ASF subversion and git services commented on GEODE-8920: Commit bce7a19b55b51a8809e71c9a2c776eba31a4e92c in geode's branch refs/heads/support/1.14 from Kamilla Aslami [ https://gitbox.apache.org/repos/asf?p=geode.git;h=bce7a19 ] GEODE-8920: Modify debug logging to make it easier to trace a message (#6041) (#6071) (cherry picked from commit fc2fc9f890c5673bd6d0954048efb525b0098126) > Modify debug logging to make it easier to trace a message > - > > Key: GEODE-8920 > URL: https://issues.apache.org/jira/browse/GEODE-8920 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Bruce J Schuchardt >Assignee: Kamilla Aslami >Priority: Major > Labels: blocks-1.14.0, pull-request-available > Fix For: 1.15.0 > > > Debug logging in DirectChannel lets us know the IDs of receivers of a message > and the toString of the message but it's very difficult to figure out what > thread on the receiving end is supposed to process that message. > Here's an example of what we currently have: > [debug 2021/02/01 16:15:17.492 PST persistgemfire8_host1_8586 > tid=0x4f0] Sending > (DLockRequestProcessor.DLockResponseMessage responding GRANT; > serviceName=__PDX(version 4); objectName=PDX_LOCK; responseCode=0; > keyIfFailed=null; leaseExpireTime=9223372036854775807; processorId=509; > lockId=509) to 1 peers > ([rs-GEM-3166-PL1535a2i32xlarge-hydra-client-36(persistgemfire9_host1_8517:8517):41005]) > via tcp/ip > This does not tell you anything about the receiver except its ID. On the > receiving side the thread that, in this run, would handle that message is > this: > persistgemfire9_host1_8517 rs-GEM-3166-PL1535a2i32xlarge-hydra-client-36(persistgemfire8_host1_8586:8586):41006 > unshared ordered *uid=1036* dom #1 local port=47207 remote port=42068> > tid=0x51 > I've highlighted the *uid* here because that is the _uniqueId_ of the sending > Connection. If you looked through the logs or stack traces of the receiver > and knew the uniqueId of the sending Connection you could easily locate the > thread that should receive this DLockResponseMessage. Currently this is much > harder than it needs to be because the DirectChannel _Sending_ log message > doesn't include the _uniqueId_ of the Connections it is using to send the > message. > Let's change that log message to include the _uniqueId_ of each outgoing > Connection. Maybe something like this: > Sending (message.toString()) to 1 peers (peer ID)*, uid=1036* via tcp/ip > and on the receiving side we could be clearer about what the *uid* in the > thread's name means: > persistgemfire9_host1_8517 rs-GEM-3166-PL1535a2i32xlarge-hydra-client-36(persistgemfire8_host1_8586:8586):41006 > unshared ordered *sender uid=1036* dom #1 local port=47207 remote > port=42068> tid=0x51 > or something like that. > Now we can look at the _Sending_ message and know that the receiving thread > will have _uid=1036_ in its name. Knowing this it ought to be possible to > write a program/script to trace a message and its consequences from one node > to another. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8920) Modify debug logging to make it easier to trace a message
[ https://issues.apache.org/jira/browse/GEODE-8920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293883#comment-17293883 ] ASF GitHub Bot commented on GEODE-8920: --- Bill merged pull request #6071: URL: https://github.com/apache/geode/pull/6071 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Modify debug logging to make it easier to trace a message > - > > Key: GEODE-8920 > URL: https://issues.apache.org/jira/browse/GEODE-8920 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Bruce J Schuchardt >Assignee: Kamilla Aslami >Priority: Major > Labels: blocks-1.14.0, pull-request-available > Fix For: 1.15.0 > > > Debug logging in DirectChannel lets us know the IDs of receivers of a message > and the toString of the message but it's very difficult to figure out what > thread on the receiving end is supposed to process that message. > Here's an example of what we currently have: > [debug 2021/02/01 16:15:17.492 PST persistgemfire8_host1_8586 > tid=0x4f0] Sending > (DLockRequestProcessor.DLockResponseMessage responding GRANT; > serviceName=__PDX(version 4); objectName=PDX_LOCK; responseCode=0; > keyIfFailed=null; leaseExpireTime=9223372036854775807; processorId=509; > lockId=509) to 1 peers > ([rs-GEM-3166-PL1535a2i32xlarge-hydra-client-36(persistgemfire9_host1_8517:8517):41005]) > via tcp/ip > This does not tell you anything about the receiver except its ID. On the > receiving side the thread that, in this run, would handle that message is > this: > persistgemfire9_host1_8517 rs-GEM-3166-PL1535a2i32xlarge-hydra-client-36(persistgemfire8_host1_8586:8586):41006 > unshared ordered *uid=1036* dom #1 local port=47207 remote port=42068> > tid=0x51 > I've highlighted the *uid* here because that is the _uniqueId_ of the sending > Connection. If you looked through the logs or stack traces of the receiver > and knew the uniqueId of the sending Connection you could easily locate the > thread that should receive this DLockResponseMessage. Currently this is much > harder than it needs to be because the DirectChannel _Sending_ log message > doesn't include the _uniqueId_ of the Connections it is using to send the > message. > Let's change that log message to include the _uniqueId_ of each outgoing > Connection. Maybe something like this: > Sending (message.toString()) to 1 peers (peer ID)*, uid=1036* via tcp/ip > and on the receiving side we could be clearer about what the *uid* in the > thread's name means: > persistgemfire9_host1_8517 rs-GEM-3166-PL1535a2i32xlarge-hydra-client-36(persistgemfire8_host1_8586:8586):41006 > unshared ordered *sender uid=1036* dom #1 local port=47207 remote > port=42068> tid=0x51 > or something like that. > Now we can look at the _Sending_ message and know that the receiving thread > will have _uid=1036_ in its name. Knowing this it ought to be possible to > write a program/script to trace a message and its consequences from one node > to another. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8992) When a GatewaySenderEventImpl is serialized, its operationDetail field is not included
[
https://issues.apache.org/jira/browse/GEODE-8992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nabarun Nag updated GEODE-8992:
---
Labels: blocks-1.15.0 (was: )
> When a GatewaySenderEventImpl is serialized, its operationDetail field is not
> included
> --
>
> Key: GEODE-8992
> URL: https://issues.apache.org/jira/browse/GEODE-8992
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barrett Oglesby
>Priority: Major
> Labels: blocks-1.15.0
>
> This causes the operation to become less specific when the
> {{GatewaySenderEventImpl}} is deserialized.
> Here is an example.
> If the original {{GatewaySenderEventImpl}} is a *PUTALL_CREATE* like:
> {noformat}
> GatewaySenderEventImpl[id=EventID[id=31
> bytes;threadID=0x10063|1;sequenceID=0;bucketId=99];action=0;operation=PUTALL_CREATE;region=/data;key=0;value=0;...]
> {noformat}
> Then, when the {{GatewaySenderEventImpl}} is serialized and deserialized, its
> operation becomes a *CREATE*:
> {noformat}
> GatewaySenderEventImpl[id=EventID[id=31
> bytes;threadID=0x10063|1;sequenceID=0;bucketId=99];action=0;operation=CREATE;region=/data;key=0;value=0;...]
> {noformat}
> Thats because {{GatewaySenderEventImpl.getOperation}} uses both *action* and
> *operationDetail* to determine its operation:
> {noformat}
> public Operation getOperation() {
> Operation op = null;
> switch (this.action) {
> case CREATE_ACTION:
> switch (this.operationDetail) {
> case ...
> case OP_DETAIL_PUTALL:
> op = Operation.PUTALL_CREATE;
> break;
> default:
> op = Operation.CREATE;
> break;
> }
> ...
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8986) change benchmarks baseline to version 1.13.1
[ https://issues.apache.org/jira/browse/GEODE-8986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293880#comment-17293880 ] ASF subversion and git services commented on GEODE-8986: Commit 57666f64b418bf09795318fd4e2c3f2b312dfb9e in geode's branch refs/heads/develop from Hale Bales [ https://gitbox.apache.org/repos/asf?p=geode.git;h=57666f6 ] GEODE-8986: bump benchmark baseline version (#6072) - bump benchmark baseline version to most recent release - change release script to automatically keep the baseline for develop at the latest released version > change benchmarks baseline to version 1.13.1 > > > Key: GEODE-8986 > URL: https://issues.apache.org/jira/browse/GEODE-8986 > Project: Geode > Issue Type: Task > Components: benchmarks, ci >Reporter: Hale Bales >Assignee: Hale Bales >Priority: Major > Labels: pull-request-available > > In CI, the current baseline is 1.13.0. It should be changed to the most > recent version, which is currently 1.13.1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8986) change benchmarks baseline to version 1.13.1
[ https://issues.apache.org/jira/browse/GEODE-8986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293878#comment-17293878 ] ASF GitHub Bot commented on GEODE-8986: --- onichols-pivotal merged pull request #6072: URL: https://github.com/apache/geode/pull/6072 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > change benchmarks baseline to version 1.13.1 > > > Key: GEODE-8986 > URL: https://issues.apache.org/jira/browse/GEODE-8986 > Project: Geode > Issue Type: Task > Components: benchmarks, ci >Reporter: Hale Bales >Assignee: Hale Bales >Priority: Major > Labels: pull-request-available > > In CI, the current baseline is 1.13.0. It should be changed to the most > recent version, which is currently 1.13.1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8980) bump dependencies for 1.15.0
[ https://issues.apache.org/jira/browse/GEODE-8980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293876#comment-17293876 ] ASF subversion and git services commented on GEODE-8980: Commit 0da3718f30bf749b29572b7017ea581b7279cefb in geode's branch refs/heads/develop from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0da3718 ] GEODE-8980: bump dependencies (#6062) * Bump spring (except spring-test) from 5.3.3 to 5.3.4 * Bump spring-security from 5.4.2 to 5.4.5 * Bump spring-hateoas from 1.2.3 to 1.2.4 * Bump spring-boot-starter from 2.4.2 to 2.4.3 * Bump HikariCP from 4.0.1 to 4.0.2 * Bump micrometer-core from 1.6.3 to 1.6.4 * Bump jetty from 9.4.36.v20210114 to 9.4.37.v20210219 * Bump junit from 4.13.1 to 4.13.2 * Bump mockito-core from 3.7.7 to 3.8.0 * Bump jna from 5.6.0 to 5.7.0 * Bump jproc from 2.4.0 to 2.5.1 * Bump spotless from 5.10.0 to 5.10.2 > bump dependencies for 1.15.0 > > > Key: GEODE-8980 > URL: https://issues.apache.org/jira/browse/GEODE-8980 > Project: Geode > Issue Type: Improvement > Components: build >Affects Versions: 1.15.0 >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > > keeping up with the latest versions of 3rd-party libraries used by Geode is a > proactive way to reduce bugs and avoid security vulnerabilities. this ticket > will be used for ~monthly dependency bumps on develop until we get close to > cutting support/1.15 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8964) Entry created via TX putIfAbsent with null value can write incorrect data to cache
[ https://issues.apache.org/jira/browse/GEODE-8964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293875#comment-17293875 ] ASF GitHub Bot commented on GEODE-8964: --- luissson closed pull request #6067: URL: https://github.com/apache/geode/pull/6067 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Entry created via TX putIfAbsent with null value can write incorrect data to > cache > -- > > Key: GEODE-8964 > URL: https://issues.apache.org/jira/browse/GEODE-8964 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.10.0, 1.14.0 >Reporter: Louis R. Jacome >Assignee: Louis R. Jacome >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > In backwards compatibility testing, an error was seen wherein a putIfAbsent > with a null value was being processed by a server but interrupted by a GII > with the same key. The operation was subsequently enqueued in the client's HA > Region Queue as an update with a null value rather than a create with a null > value -- a path that's not supported -- resulting in erroneous data sometimes > being written to the client cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8980) bump dependencies for 1.15.0
[ https://issues.apache.org/jira/browse/GEODE-8980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293873#comment-17293873 ] ASF GitHub Bot commented on GEODE-8980: --- onichols-pivotal merged pull request #6062: URL: https://github.com/apache/geode/pull/6062 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > bump dependencies for 1.15.0 > > > Key: GEODE-8980 > URL: https://issues.apache.org/jira/browse/GEODE-8980 > Project: Geode > Issue Type: Improvement > Components: build >Affects Versions: 1.15.0 >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > > keeping up with the latest versions of 3rd-party libraries used by Geode is a > proactive way to reduce bugs and avoid security vulnerabilities. this ticket > will be used for ~monthly dependency bumps on develop until we get close to > cutting support/1.15 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7245) Remove most uses of latestViewReadLock in GMSMembershipManager
[ https://issues.apache.org/jira/browse/GEODE-7245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293874#comment-17293874 ] ASF subversion and git services commented on GEODE-7245: Commit 477ffba8e155dca0bdeeefd312b6b32b4b481100 in geode's branch refs/heads/develop from Kamilla Aslami [ https://gitbox.apache.org/repos/asf?p=geode.git;h=477ffba ] GEODE-7245: Remove most uses of latestViewReadLock in GMSMembership (#6037) * Remove most uses of latestViewReadLock in GMSMembership * make MembershipView immutable * Constructor consolidation and better naming of add/remove * Tighten constructor chaining Co-authored-by: Bill Burcham > Remove most uses of latestViewReadLock in GMSMembershipManager > -- > > Key: GEODE-7245 > URL: https://issues.apache.org/jira/browse/GEODE-7245 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Bruce J Schuchardt >Priority: Major > Labels: pull-request-available > > Changes for GEODE-7196 made the latestView immutable so there is no reason, > in most cases, to use the latestViewReadlock when accessing the view. A > simple volatile read of the field & storing the value in a method variable > can replace most uses of the latestViewReadLock, especially those uses that > are in the path of sending or receiving messages. > Performance could be measured with our benchmarks to see if this change helps. > > latestViewReadLock is currently used in getCoordinator(), memberExists(), > getMembersNotShuttingDown(), getAllMembers(), isShunnedOrNew(), > isSurpriseMember(), doWithViewLocked(). > doWithViewLocked() is used to add membership listeners, and we don't want the > view to change until this operation completes. Therefore, we should keep the > lock in this method. > getCoordinator(), memberExists(), getMembersNotShuttingDown(), > getAllMembers() use latestViewReadLock to access latestView. In these methods > we can replace the lock with a volatile read of the latestView and storing > the value in a method variable. > isShunnedOrNew() accesses latestView, and 2 ConcurrentHashMaps - > shunnedMembers and surpriseMembers. Since the hashmaps are concurrent and > latestView is unmodifiable, a volatile read could replace the lock. Same for > isSurpriseMember(), which uses surpriseMembers hashmap. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7245) Remove most uses of latestViewReadLock in GMSMembershipManager
[ https://issues.apache.org/jira/browse/GEODE-7245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293872#comment-17293872 ] ASF GitHub Bot commented on GEODE-7245: --- Bill merged pull request #6037: URL: https://github.com/apache/geode/pull/6037 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Remove most uses of latestViewReadLock in GMSMembershipManager > -- > > Key: GEODE-7245 > URL: https://issues.apache.org/jira/browse/GEODE-7245 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Bruce J Schuchardt >Priority: Major > Labels: pull-request-available > > Changes for GEODE-7196 made the latestView immutable so there is no reason, > in most cases, to use the latestViewReadlock when accessing the view. A > simple volatile read of the field & storing the value in a method variable > can replace most uses of the latestViewReadLock, especially those uses that > are in the path of sending or receiving messages. > Performance could be measured with our benchmarks to see if this change helps. > > latestViewReadLock is currently used in getCoordinator(), memberExists(), > getMembersNotShuttingDown(), getAllMembers(), isShunnedOrNew(), > isSurpriseMember(), doWithViewLocked(). > doWithViewLocked() is used to add membership listeners, and we don't want the > view to change until this operation completes. Therefore, we should keep the > lock in this method. > getCoordinator(), memberExists(), getMembersNotShuttingDown(), > getAllMembers() use latestViewReadLock to access latestView. In these methods > we can replace the lock with a volatile read of the latestView and storing > the value in a method variable. > isShunnedOrNew() accesses latestView, and 2 ConcurrentHashMaps - > shunnedMembers and surpriseMembers. Since the hashmaps are concurrent and > latestView is unmodifiable, a volatile read could replace the lock. Same for > isSurpriseMember(), which uses surpriseMembers hashmap. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8992) When a GatewaySenderEventImpl is serialized, its operationDetail field is not included
Barrett Oglesby created GEODE-8992:
--
Summary: When a GatewaySenderEventImpl is serialized, its
operationDetail field is not included
Key: GEODE-8992
URL: https://issues.apache.org/jira/browse/GEODE-8992
Project: Geode
Issue Type: Bug
Components: wan
Reporter: Barrett Oglesby
This causes the operation to become less specific when the
{{GatewaySenderEventImpl}} is deserialized.
Here is an example.
If the original {{GatewaySenderEventImpl}} is a *PUTALL_CREATE* like:
{noformat}
GatewaySenderEventImpl[id=EventID[id=31
bytes;threadID=0x10063|1;sequenceID=0;bucketId=99];action=0;operation=PUTALL_CREATE;region=/data;key=0;value=0;...]
{noformat}
Then, when the {{GatewaySenderEventImpl}} is serialized and deserialized, its
operation becomes a *CREATE*:
{noformat}
GatewaySenderEventImpl[id=EventID[id=31
bytes;threadID=0x10063|1;sequenceID=0;bucketId=99];action=0;operation=CREATE;region=/data;key=0;value=0;...]
{noformat}
Thats because {{GatewaySenderEventImpl.getOperation}} uses both *action* and
*operationDetail* to determine its operation:
{noformat}
public Operation getOperation() {
Operation op = null;
switch (this.action) {
case CREATE_ACTION:
switch (this.operationDetail) {
case ...
case OP_DETAIL_PUTALL:
op = Operation.PUTALL_CREATE;
break;
default:
op = Operation.CREATE;
break;
}
...
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8671) Two threads calling get and retrieve the same PdxInstance, resulting in corruption
[
https://issues.apache.org/jira/browse/GEODE-8671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293871#comment-17293871
]
ASF GitHub Bot commented on GEODE-8671:
---
kirklund commented on a change in pull request #5925:
URL: https://github.com/apache/geode/pull/5925#discussion_r585774910
##
File path:
geode-core/src/distributedTest/java/org/apache/geode/internal/cache/RegionConcurrentOperationDUnitTest.java
##
@@ -61,9 +63,14 @@ private static DUnitBlackboard getBlackboard() {
@Rule
public ExecutorServiceRule executorServiceRule = new ExecutorServiceRule();
+ @Rule
+ public DistributedBlackboard blackboard = new DistributedBlackboard();
+
@After
public void tearDown() {
-blackboard.initBlackboard();
+if (blackboard != null) {
Review comment:
You can delete this `tearDown`. The `DistributedBlackboard` Rule handles
this for you. (If it doesn't, that's a bug that I need to know 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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Two threads calling get and retrieve the same PdxInstance, resulting in
> corruption
> --
>
> Key: GEODE-8671
> URL: https://issues.apache.org/jira/browse/GEODE-8671
> Project: Geode
> Issue Type: Improvement
> Components: regions
>Reporter: Dan Smith
>Assignee: Jianxia Chen
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
>
> Even if copy-on-read is set to true, two threads calling get on a partitioned
> region can end up with the same PdxInstance object.
> This is problematic because some PdxInstances methods are not thread safe.
> Although the underlying bytes are immutatable, the PDXInstance has a
> ByteSource with a position field that changes. That means two threads doing
> serialization or calling toString on the PdxInstance could result in one or
> more threads getting a corrupt read.
> It looks like they are ending up with the same instance because of the
> behavior in LocalRegion.optimizedGetObject. We use futures to make sure there
> is only 1 get that goes through, and both threads receive the same value.
>
> Ending up in optimizedGetObject requires a race with the put, because if the
> value was in the cache at the beginning of the get it would be returned
> earlier in the get process.
> I put a test that reproduces this issue here -
> https://github.com/upthewaterspout/geode/pull/new/feature/pdx-instances-shared
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8671) Two threads calling get and retrieve the same PdxInstance, resulting in corruption
[
https://issues.apache.org/jira/browse/GEODE-8671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293870#comment-17293870
]
ASF GitHub Bot commented on GEODE-8671:
---
kirklund commented on a change in pull request #5925:
URL: https://github.com/apache/geode/pull/5925#discussion_r585774024
##
File path:
geode-core/src/distributedTest/java/org/apache/geode/internal/cache/RegionConcurrentOperationDUnitTest.java
##
@@ -131,6 +140,49 @@ public void
getOnPreLoadedRegionFromMultipleThreadsReturnSameObject() throws Exc
assertThat(cacheRule.getCache().getRegion(regionName).size()).isEqualTo(1);
}
+ @Test
+ public void
getOnPartitionedRegionFromMultipleThreadsReturnsDifferentPdxInstances()
+ throws Exception {
+String regionName = getClass().getSimpleName();
+CacheFactory cacheFactory = new CacheFactory();
+cacheFactory.setPdxReadSerialized(true);
+cacheRule.createCache(cacheFactory);
+InternalCache cache = cacheRule.getCache();
+cache.setCopyOnRead(true);
+Region region = cache.createRegionFactory(PARTITION)
+.create(regionName);
+
+// Keep doing this concurrency test for 30 seconds.
+long endTime = Duration.ofSeconds(30).toMillis() +
System.currentTimeMillis();
+
+while (System.currentTimeMillis() < endTime) {
+ Callable getValue = () -> {
+while (true) {
+ Object value = region.get(key);
+ if (value != null) {
+return value;
+ }
+}
+ };
+
+ // In this test, two threads are doing gets. One thread puts the value
+ // We expect that the threads will *always* get different PdxInstance
values
+ Future get1 = executorServiceRule.submit(getValue);
+ Future get2 = executorServiceRule.submit(getValue);
+ Future put = executorServiceRule.submit(() -> region.put(key, new
TestValue()));
Review comment:
If the Future is not going to have a result then go with `Future`.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Two threads calling get and retrieve the same PdxInstance, resulting in
> corruption
> --
>
> Key: GEODE-8671
> URL: https://issues.apache.org/jira/browse/GEODE-8671
> Project: Geode
> Issue Type: Improvement
> Components: regions
>Reporter: Dan Smith
>Assignee: Jianxia Chen
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
>
> Even if copy-on-read is set to true, two threads calling get on a partitioned
> region can end up with the same PdxInstance object.
> This is problematic because some PdxInstances methods are not thread safe.
> Although the underlying bytes are immutatable, the PDXInstance has a
> ByteSource with a position field that changes. That means two threads doing
> serialization or calling toString on the PdxInstance could result in one or
> more threads getting a corrupt read.
> It looks like they are ending up with the same instance because of the
> behavior in LocalRegion.optimizedGetObject. We use futures to make sure there
> is only 1 get that goes through, and both threads receive the same value.
>
> Ending up in optimizedGetObject requires a race with the put, because if the
> value was in the cache at the beginning of the get it would be returned
> earlier in the get process.
> I put a test that reproduces this issue here -
> https://github.com/upthewaterspout/geode/pull/new/feature/pdx-instances-shared
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8919) revert renaming of GMS processMessage methods
[
https://issues.apache.org/jira/browse/GEODE-8919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt updated GEODE-8919:
Fix Version/s: 1.14.0
> revert renaming of GMS processMessage methods
> -
>
> Key: GEODE-8919
> URL: https://issues.apache.org/jira/browse/GEODE-8919
> Project: Geode
> Issue Type: Improvement
> Components: membership
>Reporter: Bruce J Schuchardt
>Assignee: Ernest Burghardt
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
> Fix For: 1.14.0, 1.15.0
>
>
> [~upthewaterspout] modified methods in the membership module that process
> membership methods so that they are now all named *processMessage*, but this
> make it more difficult to read stack traces and know what type of message a
> thread is processing. Let's make life easier for us and revert that change.
> Let's name each method after the type of message it processes so that we
> don't have to look at source code to figure it out.
> This method, for instance, could be named *processInstallViewMessage* and we
> would know, without looking at source code, which type of message is being
> processed.
> {noformat}
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:1053)
> > at
> > org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1330)
> > at
> > org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1269)
> > at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> > at org.jgroups.JChannel.up(JChannel.java:741)
> > at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> > at
> > org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> > at
> > org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> > at
> > org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:73)
> > at
> > org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:72)
> > at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> > at
> > org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> > at
> > org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> > at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> > at org.jgroups.protocols.TP.receive(TP.java:1714)
> > at
> > org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:152)
> > at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> > at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8919) revert renaming of GMS processMessage methods
[
https://issues.apache.org/jira/browse/GEODE-8919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293865#comment-17293865
]
ASF subversion and git services commented on GEODE-8919:
Commit f6e3f13aa65036d890fd1faa7e2ca403f87c9fc0 in geode's branch
refs/heads/support/1.14 from Ernie Burghardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f6e3f13 ]
GEODE-8919: undid polymorphic naming for processMessage methods. (#6055) (#6070)
(cherry picked from commit 6edf69546b784f67ed125bc4b1d592496ee1f5ee)
> revert renaming of GMS processMessage methods
> -
>
> Key: GEODE-8919
> URL: https://issues.apache.org/jira/browse/GEODE-8919
> Project: Geode
> Issue Type: Improvement
> Components: membership
>Reporter: Bruce J Schuchardt
>Assignee: Ernest Burghardt
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
> Fix For: 1.15.0
>
>
> [~upthewaterspout] modified methods in the membership module that process
> membership methods so that they are now all named *processMessage*, but this
> make it more difficult to read stack traces and know what type of message a
> thread is processing. Let's make life easier for us and revert that change.
> Let's name each method after the type of message it processes so that we
> don't have to look at source code to figure it out.
> This method, for instance, could be named *processInstallViewMessage* and we
> would know, without looking at source code, which type of message is being
> processed.
> {noformat}
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:1053)
> > at
> > org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1330)
> > at
> > org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1269)
> > at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> > at org.jgroups.JChannel.up(JChannel.java:741)
> > at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> > at
> > org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> > at
> > org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> > at
> > org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:73)
> > at
> > org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:72)
> > at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> > at
> > org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> > at
> > org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> > at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> > at org.jgroups.protocols.TP.receive(TP.java:1714)
> > at
> > org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:152)
> > at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> > at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8919) revert renaming of GMS processMessage methods
[
https://issues.apache.org/jira/browse/GEODE-8919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293864#comment-17293864
]
ASF GitHub Bot commented on GEODE-8919:
---
echobravopapa merged pull request #6070:
URL: https://github.com/apache/geode/pull/6070
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> revert renaming of GMS processMessage methods
> -
>
> Key: GEODE-8919
> URL: https://issues.apache.org/jira/browse/GEODE-8919
> Project: Geode
> Issue Type: Improvement
> Components: membership
>Reporter: Bruce J Schuchardt
>Assignee: Ernest Burghardt
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
> Fix For: 1.15.0
>
>
> [~upthewaterspout] modified methods in the membership module that process
> membership methods so that they are now all named *processMessage*, but this
> make it more difficult to read stack traces and know what type of message a
> thread is processing. Let's make life easier for us and revert that change.
> Let's name each method after the type of message it processes so that we
> don't have to look at source code to figure it out.
> This method, for instance, could be named *processInstallViewMessage* and we
> would know, without looking at source code, which type of message is being
> processed.
> {noformat}
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:1053)
> > at
> > org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1330)
> > at
> > org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1269)
> > at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> > at org.jgroups.JChannel.up(JChannel.java:741)
> > at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> > at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> > at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> > at
> > org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> > at
> > org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> > at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> > at
> > org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:73)
> > at
> > org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:72)
> > at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> > at
> > org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> > at
> > org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> > at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> > at org.jgroups.protocols.TP.receive(TP.java:1714)
> > at
> > org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:152)
> > at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> > at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8793) Fix PdxTypeRegistry cleanup upon cluster disconnection
[
https://issues.apache.org/jira/browse/GEODE-8793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293861#comment-17293861
]
ASF GitHub Bot commented on GEODE-8793:
---
gaussianrecurrence commented on a change in pull request #715:
URL: https://github.com/apache/geode-native/pull/715#discussion_r585764332
##
File path: cppcache/integration/test/PdxTypeRegistryTest.cpp
##
@@ -0,0 +1,159 @@
+/* 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
+#include
+#include
+#include
+#include
+#include
+
+#include "framework/Cluster.h"
+#include "framework/Framework.h"
+#include "framework/Gfsh.h"
+
+namespace {
+
+using apache::geode::client::Cache;
+using apache::geode::client::CacheableInt16;
+using apache::geode::client::CacheFactory;
+using apache::geode::client::CacheListener;
+using apache::geode::client::NotConnectedException;
+using apache::geode::client::PdxInstance;
+using apache::geode::client::Region;
+using apache::geode::client::RegionEvent;
+using apache::geode::client::RegionShortcut;
+using apache::geode::client::SelectResults;
+
+static bool isDisconnected = false;
+
+class RegionListener : public CacheListener {
+ public:
+ void waitConnected() {
+std::unique_lock lock{mutex_};
+status_cv_.wait(lock, [this] { return status_; });
+ }
+
+ void waitDisconnected() {
+std::unique_lock lock{mutex_};
+status_cv_.wait(lock, [this] { return !status_; });
+ }
+
+ protected:
+ void afterRegionDisconnected(Region&) override {
+std::unique_lock lock{mutex_};
+
+status_ = false;
+status_cv_.notify_all();
+ }
+
+ void afterRegionLive(const RegionEvent&) override {
+std::unique_lock lock{mutex_};
+
+status_ = true;
+status_cv_.notify_all();
+ }
+
+ protected:
+ bool status_;
+ std::mutex mutex_;
+ std::condition_variable status_cv_;
+};
+
+Cache createTestCache() {
+ CacheFactory cacheFactory;
+ return cacheFactory.set("log-level", "none")
+ .set("connect-timeout", "2s")
+ .set("statistic-sampling-enabled", "false")
+ .set("on-client-disconnect-clear-pdxType-Ids", "true")
+ .setPdxReadSerialized(true)
+ .create();
+}
+
+void createTestPool(Cluster& cluster, Cache& cache) {
+ auto poolFactory = cache.getPoolManager()
+ .createFactory()
+ .setReadTimeout(std::chrono::seconds{1})
+ .setPingInterval(std::chrono::seconds{5})
+ .setSubscriptionEnabled(true);
+
+ cluster.applyLocators(poolFactory);
+ poolFactory.create("pool");
+}
+
+std::shared_ptr createTestRegion(
+Cache& cache, std::shared_ptr listener) {
+ auto regionFactory = cache.createRegionFactory(RegionShortcut::PROXY);
+ return regionFactory.setPoolName("pool").setCacheListener(listener).create(
+ "region");
+}
+
+std::shared_ptr createTestPdxInstance(Cache& cache,
+ const std::string& entry) {
+ auto factory = cache.createPdxInstanceFactory("__GEMFIRE_JSON", false);
+ return factory.writeString("entryName", entry)
+ .writeInt("int-value", -1)
+ .create();
+}
+
+TEST(PdxTypeRegistryTest, cleanupOnClusterRestart) {
+ Cluster cluster{LocatorCount{1}, ServerCount{2}};
+ cluster.start();
+
+ auto& gfsh = cluster.getGfsh();
+ gfsh.create().region().withName("region").withType("PARTITION").execute();
+
+ bool running = true;
Review comment:
Ups, thanks for pointing it out. I must have left it there from a
previous IT implementation.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Fix PdxTypeRegistry cleanup upon cluster disconnection
> --
>
> Key: GEODE-8793
> URL: https://issues.apache.org/jira/browse/GEODE-8793
> Project: Geode
> Issue
[jira] [Commented] (GEODE-8793) Fix PdxTypeRegistry cleanup upon cluster disconnection
[
https://issues.apache.org/jira/browse/GEODE-8793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293860#comment-17293860
]
ASF GitHub Bot commented on GEODE-8793:
---
moleske commented on a change in pull request #715:
URL: https://github.com/apache/geode-native/pull/715#discussion_r585762028
##
File path: cppcache/integration/test/PdxTypeRegistryTest.cpp
##
@@ -0,0 +1,159 @@
+/* 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
+#include
+#include
+#include
+#include
+#include
+
+#include "framework/Cluster.h"
+#include "framework/Framework.h"
+#include "framework/Gfsh.h"
+
+namespace {
+
+using apache::geode::client::Cache;
+using apache::geode::client::CacheableInt16;
+using apache::geode::client::CacheFactory;
+using apache::geode::client::CacheListener;
+using apache::geode::client::NotConnectedException;
+using apache::geode::client::PdxInstance;
+using apache::geode::client::Region;
+using apache::geode::client::RegionEvent;
+using apache::geode::client::RegionShortcut;
+using apache::geode::client::SelectResults;
+
+static bool isDisconnected = false;
+
+class RegionListener : public CacheListener {
+ public:
+ void waitConnected() {
+std::unique_lock lock{mutex_};
+status_cv_.wait(lock, [this] { return status_; });
+ }
+
+ void waitDisconnected() {
+std::unique_lock lock{mutex_};
+status_cv_.wait(lock, [this] { return !status_; });
+ }
+
+ protected:
+ void afterRegionDisconnected(Region&) override {
+std::unique_lock lock{mutex_};
+
+status_ = false;
+status_cv_.notify_all();
+ }
+
+ void afterRegionLive(const RegionEvent&) override {
+std::unique_lock lock{mutex_};
+
+status_ = true;
+status_cv_.notify_all();
+ }
+
+ protected:
+ bool status_;
+ std::mutex mutex_;
+ std::condition_variable status_cv_;
+};
+
+Cache createTestCache() {
+ CacheFactory cacheFactory;
+ return cacheFactory.set("log-level", "none")
+ .set("connect-timeout", "2s")
+ .set("statistic-sampling-enabled", "false")
+ .set("on-client-disconnect-clear-pdxType-Ids", "true")
+ .setPdxReadSerialized(true)
+ .create();
+}
+
+void createTestPool(Cluster& cluster, Cache& cache) {
+ auto poolFactory = cache.getPoolManager()
+ .createFactory()
+ .setReadTimeout(std::chrono::seconds{1})
+ .setPingInterval(std::chrono::seconds{5})
+ .setSubscriptionEnabled(true);
+
+ cluster.applyLocators(poolFactory);
+ poolFactory.create("pool");
+}
+
+std::shared_ptr createTestRegion(
+Cache& cache, std::shared_ptr listener) {
+ auto regionFactory = cache.createRegionFactory(RegionShortcut::PROXY);
+ return regionFactory.setPoolName("pool").setCacheListener(listener).create(
+ "region");
+}
+
+std::shared_ptr createTestPdxInstance(Cache& cache,
+ const std::string& entry) {
+ auto factory = cache.createPdxInstanceFactory("__GEMFIRE_JSON", false);
+ return factory.writeString("entryName", entry)
+ .writeInt("int-value", -1)
+ .create();
+}
+
+TEST(PdxTypeRegistryTest, cleanupOnClusterRestart) {
+ Cluster cluster{LocatorCount{1}, ServerCount{2}};
+ cluster.start();
+
+ auto& gfsh = cluster.getGfsh();
+ gfsh.create().region().withName("region").withType("PARTITION").execute();
+
+ bool running = true;
Review comment:
I believe this is unused
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Fix PdxTypeRegistry cleanup upon cluster disconnection
> --
>
> Key: GEODE-8793
> URL: https://issues.apache.org/jira/browse/GEODE-8793
> Project: Geode
> Issue Type: Bug
> Components: native client
>Affects Versions: 1.13.0, 1.1
[jira] [Commented] (GEODE-8864) finish implementation of Redis HScan Command
[
https://issues.apache.org/jira/browse/GEODE-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293844#comment-17293844
]
ASF GitHub Bot commented on GEODE-8864:
---
jhutchison commented on a change in pull request #5954:
URL: https://github.com/apache/geode/pull/5954#discussion_r585746972
##
File path:
geode-redis/src/main/java/org/apache/geode/redis/internal/data/RedisHash.java
##
@@ -203,49 +279,122 @@ public int hstrlen(ByteArrayWrapper field) {
return new ArrayList<>(hash.keySet());
}
- public Pair> hscan(Pattern matchPattern, int count,
BigInteger cursor) {
-List returnList = new ArrayList();
-int size = hash.size();
-BigInteger beforeCursor = new BigInteger("0");
-int numElements = 0;
-int i = -1;
-for (Map.Entry entry :
hash.entrySet()) {
- ByteArrayWrapper key = entry.getKey();
- ByteArrayWrapper value = entry.getValue();
- i++;
- if (beforeCursor.compareTo(cursor) < 0) {
-beforeCursor = beforeCursor.add(new BigInteger("1"));
+ public ImmutablePair> hscan(UUID clientID, Pattern
matchPattern,
+ int count,
+ BigInteger cursorParameter) {
+
+int startCursor = cursorParameter.intValue();
+
+List keysToScan = getSnapShotOfKeySet(clientID);
+
+Pair> resultsPair =
+getResultsPair(keysToScan, startCursor, count, matchPattern);
+
+List resultList = resultsPair.getRight();
+
+Integer numberOfIterationsCompleted = resultsPair.getLeft();
+
+int returnCursorValueAsInt =
+getCursorValueToReturn(startCursor, numberOfIterationsCompleted,
keysToScan);
+
+if (returnCursorValueAsInt == 0) {
+ removeHSCANSnapshot(clientID);
+}
+
+return new ImmutablePair<>(BigInteger.valueOf(returnCursorValueAsInt),
+resultList);
+ }
+
+ private void removeHSCANSnapshot(UUID clientID) {
+this.hScanSnapShots.remove(clientID);
+this.hScanSnapShotCreationTimes.remove(clientID);
+
+if (this.hScanSnapShots.isEmpty()) {
+ shutDownHscanSnapshotScheduledRemoval();
+}
+ }
+
+ @SuppressWarnings("unchecked")
+ private Pair> getResultsPair(List
keysSnapShot,
+ int startCursor,
+ int count,
+ Pattern matchPattern) {
+
+int indexOfKeys = startCursor;
+
+List resultList = new ArrayList<>();
+
+for (int index = startCursor; index < keysSnapShot.size(); index++) {
+
+ if ((index - startCursor) == count) {
+break;
+ }
+
+ ByteArrayWrapper key = keysSnapShot.get(index);
+ indexOfKeys++;
+
+ ByteArrayWrapper value = hash.get(key);
+ if (value == null) {
continue;
}
if (matchPattern != null) {
if (matchPattern.matcher(key.toString()).matches()) {
- returnList.add(key);
- returnList.add(value);
- numElements++;
+ resultList.add(key);
+ resultList.add(value);
}
} else {
-returnList.add(key);
-returnList.add(value);
-numElements++;
+resultList.add(key);
+resultList.add(value);
}
+}
- if (numElements == count) {
-break;
- }
+Integer numberOfIterationsCompleted = indexOfKeys - startCursor;
+
+Pair resultsPair = new ImmutablePair(numberOfIterationsCompleted,
resultList);
+
+return resultsPair;
+ }
+
+ private int getCursorValueToReturn(int startCursor,
+ int numberOfIterationsCompleted,
+ List keySnapshot) {
+
+if (startCursor + numberOfIterationsCompleted >= keySnapshot.size()) {
+ return 0;
}
-Pair> scanResult;
-if (i >= size - 1) {
- scanResult = new ImmutablePair<>(new BigInteger("0"), returnList);
-} else {
- scanResult = new ImmutablePair<>(new BigInteger(String.valueOf(i + 1)),
returnList);
+return (startCursor + numberOfIterationsCompleted);
+ }
+
+ @SuppressWarnings("unchecked")
+ private List getSnapShotOfKeySet(UUID clientID) {
+List keySnapShot = this.hScanSnapShots.get(clientID);
+
+if (keySnapShot == null) {
+ if (this.hScanSnapShots.isEmpty()) {
+startHscanSnapshotScheduledRemoval();
+ }
+ keySnapShot = createKeySnapShot(clientID);
}
-return scanResult;
+return keySnapShot;
+ }
+
+
+ private List createKeySnapShot(UUID clientID) {
+List keySnapShot = new ArrayList<>();
+keySnapShot.addAll(hash.keySet());
Review comment:
Meant to be copying these. changed to this (I think I added this
comment to the wrong place before)
List keySnapShot = new ArrayList<>();
List hashKeysAsList = Arrays.asList(hash.keySet().toArray());
Collections.copy(keySnapShot, hashKeysAsList);
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.
[jira] [Commented] (GEODE-8864) finish implementation of Redis HScan Command
[
https://issues.apache.org/jira/browse/GEODE-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293837#comment-17293837
]
ASF GitHub Bot commented on GEODE-8864:
---
jhutchison commented on a change in pull request #5954:
URL: https://github.com/apache/geode/pull/5954#discussion_r585740970
##
File path:
geode-redis/src/integrationTest/java/org/apache/geode/redis/internal/executor/hash/AbstractHScanIntegrationTest.java
##
@@ -336,48 +441,136 @@ public void
givenMultipleCountsAndMatches_returnsEntriesMatchingLastMatchParamet
}
@Test
- public void givenNegativeCursor_returnsEntriesUsingAbsoluteValueOfCursor() {
-Map entryMap = new HashMap<>();
-entryMap.put("1", "yellow");
-entryMap.put("2", "green");
-entryMap.put("3", "orange");
-jedis.hmset("colors", entryMap);
+ public void should_notReturnValue_givenValueWasRemovedBeforeHSCANISCalled() {
-String cursor = "-100";
-ScanResult> result;
-List> allEntries = new ArrayList<>();
+Map data = new HashMap<>();
+data.put("field_1", "yellow");
+data.put("field_2", "green");
+data.put("field_3", "grey");
+jedis.hmset("colors", data);
-do {
- result = jedis.hscan("colors", cursor);
- allEntries.addAll(result.getResult());
- cursor = result.getCursor();
-} while (!result.isCompleteIteration());
+jedis.hdel("colors", "field_3");
+data.remove("field_3");
-assertThat(allEntries).hasSize(3);
-assertThat(new HashSet<>(allEntries)).isEqualTo(entryMap.entrySet());
+GeodeAwaitility.await().untilAsserted(
+() -> assertThat(jedis.hget("colors", "field_3")).isNull());
+
+ScanResult> result = jedis.hscan("colors", "0");
+
+assertThat(new HashSet<>(result.getResult()))
+.containsExactlyInAnyOrderElementsOf(data.entrySet());
}
@Test
- public void givenCursorGreaterThanUnsignedLongCapacity_returnsCursorError() {
-assertThatThrownBy(() -> jedis.hscan("a", "18446744073709551616"))
-.hasMessageContaining(ERROR_CURSOR);
+ public void should_retun_not_error_given_non_zero_cursor_on_first_call() {
+
+Map data = new HashMap<>();
+data.put("field_1", "yellow");
+data.put("field_2", "green");
+data.put("field_3", "grey");
+jedis.hmset("colors", data);
+
+
+ScanResult> result = jedis.hscan("colors", "5");
+
+assertThat(new HashSet<>(result.getResult()))
+.containsExactlyInAnyOrderElementsOf(data.entrySet());
}
+ / Concurrency ***/
+
+ private final int SIZE_OF_INITIAL_HASH_DATA = 100;
+ final String HASH_KEY = "key";
+ final String BASE_FIELD = "baseField_";
+
@Test
- public void
givenNegativeCursorGreaterThanUnsignedLongCapacity_returnsCursorError() {
-assertThatThrownBy(() -> jedis.hscan("a", "-18446744073709551616"))
-.hasMessageContaining(ERROR_CURSOR);
+ public void
should_notLoseFields_givenConcurrentThreadsDoingHScansAndChangingValues() {
+final Map INITIAL_HASH_DATA =
makeEntrySet(SIZE_OF_INITIAL_HASH_DATA);
+jedis.hset(HASH_KEY, INITIAL_HASH_DATA);
+final int ITERATION_COUNT = 500;
+
+new ConcurrentLoopingThreads(ITERATION_COUNT,
+(i) -> multipleHScanAndAssertOnSizeOfResultSet(jedis,
INITIAL_HASH_DATA),
+(i) -> multipleHScanAndAssertOnSizeOfResultSet(jedis2,
INITIAL_HASH_DATA),
+(i) -> {
+ int fieldSuffix = i % SIZE_OF_INITIAL_HASH_DATA;
+ jedis3.hset(HASH_KEY, BASE_FIELD + fieldSuffix, "new_value_" + i);
+}).run();
+
}
@Test
- public void givenInvalidRegexSyntax_returnsEmptyArray() {
-jedis.hset("a", "1", "green");
-ScanParams scanParams = new ScanParams();
-scanParams.count(1);
-scanParams.match("\\p");
+ public void
should_notLoseKeysForConsistentlyPresentFields_givenConcurrentThreadsAddingAndRemovingFields()
{
+final Map INITIAL_HASH_DATA =
makeEntrySet(SIZE_OF_INITIAL_HASH_DATA);
+jedis.hset(HASH_KEY, INITIAL_HASH_DATA);
+final int ITERATION_COUNT = 500;
+
+new ConcurrentLoopingThreads(ITERATION_COUNT,
+(i) -> multipleHScanAndAssertOnContentOfResultSet(jedis,
INITIAL_HASH_DATA),
+(i) -> multipleHScanAndAssertOnContentOfResultSet(jedis2,
INITIAL_HASH_DATA),
+(i) -> {
+ String field = "new_" + BASE_FIELD + i;
+ jedis3.hset(HASH_KEY, field, "whatever");
+ jedis3.hdel(HASH_KEY, field);
+}).run();
-ScanResult> result = jedis.hscan("a", "0",
scanParams);
+ }
-assertThat(result.getResult()).isEmpty();
+ @Test
+ public void should_notAlterUnderlyingData_givenMultipleConcurrentHscans() {
+final Map INITIAL_HASH_DATA =
makeEntrySet(SIZE_OF_INITIAL_HASH_DATA);
+jedis.hset(HASH_KEY, INITIAL_HASH_DATA);
+final int ITERATION_COUNT = 500;
+
+new ConcurrentLoopingThreads(ITERATION_COUNT,
+(i) -> multipleHScanAndAssertOnContentOfResultSet(jedis,
INITIAL_
[jira] [Commented] (GEODE-8864) finish implementation of Redis HScan Command
[
https://issues.apache.org/jira/browse/GEODE-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293836#comment-17293836
]
ASF GitHub Bot commented on GEODE-8864:
---
jhutchison commented on a change in pull request #5954:
URL: https://github.com/apache/geode/pull/5954#discussion_r585739838
##
File path:
geode-redis/src/main/java/org/apache/geode/redis/internal/data/RedisHash.java
##
@@ -46,19 +53,88 @@
public class RedisHash extends AbstractRedisData {
public static final RedisHash NULL_REDIS_HASH = new NullRedisHash();
private HashMap hash;
+ private ConcurrentHashMap> hScanSnapShots;
+ private ConcurrentHashMap hScanSnapShotCreationTimes;
+ private ScheduledExecutorService HSCANSnapshotExpirationExecutor = null;
+
+ private static int default_hscan_snapshots_expire_check_frequency =
+ Integer.getInteger("redis.hscan-snapshot-cleanup-interval", 3);
+
+ private static int default_hscan_snapshots_milliseconds_to_live =
+ Integer.getInteger("redis.hscan-snapshot-expiry", 3);
+
+ private int HSCAN_SNAPSHOTS_EXPIRE_CHECK_FREQUENCY_MILLISECONDS;
+ private int MINIMUM_MILLISECONDS_FOR_HSCAN_SNAPSHOTS_TO_LIVE;
+
+ @VisibleForTesting
+ public RedisHash(List fieldsToSet, int
hscanSnapShotExpirationCheckFrequency,
+ int minimumLifeForHscanSnaphot) {
+this();
+
+this.HSCAN_SNAPSHOTS_EXPIRE_CHECK_FREQUENCY_MILLISECONDS =
+hscanSnapShotExpirationCheckFrequency;
+this.MINIMUM_MILLISECONDS_FOR_HSCAN_SNAPSHOTS_TO_LIVE =
minimumLifeForHscanSnaphot;
- public RedisHash(List fieldsToSet) {
-hash = new HashMap<>();
Iterator iterator = fieldsToSet.iterator();
while (iterator.hasNext()) {
hashPut(iterator.next(), iterator.next());
}
}
+ public RedisHash(List fieldsToSet) {
+this(fieldsToSet,
+default_hscan_snapshots_expire_check_frequency,
+default_hscan_snapshots_milliseconds_to_live);
+ }
+
+ // for serialization
public RedisHash() {
-// for serialization
+this.hash = new HashMap<>();
+this.hScanSnapShots = new ConcurrentHashMap<>();
+this.hScanSnapShotCreationTimes = new ConcurrentHashMap<>();
+
+this.HSCAN_SNAPSHOTS_EXPIRE_CHECK_FREQUENCY_MILLISECONDS =
+this.default_hscan_snapshots_expire_check_frequency;
+
+this.MINIMUM_MILLISECONDS_FOR_HSCAN_SNAPSHOTS_TO_LIVE =
+this.default_hscan_snapshots_milliseconds_to_live;
}
+
+ private void expireHScanSnapshots() {
+
+this.hScanSnapShotCreationTimes.entrySet().forEach(entry -> {
Review comment:
o, wow- that's because I'm not making a copy like I thought I was-
changed to this:
List keySnapShot = new ArrayList<>();
List hashKeysAsList = Arrays.asList(hash.keySet().toArray());
Collections.copy(keySnapShot, hashKeysAsList);
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> finish implementation of Redis HScan Command
>
>
> Key: GEODE-8864
> URL: https://issues.apache.org/jira/browse/GEODE-8864
> Project: Geode
> Issue Type: New Feature
> Components: redis
>Reporter: John Hutchison
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8864) finish implementation of Redis HScan Command
[
https://issues.apache.org/jira/browse/GEODE-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293822#comment-17293822
]
ASF GitHub Bot commented on GEODE-8864:
---
jhutchison commented on a change in pull request #5954:
URL: https://github.com/apache/geode/pull/5954#discussion_r585722123
##
File path:
geode-redis/src/integrationTest/java/org/apache/geode/redis/internal/executor/hash/AbstractHScanIntegrationTest.java
##
@@ -36,58 +38,86 @@
import redis.clients.jedis.ScanParams;
import redis.clients.jedis.ScanResult;
+import org.apache.geode.redis.ConcurrentLoopingThreads;
import org.apache.geode.test.awaitility.GeodeAwaitility;
import org.apache.geode.test.dunit.rules.RedisPortSupplier;
public abstract class AbstractHScanIntegrationTest implements
RedisPortSupplier {
protected Jedis jedis;
+ private static Jedis jedis2;
+ private static Jedis jedis3;
+
private static final int REDIS_CLIENT_TIMEOUT =
Math.toIntExact(GeodeAwaitility.getTimeout().toMillis());
@Before
public void setUp() {
jedis = new Jedis("localhost", getPort(), REDIS_CLIENT_TIMEOUT);
+jedis2 = new Jedis("localhost", getPort(), REDIS_CLIENT_TIMEOUT);
+jedis3 = new Jedis("localhost", getPort(), REDIS_CLIENT_TIMEOUT);
}
@After
public void flushAll() {
jedis.flushAll();
+jedis2.flushAll();
+jedis3.flushAll();
}
@After
public void tearDown() {
jedis.close();
+jedis2.close();
+jedis3.close();
}
+ /* Parameter Checks **/
+
@Test
- public void givenNoKeyArgument_returnsWrongNumberOfArgumentsError() {
+ public void givenLessThanTwoArguments_returnsWrongNumberOfArgumentsError() {
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> finish implementation of Redis HScan Command
>
>
> Key: GEODE-8864
> URL: https://issues.apache.org/jira/browse/GEODE-8864
> Project: Geode
> Issue Type: New Feature
> Components: redis
>Reporter: John Hutchison
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8949) Create a Continuous Integration Pipeline
[ https://issues.apache.org/jira/browse/GEODE-8949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293821#comment-17293821 ] ASF GitHub Bot commented on GEODE-8949: --- pdxcodemonkey commented on a change in pull request #754: URL: https://github.com/apache/geode-native/pull/754#discussion_r585704872 ## File path: ci/lib/templates.lib.txt ## @@ -90,7 +90,7 @@ run-clang-tidy -j $(nproc) -quiet (@ def clang_format_bash_task(): -@) set -ueo pipefail -export GEODE_HOME=$(pwd)/geode/expanded/apache-geode-$(cat geode/version) +export GEODE_HOME=$(pwd)/geode Review comment: Why set GEODE_HOME here, and use -DGEODE_ROOT in cmake configure line below? It'd be great to do this consistently, probably using cmake variable in both cases. 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Create a Continuous Integration Pipeline > > > Key: GEODE-8949 > URL: https://issues.apache.org/jira/browse/GEODE-8949 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > > This will be our open source CI for publishing to the Apache Software > Foundation. Two primary tenets are: > * based on Concourse > * PRs will trigger the CI pipeline and can't be merged until they pass the CI > Note: The bulk of this work has been completed in draft [PR > #716|http://github.com/apache/geode-native/pull/716]. See that PR for further > details. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8864) finish implementation of Redis HScan Command
[
https://issues.apache.org/jira/browse/GEODE-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293820#comment-17293820
]
ASF GitHub Bot commented on GEODE-8864:
---
jhutchison commented on a change in pull request #5954:
URL: https://github.com/apache/geode/pull/5954#discussion_r585714865
##
File path:
geode-redis/src/integrationTest/java/org/apache/geode/redis/internal/executor/hash/AbstractHScanIntegrationTest.java
##
@@ -336,48 +441,136 @@ public void
givenMultipleCountsAndMatches_returnsEntriesMatchingLastMatchParamet
}
@Test
- public void givenNegativeCursor_returnsEntriesUsingAbsoluteValueOfCursor() {
-Map entryMap = new HashMap<>();
-entryMap.put("1", "yellow");
-entryMap.put("2", "green");
-entryMap.put("3", "orange");
-jedis.hmset("colors", entryMap);
+ public void should_notReturnValue_givenValueWasRemovedBeforeHSCANISCalled() {
-String cursor = "-100";
-ScanResult> result;
-List> allEntries = new ArrayList<>();
+Map data = new HashMap<>();
+data.put("field_1", "yellow");
+data.put("field_2", "green");
+data.put("field_3", "grey");
+jedis.hmset("colors", data);
-do {
- result = jedis.hscan("colors", cursor);
- allEntries.addAll(result.getResult());
- cursor = result.getCursor();
-} while (!result.isCompleteIteration());
+jedis.hdel("colors", "field_3");
+data.remove("field_3");
-assertThat(allEntries).hasSize(3);
-assertThat(new HashSet<>(allEntries)).isEqualTo(entryMap.entrySet());
+GeodeAwaitility.await().untilAsserted(
+() -> assertThat(jedis.hget("colors", "field_3")).isNull());
+
+ScanResult> result = jedis.hscan("colors", "0");
+
+assertThat(new HashSet<>(result.getResult()))
+.containsExactlyInAnyOrderElementsOf(data.entrySet());
}
@Test
- public void givenCursorGreaterThanUnsignedLongCapacity_returnsCursorError() {
-assertThatThrownBy(() -> jedis.hscan("a", "18446744073709551616"))
-.hasMessageContaining(ERROR_CURSOR);
+ public void should_retun_not_error_given_non_zero_cursor_on_first_call() {
+
+Map data = new HashMap<>();
+data.put("field_1", "yellow");
+data.put("field_2", "green");
+data.put("field_3", "grey");
+jedis.hmset("colors", data);
+
+
+ScanResult> result = jedis.hscan("colors", "5");
+
+assertThat(new HashSet<>(result.getResult()))
+.containsExactlyInAnyOrderElementsOf(data.entrySet());
}
+ / Concurrency ***/
+
+ private final int SIZE_OF_INITIAL_HASH_DATA = 100;
+ final String HASH_KEY = "key";
+ final String BASE_FIELD = "baseField_";
+
@Test
- public void
givenNegativeCursorGreaterThanUnsignedLongCapacity_returnsCursorError() {
-assertThatThrownBy(() -> jedis.hscan("a", "-18446744073709551616"))
-.hasMessageContaining(ERROR_CURSOR);
+ public void
should_notLoseFields_givenConcurrentThreadsDoingHScansAndChangingValues() {
+final Map INITIAL_HASH_DATA =
makeEntrySet(SIZE_OF_INITIAL_HASH_DATA);
+jedis.hset(HASH_KEY, INITIAL_HASH_DATA);
+final int ITERATION_COUNT = 500;
+
+new ConcurrentLoopingThreads(ITERATION_COUNT,
+(i) -> multipleHScanAndAssertOnSizeOfResultSet(jedis,
INITIAL_HASH_DATA),
+(i) -> multipleHScanAndAssertOnSizeOfResultSet(jedis2,
INITIAL_HASH_DATA),
+(i) -> {
+ int fieldSuffix = i % SIZE_OF_INITIAL_HASH_DATA;
+ jedis3.hset(HASH_KEY, BASE_FIELD + fieldSuffix, "new_value_" + i);
+}).run();
+
}
@Test
- public void givenInvalidRegexSyntax_returnsEmptyArray() {
-jedis.hset("a", "1", "green");
-ScanParams scanParams = new ScanParams();
-scanParams.count(1);
-scanParams.match("\\p");
+ public void
should_notLoseKeysForConsistentlyPresentFields_givenConcurrentThreadsAddingAndRemovingFields()
{
+final Map INITIAL_HASH_DATA =
makeEntrySet(SIZE_OF_INITIAL_HASH_DATA);
+jedis.hset(HASH_KEY, INITIAL_HASH_DATA);
+final int ITERATION_COUNT = 500;
+
+new ConcurrentLoopingThreads(ITERATION_COUNT,
+(i) -> multipleHScanAndAssertOnContentOfResultSet(jedis,
INITIAL_HASH_DATA),
+(i) -> multipleHScanAndAssertOnContentOfResultSet(jedis2,
INITIAL_HASH_DATA),
+(i) -> {
+ String field = "new_" + BASE_FIELD + i;
+ jedis3.hset(HASH_KEY, field, "whatever");
+ jedis3.hdel(HASH_KEY, field);
+}).run();
-ScanResult> result = jedis.hscan("a", "0",
scanParams);
+ }
-assertThat(result.getResult()).isEmpty();
+ @Test
+ public void should_notAlterUnderlyingData_givenMultipleConcurrentHscans() {
+final Map INITIAL_HASH_DATA =
makeEntrySet(SIZE_OF_INITIAL_HASH_DATA);
+jedis.hset(HASH_KEY, INITIAL_HASH_DATA);
+final int ITERATION_COUNT = 500;
+
+new ConcurrentLoopingThreads(ITERATION_COUNT,
+(i) -> multipleHScanAndAssertOnContentOfResultSet(jedis,
INITIAL_
[jira] [Commented] (GEODE-8864) finish implementation of Redis HScan Command
[
https://issues.apache.org/jira/browse/GEODE-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293816#comment-17293816
]
ASF GitHub Bot commented on GEODE-8864:
---
sabbey37 commented on a change in pull request #5954:
URL: https://github.com/apache/geode/pull/5954#discussion_r585709795
##
File path:
geode-redis/src/main/java/org/apache/geode/redis/internal/data/RedisHash.java
##
@@ -203,49 +279,122 @@ public int hstrlen(ByteArrayWrapper field) {
return new ArrayList<>(hash.keySet());
}
- public Pair> hscan(Pattern matchPattern, int count,
BigInteger cursor) {
-List returnList = new ArrayList();
-int size = hash.size();
-BigInteger beforeCursor = new BigInteger("0");
-int numElements = 0;
-int i = -1;
-for (Map.Entry entry :
hash.entrySet()) {
- ByteArrayWrapper key = entry.getKey();
- ByteArrayWrapper value = entry.getValue();
- i++;
- if (beforeCursor.compareTo(cursor) < 0) {
-beforeCursor = beforeCursor.add(new BigInteger("1"));
+ public ImmutablePair> hscan(UUID clientID, Pattern
matchPattern,
+ int count,
+ BigInteger cursorParameter) {
+
+int startCursor = cursorParameter.intValue();
Review comment:
That makes sense. Thanks for discussing this!
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> finish implementation of Redis HScan Command
>
>
> Key: GEODE-8864
> URL: https://issues.apache.org/jira/browse/GEODE-8864
> Project: Geode
> Issue Type: New Feature
> Components: redis
>Reporter: John Hutchison
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8864) finish implementation of Redis HScan Command
[
https://issues.apache.org/jira/browse/GEODE-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293808#comment-17293808
]
ASF GitHub Bot commented on GEODE-8864:
---
sabbey37 commented on a change in pull request #5954:
URL: https://github.com/apache/geode/pull/5954#discussion_r585703860
##
File path:
geode-redis/src/main/java/org/apache/geode/redis/internal/executor/hash/HScanExecutor.java
##
@@ -44,6 +45,9 @@
@Override
public RedisResponse executeCommand(Command command,
ExecutionHandlerContext context) {
+
+final UUID CLIENT_ID = context.getClientUUID();
+
List commandElems = command.getProcessedCommand();
Review comment:
I think it makes sense to leave it as an `int` given the cursor
parameter will be an `int` and max size of a hash is the same as an `int`.
Thanks for discussing this with everyone!
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> finish implementation of Redis HScan Command
>
>
> Key: GEODE-8864
> URL: https://issues.apache.org/jira/browse/GEODE-8864
> Project: Geode
> Issue Type: New Feature
> Components: redis
>Reporter: John Hutchison
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8864) finish implementation of Redis HScan Command
[
https://issues.apache.org/jira/browse/GEODE-8864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293798#comment-17293798
]
ASF GitHub Bot commented on GEODE-8864:
---
jhutchison commented on a change in pull request #5954:
URL: https://github.com/apache/geode/pull/5954#discussion_r585691296
##
File path:
geode-redis/src/main/java/org/apache/geode/redis/internal/executor/hash/HScanExecutor.java
##
@@ -44,6 +45,9 @@
@Override
public RedisResponse executeCommand(Command command,
ExecutionHandlerContext context) {
+
+final UUID CLIENT_ID = context.getClientUUID();
+
List commandElems = command.getProcessedCommand();
Review comment:
I made a story to look into this parameters for all the scans and
document differences. Going to leave this as an int for now. Yell at me if
you strongly disagree.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> finish implementation of Redis HScan Command
>
>
> Key: GEODE-8864
> URL: https://issues.apache.org/jira/browse/GEODE-8864
> Project: Geode
> Issue Type: New Feature
> Components: redis
>Reporter: John Hutchison
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8442) Exception in server not identified correctly in client
[ https://issues.apache.org/jira/browse/GEODE-8442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293782#comment-17293782 ] ASF GitHub Bot commented on GEODE-8442: --- pdxcodemonkey commented on pull request #713: URL: https://github.com/apache/geode-native/pull/713#issuecomment-788999841 The test output is a little tricky to see clearly, but the issue in this PR is not `RegisterKeysTest.RegisterAllWithConsistencyDisabled`. If you grep for it, you see the following: ``` Start 55: RegisterKeysTest.RegisterAllWithConsistencyDisabled 18/78 Test #55: RegisterKeysTest.RegisterAllWithConsistencyDisabled ..***Failed 152.70 sec Note: Google Test filter = RegisterKeysTest.RegisterAllWithConsistencyDisabled [ RUN ] RegisterKeysTest.RegisterAllWithConsistencyDisabled [2021-03-01 12:46:10.389389] [0x2d58] [info]Gfsh::execute: start locator --log-level=INFO --dir=RegisterKeysTest/RegisterAllWithConsistencyDisabled/locator/0 --name=RegisterKeysTest_RegisterAllWithConsistencyDisabled_locator_0 --bind-address=localhost --port=50311 --max-heap=256m --J=-Dgemfire.jmx-manager-port=50310 --http-service-port=0 --J=-Dgemfire.jmx-manager-start=true [2021-03-01 12:46:15.701819] [0x2d58] [trace] Gfsh::execute: (1) Executing - start locator --log-level=INFO --dir=RegisterKeysTest/RegisterAllWithConsistencyDisabled/locator/0 --name=RegisterKeysTest_RegisterAllWithConsistencyDisabled_locator_0 --bind-address=localhost --port=50311 --max-heap=256m --J=-Dgemfire.jmx-manager-port=50310 --http-service-port=0 --J=-Dgemfire.jmx-manager-start=true [2021-03-01 12:46:33.904986] [0x2d58] [trace] Gfsh::execute: Locator in C:\Users\build\build\cppcache\integration\test\RegisterKeysTest\RegisterAllWithConsistencyDisabled\locator\0 on 127.0.0.1[50311] as RegisterKeysTest_RegisterAllWithConsistencyDisabled_locator_0 is currently online. [2021-03-01 12:46:33.904986] [0x2d58] [trace] Gfsh::execute: Log File: C:\Users\build\build\cppcache\integration\test\RegisterKeysTest\RegisterAllWithConsistencyDisabled\locator\0\RegisterKeysTest_RegisterAllWithConsistencyDisabled_locator_0.log [2021-03-01 12:46:44.793326] [0x2d58] [info]Gfsh::execute: start server --dir=RegisterKeysTest/RegisterAllWithConsistencyDisabled/server/0 --name=RegisterKeysTest_RegisterAllWithConsistencyDisabled_server_0 --bind-address=localhost --server-port=0 --max-heap=1g --locators=localhost[50311] [2021-03-01 12:46:55.904964] [0x2d58] [trace] Gfsh::execute: (2) Executing - start server --dir=RegisterKeysTest/RegisterAllWithConsistencyDisabled/server/0 --name=RegisterKeysTest_RegisterAllWithConsistencyDisabled_server_0 --bind-address=localhost --server-port=0 --max-heap=1g --locators=localhost[50311] [2021-03-01 12:47:10.389461] [0x2d58] [trace] Gfsh::execute: Server in C:\Users\build\build\cppcache\integration\test\RegisterKeysTest\RegisterAllWithConsistencyDisabled\server\0 on build-7876be09-a95c-4725-b2d3-4cb99aabd716.c.apachegeode-ci.internal[50533] as RegisterKeysTest_RegisterAllWithConsistencyDisabled_server_0 is currently online. [2021-03-01 12:47:10.389461] [0x2d58] [trace] Gfsh::execute: Log File: C:\Users\build\build\cppcache\integration\test\RegisterKeysTest\RegisterAllWithConsistencyDisabled\server\0\RegisterKeysTest_RegisterAllWithConsistencyDisabled_server_0.log [2021-03-01 12:47:24.217552] [0x28ec] [trace] Gfsh::execute: RegisterKeysTest_RegisterAllWithConsistencyDisabled_server_0 | OK | Region "/region" created o.. [2021-03-01 12:48:28.451760] [0x1b0c] [info]Gfsh::execute: stop server --dir=RegisterKeysTest/RegisterAllWithConsistencyDisabled/server/0 [2021-03-01 12:48:28.451760] [0x13a4] [info]Gfsh::execute: stop locator --dir=RegisterKeysTest/RegisterAllWithConsistencyDisabled/locator/0 [2021-03-01 12:48:39.288256] [0x1b0c] [trace] Gfsh::execute: (2) Executing - stop server --dir=RegisterKeysTest/RegisterAllWithConsistencyDisabled/server/0 [2021-03-01 12:48:39.320492] [0x13a4] [trace] Gfsh::execute: (2) Executing - stop locator --dir=RegisterKeysTest/RegisterAllWithConsistencyDisabled/locator/0 [ FAILED ] RegisterKeysTest.RegisterAllWithConsistencyDisabled (152546 ms) [ FAILED ] RegisterKeysTest.RegisterAllWithConsistencyDisabled Start 55: RegisterKeysTest.RegisterAllWithConsistencyDisabled Test #55: RegisterKeysTest.RegisterAllWithConsistencyDisabled .. Passed 96.14 sec ``` So, that test re-ran and passed the second time. The problem is that the run is timing out because one test is stuck. I have a rudimentary Python script that matches the "Start X:" output lines with "Test #X:" result lines, that shows which ones are unmatched, i.e. never completed. Here's the ou
[jira] [Commented] (GEODE-7309) Upgrade Lucene from 6.6.2 to 8.2.0
[
https://issues.apache.org/jira/browse/GEODE-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293694#comment-17293694
]
ASF GitHub Bot commented on GEODE-7309:
---
mkevo commented on a change in pull request #6076:
URL: https://github.com/apache/geode/pull/6076#discussion_r585509589
##
File path: geode-lucene/build.gradle
##
@@ -71,6 +71,7 @@ dependencies {
upgradeTestImplementation(project(':geode-dunit'))
upgradeTestImplementation('commons-io:commons-io')
+ upgradeTestImplementation('org.apache.lucene:lucene-backward-codecs')
Review comment:
I read some articles about Lucene and its similarities and only find
that this backward-codecs is needed for test. So I'm not sure that we need to
ship it with Geode.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Upgrade Lucene from 6.6.2 to 8.2.0
> --
>
> Key: GEODE-7309
> URL: https://issues.apache.org/jira/browse/GEODE-7309
> Project: Geode
> Issue Type: Sub-task
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7309) Upgrade Lucene from 6.6.2 to 8.2.0
[
https://issues.apache.org/jira/browse/GEODE-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293663#comment-17293663
]
ASF GitHub Bot commented on GEODE-7309:
---
mkevo commented on a change in pull request #6076:
URL: https://github.com/apache/geode/pull/6076#discussion_r585509589
##
File path: geode-lucene/build.gradle
##
@@ -71,6 +71,7 @@ dependencies {
upgradeTestImplementation(project(':geode-dunit'))
upgradeTestImplementation('commons-io:commons-io')
+ upgradeTestImplementation('org.apache.lucene:lucene-backward-codecs')
Review comment:
I read some articles about Lucene and its similarities and only find
that this backward-codecs is needed for test. So I'm not sure taht we need to
ship it with Geode.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Upgrade Lucene from 6.6.2 to 8.2.0
> --
>
> Key: GEODE-7309
> URL: https://issues.apache.org/jira/browse/GEODE-7309
> Project: Geode
> Issue Type: Sub-task
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8793) Fix PdxTypeRegistry cleanup upon cluster disconnection
[ https://issues.apache.org/jira/browse/GEODE-8793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293662#comment-17293662 ] ASF GitHub Bot commented on GEODE-8793: --- gaussianrecurrence edited a comment on pull request #715: URL: https://github.com/apache/geode-native/pull/715#issuecomment-788809853 Maybe if @moleske @mmartell @pdxcodemonkey @mivanac @mkevo @albertogpz want to jump it and throw some commments, I'll be appreciated :) 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Fix PdxTypeRegistry cleanup upon cluster disconnection > -- > > Key: GEODE-8793 > URL: https://issues.apache.org/jira/browse/GEODE-8793 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.13.0, 1.13.1 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *GIVEN* A native client cache with on-client-disconnect-clear-pdxType-Ids is > set to "true" (not the best name if you ask me) > *WHEN* the connection towards the cluster is lost > *THEN* PdxTypeRegistry should be cleaned up straight away. > > *Additional information* > **Instead of being cleaned up straight away, PdxTypeRegistry it's cleaned up > every 2 cluster disconnections. > Probably the issue is that semaphores in place are missused. > Consider additionally to change the callback name "cliCallback" as it does > not represent the actual functionality here. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8793) Fix PdxTypeRegistry cleanup upon cluster disconnection
[ https://issues.apache.org/jira/browse/GEODE-8793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293658#comment-17293658 ] ASF GitHub Bot commented on GEODE-8793: --- albertogpz commented on pull request #715: URL: https://github.com/apache/geode-native/pull/715#issuecomment-788843627 Looks good to me! 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Fix PdxTypeRegistry cleanup upon cluster disconnection > -- > > Key: GEODE-8793 > URL: https://issues.apache.org/jira/browse/GEODE-8793 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.13.0, 1.13.1 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *GIVEN* A native client cache with on-client-disconnect-clear-pdxType-Ids is > set to "true" (not the best name if you ask me) > *WHEN* the connection towards the cluster is lost > *THEN* PdxTypeRegistry should be cleaned up straight away. > > *Additional information* > **Instead of being cleaned up straight away, PdxTypeRegistry it's cleaned up > every 2 cluster disconnections. > Probably the issue is that semaphores in place are missused. > Consider additionally to change the callback name "cliCallback" as it does > not represent the actual functionality here. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8793) Fix PdxTypeRegistry cleanup upon cluster disconnection
[ https://issues.apache.org/jira/browse/GEODE-8793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293647#comment-17293647 ] ASF GitHub Bot commented on GEODE-8793: --- gaussianrecurrence commented on pull request #715: URL: https://github.com/apache/geode-native/pull/715#issuecomment-788809853 Maybe if @moleske @mmartell @pdxcodemonkey @mivanac @mkevo @albertogpz want to jump it and throw some commments, they will be appreciated :) 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Fix PdxTypeRegistry cleanup upon cluster disconnection > -- > > Key: GEODE-8793 > URL: https://issues.apache.org/jira/browse/GEODE-8793 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.13.0, 1.13.1 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *GIVEN* A native client cache with on-client-disconnect-clear-pdxType-Ids is > set to "true" (not the best name if you ask me) > *WHEN* the connection towards the cluster is lost > *THEN* PdxTypeRegistry should be cleaned up straight away. > > *Additional information* > **Instead of being cleaned up straight away, PdxTypeRegistry it's cleaned up > every 2 cluster disconnections. > Probably the issue is that semaphores in place are missused. > Consider additionally to change the callback name "cliCallback" as it does > not represent the actual functionality here. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8991) Cached regions are not cleaned up whenever the connection to the cluster is lost
Mario Salazar de Torres created GEODE-8991: -- Summary: Cached regions are not cleaned up whenever the connection to the cluster is lost Key: GEODE-8991 URL: https://issues.apache.org/jira/browse/GEODE-8991 Project: Geode Issue Type: Bug Components: native client Affects Versions: 1.15.0 Reporter: Mario Salazar de Torres Under a cluster restart scenario it can't be guaranteed that all the entries that existed before, exist after the restart. Hence if geode-native client has any cached region registered it should be cleared after the connection is lost towards the cluster in order to ensure cache consistency. This is happenig in the case of the Java client, as described in this part of the documentation: [https://geode.apache.org/docs/guide/12/developing/events/how_client_server_distribution_works.html#how_client_server_distribution_works__section_928BB60066414BEB9FAA7FB3120334A3] However, this is not the case for the native client -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8877) Configurable membership bind address
[ https://issues.apache.org/jira/browse/GEODE-8877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293589#comment-17293589 ] ASF GitHub Bot commented on GEODE-8877: --- alb3rtobr commented on pull request #6066: URL: https://github.com/apache/geode/pull/6066#issuecomment-788773355 > Many Distributed Tests are failing with the same problem you're hitting with this PR Alberto. People are looking into it. ok, lets wait then, thanks! 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Configurable membership bind address > > > Key: GEODE-8877 > URL: https://issues.apache.org/jira/browse/GEODE-8877 > Project: Geode > Issue Type: Improvement >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > > Geode binds the locator and server traffic port by default to 0.0.0.0, but > the membership ports are bound to the local address. > There is a use case that needs this binding to be configurable ([link to the > conversation in the dev list|http://markmail.org/thread/7dwtygtgfcitboy3]): > We would like to use Istio with Geode. For that, a sidecar container (Envoy) > has to be added in each Geode pod. That sidecar container intercepts and > handles all incoming and outgoing traffic for that pod. One of the > requirements set by Istio towards applications trying to integrate with it is > that the application listening ports need to be bound to either localhost or > 0.0.0.0 address (which listens on all interfaces). > > Geode binds the locator and server traffic port by default to 0.0.0.0, but > the membership ports are bound to the pod IP. > And with Envoy listening on the pod IP for incoming traffic and proxying > everything towards localhost, applications binding to pod IPs won't receive > any traffic. > We have tried using the "bind-address" parameter, but that doesn't work for > our case. Geode binds the listening ports to the configured address, but it > also shares that same address to other members in the system as the address > to be used to reach it. If we configure that address to localhost, it just > won't work. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8872) Add client option, to request locators internal host addresses
[ https://issues.apache.org/jira/browse/GEODE-8872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac updated GEODE-8872: Description: Additional option for clients, when pool is created, to request locators internal host addresses. When sending LocatorListRequest in some cases we need to get internal host addresses. To describe use case: When deploying geode, for locator we define hostname-for-clients. This is external address used for WAN, and external clients. If we also deploy some clients in internal network (for example in the same kubernetes cluster as geode), then for those clients to connect with locator, communication will go from internal network to external, then from external to internal. This increases latency, and we should communicate over the shortest path. was: Additional option for clients, when pool is created, to request locators internal host addresses. When sending LocatorListRequest in some cases we need to get internal host addresses. > Add client option, to request locators internal host addresses > --- > > Key: GEODE-8872 > URL: https://issues.apache.org/jira/browse/GEODE-8872 > Project: Geode > Issue Type: New Feature > Components: client/server >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > > Additional option for clients, when pool is created, to request locators > internal host addresses. > When sending LocatorListRequest in some cases we need to get internal host > addresses. > To describe use case: > When deploying geode, for locator we define hostname-for-clients. This is > external address used for WAN, and external clients. > If we also deploy some clients in internal network (for example in the same > kubernetes cluster as geode), then for those clients to connect with locator, > communication will go from internal network to external, then from external > to internal. This increases latency, and we should communicate over the > shortest path. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7309) Upgrade Lucene from 6.6.2 to 8.2.0
[
https://issues.apache.org/jira/browse/GEODE-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17293480#comment-17293480
]
ASF GitHub Bot commented on GEODE-7309:
---
onichols-pivotal commented on a change in pull request #6076:
URL: https://github.com/apache/geode/pull/6076#discussion_r585337063
##
File path: geode-lucene/build.gradle
##
@@ -71,6 +71,7 @@ dependencies {
upgradeTestImplementation(project(':geode-dunit'))
upgradeTestImplementation('commons-io:commons-io')
+ upgradeTestImplementation('org.apache.lucene:lucene-backward-codecs')
Review comment:
just checking, is backward-codecs really only required by tests, not
end-users too? I would naively assume it needs to be shipped with Geode as
well.
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Upgrade Lucene from 6.6.2 to 8.2.0
> --
>
> Key: GEODE-7309
> URL: https://issues.apache.org/jira/browse/GEODE-7309
> Project: Geode
> Issue Type: Sub-task
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
> Time Spent: 5.5h
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
