[jira] [Commented] (GEODE-8615) Update gitignore with tools/gnmsg entries
[ https://issues.apache.org/jira/browse/GEODE-8615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215264#comment-17215264 ] ASF GitHub Bot commented on GEODE-8615: --- alb3rtobr commented on pull request #677: URL: https://github.com/apache/geode-native/pull/677#issuecomment-709910028 cc: @pdxcodemonkey 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 > Update gitignore with tools/gnmsg entries > - > > Key: GEODE-8615 > URL: https://issues.apache.org/jira/browse/GEODE-8615 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > > Following entries should be added to gitignore: > * /tools/gnmsg/.idea/ > * /tools/gnmsg/__pycache__/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8585) Redis SCAN, HSCAN, and SSCAN do not detect illegal parameters
[
https://issues.apache.org/jira/browse/GEODE-8585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215384#comment-17215384
]
ASF GitHub Bot commented on GEODE-8585:
---
sabbey37 commented on a change in pull request #5627:
URL: https://github.com/apache/geode/pull/5627#discussion_r505871824
##
File path:
geode-redis/src/main/java/org/apache/geode/redis/internal/executor/key/ScanExecutor.java
##
@@ -36,91 +39,87 @@
public RedisResponse executeCommand(Command command, ExecutionHandlerContext
context) {
List commandElems = command.getProcessedCommand();
-if (commandElems.size() < 2) {
- return RedisResponse.error(ArityDef.SCAN);
-}
-
String cursorString = command.getStringKey();
-int cursor = 0;
-Pattern matchPattern = null;
-String globMatchString = null;
+BigInteger cursor;
+Pattern matchPattern;
+String globPattern = null;
int count = DEFAULT_COUNT;
+
try {
- cursor = Integer.parseInt(cursorString);
+ cursor = new BigInteger(cursorString).abs();
} catch (NumberFormatException e) {
return RedisResponse.error(ERROR_CURSOR);
}
-if (cursor < 0) {
+
+if (cursor.compareTo(UNSIGNED_LONG_CAPACITY) > 0) {
return RedisResponse.error(ERROR_CURSOR);
}
-if (commandElems.size() > 3) {
- try {
-byte[] bytes = commandElems.get(2);
-String tmp = Coder.bytesToString(bytes);
-if (tmp.equalsIgnoreCase("MATCH")) {
- bytes = commandElems.get(3);
- globMatchString = Coder.bytesToString(bytes);
-} else if (tmp.equalsIgnoreCase("COUNT")) {
- bytes = commandElems.get(3);
- count = Coder.bytesToInt(bytes);
-}
- } catch (NumberFormatException e) {
-return RedisResponse.error(ERROR_COUNT);
- }
+if (!cursor.equals(context.getScanCursor())) {
+ cursor = new BigInteger("0");
}
-if (commandElems.size() > 5) {
- try {
-byte[] bytes = commandElems.get(4);
-String tmp = Coder.bytesToString(bytes);
-if (tmp.equalsIgnoreCase("COUNT")) {
- bytes = commandElems.get(5);
- count = Coder.bytesToInt(bytes);
+for (int i = 2; i < commandElems.size(); i = i + 2) {
+ byte[] commandElemBytes = commandElems.get(i);
+ String keyword = Coder.bytesToString(commandElemBytes);
+ if (keyword.equalsIgnoreCase("MATCH")) {
+commandElemBytes = commandElems.get(i + 1);
+globPattern = Coder.bytesToString(commandElemBytes);
+
+ } else if (keyword.equalsIgnoreCase("COUNT")) {
+commandElemBytes = commandElems.get(i + 1);
+try {
+ count = Coder.bytesToInt(commandElemBytes);
+} catch (NumberFormatException e) {
+ return RedisResponse.error(ERROR_NOT_INTEGER);
+}
+
+if (count < 1) {
+ return RedisResponse.error(ERROR_SYNTAX);
}
- } catch (NumberFormatException e) {
-return RedisResponse.error(ERROR_COUNT);
- }
-}
-if (count < 0) {
- return RedisResponse.error(ERROR_COUNT);
+ } else {
+return RedisResponse.error(ERROR_SYNTAX);
+ }
}
try {
- matchPattern = convertGlobToRegex(globMatchString);
+ matchPattern = convertGlobToRegex(globPattern);
} catch (PatternSyntaxException e) {
- return RedisResponse.error(ERROR_ILLEGAL_GLOB);
+ LogService.getLogger().warn(
+ "Could not compile the pattern: '{}' due to the following exception:
'{}'. SCAN will return an empty list.",
+ globPattern, e.getMessage());
+ return RedisResponse.emptyScan();
}
-List returnList = getIteration(getDataRegion(context).keySet(),
matchPattern, count,
+List returnList = scan(getDataRegion(context).keySet(),
matchPattern, count,
cursor);
+context.setScanCursor(new BigInteger((String) returnList.get(0)));
return RedisResponse.scan(returnList);
}
- private List getIteration(Collection list, Pattern
matchPattern,
- int count, int cursor) {
-List returnList = new ArrayList<>();
+ private List scan(Collection list, Pattern
matchPattern,
Review comment:
Good idea! I just implemented it. Let me know what you think.
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
> Redis SCAN, HSCAN, and SSCAN do not detect illegal parameters
> -
>
> Key: GEODE-8585
> URL: https://issues.apache.org/jira/browse/GEODE-8585
> Project: Geode
> Issue Type: Bug
> Components: redis
[jira] [Created] (GEODE-8621) Redis SPOP can return incorrect string type
Jens Deppe created GEODE-8621: - Summary: Redis SPOP can return incorrect string type Key: GEODE-8621 URL: https://issues.apache.org/jira/browse/GEODE-8621 Project: Geode Issue Type: Test Components: redis Reporter: Jens Deppe When SPOP is used with just a key argument and no count, the single return value should be a bulk string and not a simple string. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8621) Redis SPOP can return incorrect string type
[ https://issues.apache.org/jira/browse/GEODE-8621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8621: -- Labels: pull-request-available (was: ) > Redis SPOP can return incorrect string type > --- > > Key: GEODE-8621 > URL: https://issues.apache.org/jira/browse/GEODE-8621 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Priority: Major > Labels: pull-request-available > > When SPOP is used with just a key argument and no count, the single return > value should be a bulk string and not a simple string. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8621) Redis SPOP can return incorrect string type
[ https://issues.apache.org/jira/browse/GEODE-8621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215410#comment-17215410 ] ASF GitHub Bot commented on GEODE-8621: --- jdeppe-pivotal opened a new pull request #5634: URL: https://github.com/apache/geode/pull/5634 - Without a count argument, SPOP should return the result as a bulk string. Authored-by: Jens Deppe 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 > Redis SPOP can return incorrect string type > --- > > Key: GEODE-8621 > URL: https://issues.apache.org/jira/browse/GEODE-8621 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Priority: Major > > When SPOP is used with just a key argument and no count, the single return > value should be a bulk string and not a simple string. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8622) Redis INCRBYFLOAT should return an error message consistent with native Redis
Jens Deppe created GEODE-8622:
-
Summary: Redis INCRBYFLOAT should return an error message
consistent with native Redis
Key: GEODE-8622
URL: https://issues.apache.org/jira/browse/GEODE-8622
Project: Geode
Issue Type: Improvement
Components: redis
Reporter: Jens Deppe
Geode Redis:
{noformat}
127.0.0.1:6379> set anshin-1 weeble
OK
127.0.0.1:6379> incrbyfloat anshin-1 2.0e2f
(error) ERR Value at this key cannot be incremented numerically
{noformat}
Native Redis:
{noformat}
ERR value is not a valid float
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8613) Remove exclusive access to pool connection creation/removal in native client
[ https://issues.apache.org/jira/browse/GEODE-8613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215427#comment-17215427 ] ASF GitHub Bot commented on GEODE-8613: --- pivotal-jbarrett commented on pull request #676: URL: https://github.com/apache/geode-native/pull/676#issuecomment-710089765 > > I need more time to review this for correctness. I think the locking is required here to both protect concurrent updates to the `m_poolSize` value in various places as well as synchronize the CPU caches of this member. > > Wouldn't that already be guaranteed given that the type of `m_poolSize` is `std::atomic`? I hadn't looked into the type yet but mostly yes that should be safe. Though if the pool and count are mutated independently there could be some issues with a mismatch. I will poke into this later today. 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 exclusive access to pool connection creation/removal in native client > > > Key: GEODE-8613 > URL: https://issues.apache.org/jira/browse/GEODE-8613 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > The Apache Geode C++ native client uses a mutex to grant exclusive access to > the code that creates or removes pool connections (mutex_ member in > ThinClientPoolDM class). The reason behind seems to be to perform atomically > the creation of the connection and the update of the number of connections > (m_poolSize) of the pool so that the number of connections in the pool and > the counter are always aligned. > This mutex is also used to protect the concurrent access to the connection > queue structure (ConnectionQueue class). > So, the mutex is used for two different purposes. > Getting this mutex while creating/removing a pool connection has an impact in > the performance of the client because connections cannot be created > concurrently but there are also negative side effects that could lead to a > freeze of the client if the connection creation is taking a long time (for > example when the DNS is not available and name resolution calls take seconds > to be answered). > A particularly problematic case is that when a minimum number of connections > has been configured in the client, loadconditioning or connection expiration > is configured and the DNS becomes unavailable. If at a given point in time > the number of connections in the pool is lower than the minimum configured, > the thread that restores the minimum number of connections will try to create > a new connection and will not release the mutex until it has finished. This > will block other threads trying to get a connection from the queue > unnecessarily. > In this ticket, it is proposed to remove the locking of the mutex when the > connection is created or removed. An alternative could be to create a new > mutex for the creation or removal of connections so that the access to the > ConnectionQueue is not affected by the creation/removal of connections but I > do not consider it necessary just to maintain consistent (and not only > eventually consistent) the number of connection of the pool and the counter > of the connections (m_poolSize). > Note that this ticket does not propose to remove the use of the mutex to > access the ConnectionQueue. This will still be necessary to protect > concurrent access to the connection queue data structure. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8585) Redis SCAN, HSCAN, and SSCAN do not detect illegal parameters
[ https://issues.apache.org/jira/browse/GEODE-8585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215430#comment-17215430 ] ASF GitHub Bot commented on GEODE-8585: --- lgtm-com[bot] commented on pull request #5627: URL: https://github.com/apache/geode/pull/5627#issuecomment-710095163 This pull request **introduces 2 alerts** when merging 681e73630254e9db9800d86663411e06b28749a0 into 4c4820207e263f1a9d11f34df5cd6cd2f9daf973 - [view on LGTM.com](https://lgtm.com/projects/g/apache/geode/rev/pr-65a447ce28c79e4440b13fc5873863b002516dd3) **new alerts:** * 2 for Dereferenced variable may be null 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 > Redis SCAN, HSCAN, and SSCAN do not detect illegal parameters > - > > Key: GEODE-8585 > URL: https://issues.apache.org/jira/browse/GEODE-8585 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Sarah Abbey >Assignee: Sarah Abbey >Priority: Minor > Labels: pull-request-available > > The parameter parsing for SCAN will not detect some illegal parameters. We > found that if we left off the MATCH keyword it just ignored the match string > we gave it. Native redis throws a syntax error. We also saw that COUNT could > follow MATCH but MATCH could not follow COUNT. I think it also allows COUNT > to be specified twice. HSCAN and SSCAN probably have similar issues. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8585) Redis SCAN, HSCAN, and SSCAN do not detect illegal parameters
[ https://issues.apache.org/jira/browse/GEODE-8585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215438#comment-17215438 ] ASF GitHub Bot commented on GEODE-8585: --- lgtm-com[bot] removed a comment on pull request #5627: URL: https://github.com/apache/geode/pull/5627#issuecomment-710095163 This pull request **introduces 2 alerts** when merging 681e73630254e9db9800d86663411e06b28749a0 into 4c4820207e263f1a9d11f34df5cd6cd2f9daf973 - [view on LGTM.com](https://lgtm.com/projects/g/apache/geode/rev/pr-65a447ce28c79e4440b13fc5873863b002516dd3) **new alerts:** * 2 for Dereferenced variable may be null 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 > Redis SCAN, HSCAN, and SSCAN do not detect illegal parameters > - > > Key: GEODE-8585 > URL: https://issues.apache.org/jira/browse/GEODE-8585 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Sarah Abbey >Assignee: Sarah Abbey >Priority: Minor > Labels: pull-request-available > > The parameter parsing for SCAN will not detect some illegal parameters. We > found that if we left off the MATCH keyword it just ignored the match string > we gave it. Native redis throws a syntax error. We also saw that COUNT could > follow MATCH but MATCH could not follow COUNT. I think it also allows COUNT > to be specified twice. HSCAN and SSCAN probably have similar issues. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8620) Actual redundancy of -1 in restore redundancy result
[ https://issues.apache.org/jira/browse/GEODE-8620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans reassigned GEODE-8620: -- Assignee: Donal Evans > Actual redundancy of -1 in restore redundancy result > > > Key: GEODE-8620 > URL: https://issues.apache.org/jira/browse/GEODE-8620 > Project: Geode > Issue Type: Bug > Components: gfsh, management >Affects Versions: 1.13.0 >Reporter: Aaron Lindsey >Assignee: Donal Evans >Priority: Major > > Steps to reproduce: > # Create a geode cluster with 1 locator and 2 servers. > # Create a region of type PARTITION_REDUNDANT. > # Put an entry into the region. > # Trigger a restore redundancy operation via the management REST API or gfsh. > # The result from the restore redundancy operation states that the actual > redundancy for the region is -1. However, the expected redundancy at this > point is 1 because there should be enough cache servers in the cluster to > hold the redundant copy. > # Stop one of the servers. > # Trigger another restore redundancy operation via the management REST API > or gfsh. > # The result from the second restore redundancy operation again states that > the actual redundancy for the region is -1. However, the region should be > counted as having zero redundant copies at this point because there is only > one cache server. > I encountered this issue while using the management REST API, although the > same issue happens in the gfsh command. I assume fixing the gfsh command > would also fix the management REST API. If not, I can break this out into two > separate JIRAs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8621) Redis SPOP can return incorrect string type
[ https://issues.apache.org/jira/browse/GEODE-8621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215542#comment-17215542 ] ASF GitHub Bot commented on GEODE-8621: --- jdeppe-pivotal merged pull request #5634: URL: https://github.com/apache/geode/pull/5634 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 > Redis SPOP can return incorrect string type > --- > > Key: GEODE-8621 > URL: https://issues.apache.org/jira/browse/GEODE-8621 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Priority: Major > Labels: pull-request-available > > When SPOP is used with just a key argument and no count, the single return > value should be a bulk string and not a simple string. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8585) Redis SCAN, HSCAN, and SSCAN do not detect illegal parameters
[ https://issues.apache.org/jira/browse/GEODE-8585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215544#comment-17215544 ] ASF GitHub Bot commented on GEODE-8585: --- sabbey37 merged pull request #5627: URL: https://github.com/apache/geode/pull/5627 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 > Redis SCAN, HSCAN, and SSCAN do not detect illegal parameters > - > > Key: GEODE-8585 > URL: https://issues.apache.org/jira/browse/GEODE-8585 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Sarah Abbey >Assignee: Sarah Abbey >Priority: Minor > Labels: pull-request-available > > The parameter parsing for SCAN will not detect some illegal parameters. We > found that if we left off the MATCH keyword it just ignored the match string > we gave it. Native redis throws a syntax error. We also saw that COUNT could > follow MATCH but MATCH could not follow COUNT. I think it also allows COUNT > to be specified twice. HSCAN and SSCAN probably have similar issues. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8621) Redis SPOP can return incorrect string type
[ https://issues.apache.org/jira/browse/GEODE-8621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215546#comment-17215546 ] ASF subversion and git services commented on GEODE-8621: Commit f0ee8e2bbce379ae5e5994b886808d15f3fed72d in geode's branch refs/heads/develop from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f0ee8e2 ] GEODE-8621: Redis SPOP can return incorrect string type (#5634) - Without a count argument, SPOP should return the result as a bulk string. > Redis SPOP can return incorrect string type > --- > > Key: GEODE-8621 > URL: https://issues.apache.org/jira/browse/GEODE-8621 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Priority: Major > Labels: pull-request-available > > When SPOP is used with just a key argument and no count, the single return > value should be a bulk string and not a simple string. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8585) Redis SCAN, HSCAN, and SSCAN do not detect illegal parameters
[ https://issues.apache.org/jira/browse/GEODE-8585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215548#comment-17215548 ] ASF subversion and git services commented on GEODE-8585: Commit f5dabd2561ff430f55d2bb8fa8ead050ba84d52f in geode's branch refs/heads/develop from Sarah [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f5dabd2 ] GEODE-8585: Redis SCAN, HSCAN, and SSCAN do not detect illegal parameters (#5627) > Redis SCAN, HSCAN, and SSCAN do not detect illegal parameters > - > > Key: GEODE-8585 > URL: https://issues.apache.org/jira/browse/GEODE-8585 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Sarah Abbey >Assignee: Sarah Abbey >Priority: Minor > Labels: pull-request-available > > The parameter parsing for SCAN will not detect some illegal parameters. We > found that if we left off the MATCH keyword it just ignored the match string > we gave it. Native redis throws a syntax error. We also saw that COUNT could > follow MATCH but MATCH could not follow COUNT. I think it also allows COUNT > to be specified twice. HSCAN and SSCAN probably have similar issues. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8621) Redis SPOP can return incorrect string type
[ https://issues.apache.org/jira/browse/GEODE-8621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215547#comment-17215547 ] ASF subversion and git services commented on GEODE-8621: Commit f0ee8e2bbce379ae5e5994b886808d15f3fed72d in geode's branch refs/heads/develop from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f0ee8e2 ] GEODE-8621: Redis SPOP can return incorrect string type (#5634) - Without a count argument, SPOP should return the result as a bulk string. > Redis SPOP can return incorrect string type > --- > > Key: GEODE-8621 > URL: https://issues.apache.org/jira/browse/GEODE-8621 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Priority: Major > Labels: pull-request-available > > When SPOP is used with just a key argument and no count, the single return > value should be a bulk string and not a simple string. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8585) Redis SCAN, HSCAN, and SSCAN do not detect illegal parameters
[ https://issues.apache.org/jira/browse/GEODE-8585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215552#comment-17215552 ] ASF subversion and git services commented on GEODE-8585: Commit f5dabd2561ff430f55d2bb8fa8ead050ba84d52f in geode's branch refs/heads/develop from Sarah [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f5dabd2 ] GEODE-8585: Redis SCAN, HSCAN, and SSCAN do not detect illegal parameters (#5627) > Redis SCAN, HSCAN, and SSCAN do not detect illegal parameters > - > > Key: GEODE-8585 > URL: https://issues.apache.org/jira/browse/GEODE-8585 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Sarah Abbey >Assignee: Sarah Abbey >Priority: Minor > Labels: pull-request-available > > The parameter parsing for SCAN will not detect some illegal parameters. We > found that if we left off the MATCH keyword it just ignored the match string > we gave it. Native redis throws a syntax error. We also saw that COUNT could > follow MATCH but MATCH could not follow COUNT. I think it also allows COUNT > to be specified twice. HSCAN and SSCAN probably have similar issues. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
Jacob Barrett created GEODE-8623:
Summary: Timing between DNS and Geode startup can result in
permanent unknown host exceptions.
Key: GEODE-8623
URL: https://issues.apache.org/jira/browse/GEODE-8623
Project: Geode
Issue Type: Bug
Affects Versions: 1.13.0, 1.12.0, 1.11.0, 1.9.2, 1.10.0, 1.9.1, 1.9.0,
1.14.0, 1.13.1
Reporter: Jacob Barrett
In a managed environment were local host name DNS entries and the startup of
Geode happen concurrently it is possible for Geode to fail name resolution in
the local hostname caching. If it fails to resolve the local hostname when
loading the caching utility class then any service dependent on this name will
fail without chance for recovery.
{code}
[error 2020/09/30 19:50:21.644 UTC tid=0x1] Jmx manager could not be
started because java.net.UnknownHostException
org.apache.geode.management.ManagementException: java.net.UnknownHostException
at
org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:133)
at
org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:432)
at
org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:181)
at
org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:127)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2063)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:606)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1239)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:219)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:171)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
at
org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
at
org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:887)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:803)
at
org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:732)
at
org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:251)
Caused by: java.net.UnknownHostException
at
org.apache.geode.internal.net.SocketCreator.getLocalHost(SocketCreator.java:285)
at
org.apache.geode.management.internal.ManagementAgent.configureAndStart(ManagementAgent.java:310)
at
org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:131)
... 14 more
[error 2020/09/30 19:50:21.724 UTC tid=0x1]
org.apache.geode.management.ManagementException: java.net.UnknownHostException
Exception in thread "main" org.apache.geode.management.ManagementException:
java.net.UnknownHostException
at
org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:133)
at
org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:432)
at
org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:181)
at
org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:127)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2063)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:606)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1239)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:219)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:171)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
at
org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
at
org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:887)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:803)
at
org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:732)
at
org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:251)
Caused by: java.net.UnknownHostException
at
org.apache.geode.internal.net.SocketCreator.getLocalHost(SocketCreator.java:285)
at
org.apache.geode.mana
[jira] [Updated] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-8623:
-
Priority: Minor (was: Major)
> Timing between DNS and Geode startup can result in permanent unknown host
> exceptions.
> -
>
> Key: GEODE-8623
> URL: https://issues.apache.org/jira/browse/GEODE-8623
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.9.0, 1.9.1, 1.10.0, 1.9.2, 1.11.0, 1.12.0, 1.13.0,
> 1.14.0, 1.13.1
>Reporter: Jacob Barrett
>Priority: Minor
>
> In a managed environment were local host name DNS entries and the startup of
> Geode happen concurrently it is possible for Geode to fail name resolution in
> the local hostname caching. If it fails to resolve the local hostname when
> loading the caching utility class then any service dependent on this name
> will fail without chance for recovery.
> {code}
> [error 2020/09/30 19:50:21.644 UTC tid=0x1] Jmx manager could not be
> started because java.net.UnknownHostException
> org.apache.geode.management.ManagementException: java.net.UnknownHostException
> at
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:133)
> at
> org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:432)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:181)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:127)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2063)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:606)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1239)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:219)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:171)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at
> org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
> at
> org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:887)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:803)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:732)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:251)
> Caused by: java.net.UnknownHostException
> at
> org.apache.geode.internal.net.SocketCreator.getLocalHost(SocketCreator.java:285)
> at
> org.apache.geode.management.internal.ManagementAgent.configureAndStart(ManagementAgent.java:310)
> at
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:131)
> ... 14 more
> [error 2020/09/30 19:50:21.724 UTC tid=0x1]
> org.apache.geode.management.ManagementException: java.net.UnknownHostException
> Exception in thread "main" org.apache.geode.management.ManagementException:
> java.net.UnknownHostException
> at
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:133)
> at
> org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:432)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:181)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:127)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2063)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:606)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1239)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:219)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:171)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at
> org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
> at
> org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:887)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLaunc
[jira] [Commented] (GEODE-8324) Events are not being replicated from one WAN site to another when there are multiple paths between the sites and the direct one is stopped
[
https://issues.apache.org/jira/browse/GEODE-8324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215578#comment-17215578
]
ASF subversion and git services commented on GEODE-8324:
Commit f57dea3f3633bdc749f16649d6ce4dbef1fcf752 in geode's branch
refs/heads/feature/GEODE-8324 from Barry Oglesby
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f57dea3 ]
GEODE-8324: Added dunit test
> Events are not being replicated from one WAN site to another when there are
> multiple paths between the sites and the direct one is stopped
> --
>
> Key: GEODE-8324
> URL: https://issues.apache.org/jira/browse/GEODE-8324
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: caching-applications, pull-request-available
>
> Scenario
>
> The configuration is a normal star/mesh pattern where each site is connected
> to each other site.
> So, there are 2 paths from site-A to site-B:
> - the direct (site-A -> site-B)
> - the indirect path (site-A -> site-C -> site-B)
> If the direct path (meaning the sender in site-A to site-B) is stopped and a
> put is done in site-A, site-B doesn't receive the event even though the
> indirect path is not stopped.
> Here is the behavior:
> Site-A - dsid=1
> Site-B - dsid=2
> Site-C - dsid=3
> Site-A
> --
> Since site-A is configured with site-B and site-C, its events will contain
> recipient dsids for those sites (2 and 3 below).
> The event sent to site-C will look like:
> {noformat}
> AbstractGatewaySender.distribute sender=site-C processing local event
> newCallbackArg=GatewaySenderEventCallbackArgument
> [originatingSenderId=1;recipientGatewayReceivers={3, 2}]; region=/data; key=0
> {noformat}
> Site-C
> --
> Site-C receives the event:
> {noformat}
> GatewayReceiverCommand.cmdExecute processing create region=/data; key=0
> {noformat}
> The sender to site-B drops the event since it thinks it is already a
> recipient:
> {noformat}
> AbstractGatewaySender.distribute sender=site-B received event from remote
> site receivedCallbackArg=GatewaySenderEventCallbackArgument
> [originatingSenderId=1;recipientGatewayReceivers={3, 2}]; region=/data;
> key=0; eventId=EventID[id=25
> bytes;threadID=0x10030|1;sequenceID=0;bucketId=48]
> AbstractGatewaySender.distribute sender=site-B dropping event since it is
> already a recipient
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8324) Events are not being replicated from one WAN site to another when there are multiple paths between the sites and the direct one is stopped
[
https://issues.apache.org/jira/browse/GEODE-8324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215580#comment-17215580
]
ASF subversion and git services commented on GEODE-8324:
Commit f57dea3f3633bdc749f16649d6ce4dbef1fcf752 in geode's branch
refs/heads/feature/GEODE-8324 from Barry Oglesby
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f57dea3 ]
GEODE-8324: Added dunit test
> Events are not being replicated from one WAN site to another when there are
> multiple paths between the sites and the direct one is stopped
> --
>
> Key: GEODE-8324
> URL: https://issues.apache.org/jira/browse/GEODE-8324
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: caching-applications, pull-request-available
>
> Scenario
>
> The configuration is a normal star/mesh pattern where each site is connected
> to each other site.
> So, there are 2 paths from site-A to site-B:
> - the direct (site-A -> site-B)
> - the indirect path (site-A -> site-C -> site-B)
> If the direct path (meaning the sender in site-A to site-B) is stopped and a
> put is done in site-A, site-B doesn't receive the event even though the
> indirect path is not stopped.
> Here is the behavior:
> Site-A - dsid=1
> Site-B - dsid=2
> Site-C - dsid=3
> Site-A
> --
> Since site-A is configured with site-B and site-C, its events will contain
> recipient dsids for those sites (2 and 3 below).
> The event sent to site-C will look like:
> {noformat}
> AbstractGatewaySender.distribute sender=site-C processing local event
> newCallbackArg=GatewaySenderEventCallbackArgument
> [originatingSenderId=1;recipientGatewayReceivers={3, 2}]; region=/data; key=0
> {noformat}
> Site-C
> --
> Site-C receives the event:
> {noformat}
> GatewayReceiverCommand.cmdExecute processing create region=/data; key=0
> {noformat}
> The sender to site-B drops the event since it thinks it is already a
> recipient:
> {noformat}
> AbstractGatewaySender.distribute sender=site-B received event from remote
> site receivedCallbackArg=GatewaySenderEventCallbackArgument
> [originatingSenderId=1;recipientGatewayReceivers={3, 2}]; region=/data;
> key=0; eventId=EventID[id=25
> bytes;threadID=0x10030|1;sequenceID=0;bucketId=48]
> AbstractGatewaySender.distribute sender=site-B dropping event since it is
> already a recipient
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8324) Events are not being replicated from one WAN site to another when there are multiple paths between the sites and the direct one is stopped
[
https://issues.apache.org/jira/browse/GEODE-8324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215583#comment-17215583
]
ASF subversion and git services commented on GEODE-8324:
Commit f57dea3f3633bdc749f16649d6ce4dbef1fcf752 in geode's branch
refs/heads/feature/GEODE-8324 from Barry Oglesby
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f57dea3 ]
GEODE-8324: Added dunit test
> Events are not being replicated from one WAN site to another when there are
> multiple paths between the sites and the direct one is stopped
> --
>
> Key: GEODE-8324
> URL: https://issues.apache.org/jira/browse/GEODE-8324
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: caching-applications, pull-request-available
>
> Scenario
>
> The configuration is a normal star/mesh pattern where each site is connected
> to each other site.
> So, there are 2 paths from site-A to site-B:
> - the direct (site-A -> site-B)
> - the indirect path (site-A -> site-C -> site-B)
> If the direct path (meaning the sender in site-A to site-B) is stopped and a
> put is done in site-A, site-B doesn't receive the event even though the
> indirect path is not stopped.
> Here is the behavior:
> Site-A - dsid=1
> Site-B - dsid=2
> Site-C - dsid=3
> Site-A
> --
> Since site-A is configured with site-B and site-C, its events will contain
> recipient dsids for those sites (2 and 3 below).
> The event sent to site-C will look like:
> {noformat}
> AbstractGatewaySender.distribute sender=site-C processing local event
> newCallbackArg=GatewaySenderEventCallbackArgument
> [originatingSenderId=1;recipientGatewayReceivers={3, 2}]; region=/data; key=0
> {noformat}
> Site-C
> --
> Site-C receives the event:
> {noformat}
> GatewayReceiverCommand.cmdExecute processing create region=/data; key=0
> {noformat}
> The sender to site-B drops the event since it thinks it is already a
> recipient:
> {noformat}
> AbstractGatewaySender.distribute sender=site-B received event from remote
> site receivedCallbackArg=GatewaySenderEventCallbackArgument
> [originatingSenderId=1;recipientGatewayReceivers={3, 2}]; region=/data;
> key=0; eventId=EventID[id=25
> bytes;threadID=0x10030|1;sequenceID=0;bucketId=48]
> AbstractGatewaySender.distribute sender=site-B dropping event since it is
> already a recipient
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8324) Events are not being replicated from one WAN site to another when there are multiple paths between the sites and the direct one is stopped
[
https://issues.apache.org/jira/browse/GEODE-8324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215584#comment-17215584
]
ASF subversion and git services commented on GEODE-8324:
Commit f57dea3f3633bdc749f16649d6ce4dbef1fcf752 in geode's branch
refs/heads/feature/GEODE-8324 from Barry Oglesby
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f57dea3 ]
GEODE-8324: Added dunit test
> Events are not being replicated from one WAN site to another when there are
> multiple paths between the sites and the direct one is stopped
> --
>
> Key: GEODE-8324
> URL: https://issues.apache.org/jira/browse/GEODE-8324
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: caching-applications, pull-request-available
>
> Scenario
>
> The configuration is a normal star/mesh pattern where each site is connected
> to each other site.
> So, there are 2 paths from site-A to site-B:
> - the direct (site-A -> site-B)
> - the indirect path (site-A -> site-C -> site-B)
> If the direct path (meaning the sender in site-A to site-B) is stopped and a
> put is done in site-A, site-B doesn't receive the event even though the
> indirect path is not stopped.
> Here is the behavior:
> Site-A - dsid=1
> Site-B - dsid=2
> Site-C - dsid=3
> Site-A
> --
> Since site-A is configured with site-B and site-C, its events will contain
> recipient dsids for those sites (2 and 3 below).
> The event sent to site-C will look like:
> {noformat}
> AbstractGatewaySender.distribute sender=site-C processing local event
> newCallbackArg=GatewaySenderEventCallbackArgument
> [originatingSenderId=1;recipientGatewayReceivers={3, 2}]; region=/data; key=0
> {noformat}
> Site-C
> --
> Site-C receives the event:
> {noformat}
> GatewayReceiverCommand.cmdExecute processing create region=/data; key=0
> {noformat}
> The sender to site-B drops the event since it thinks it is already a
> recipient:
> {noformat}
> AbstractGatewaySender.distribute sender=site-B received event from remote
> site receivedCallbackArg=GatewaySenderEventCallbackArgument
> [originatingSenderId=1;recipientGatewayReceivers={3, 2}]; region=/data;
> key=0; eventId=EventID[id=25
> bytes;threadID=0x10030|1;sequenceID=0;bucketId=48]
> AbstractGatewaySender.distribute sender=site-B dropping event since it is
> already a recipient
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8324) Events are not being replicated from one WAN site to another when there are multiple paths between the sites and the direct one is stopped
[
https://issues.apache.org/jira/browse/GEODE-8324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215587#comment-17215587
]
ASF subversion and git services commented on GEODE-8324:
Commit f57dea3f3633bdc749f16649d6ce4dbef1fcf752 in geode's branch
refs/heads/feature/GEODE-8324 from Barry Oglesby
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f57dea3 ]
GEODE-8324: Added dunit test
> Events are not being replicated from one WAN site to another when there are
> multiple paths between the sites and the direct one is stopped
> --
>
> Key: GEODE-8324
> URL: https://issues.apache.org/jira/browse/GEODE-8324
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: caching-applications, pull-request-available
>
> Scenario
>
> The configuration is a normal star/mesh pattern where each site is connected
> to each other site.
> So, there are 2 paths from site-A to site-B:
> - the direct (site-A -> site-B)
> - the indirect path (site-A -> site-C -> site-B)
> If the direct path (meaning the sender in site-A to site-B) is stopped and a
> put is done in site-A, site-B doesn't receive the event even though the
> indirect path is not stopped.
> Here is the behavior:
> Site-A - dsid=1
> Site-B - dsid=2
> Site-C - dsid=3
> Site-A
> --
> Since site-A is configured with site-B and site-C, its events will contain
> recipient dsids for those sites (2 and 3 below).
> The event sent to site-C will look like:
> {noformat}
> AbstractGatewaySender.distribute sender=site-C processing local event
> newCallbackArg=GatewaySenderEventCallbackArgument
> [originatingSenderId=1;recipientGatewayReceivers={3, 2}]; region=/data; key=0
> {noformat}
> Site-C
> --
> Site-C receives the event:
> {noformat}
> GatewayReceiverCommand.cmdExecute processing create region=/data; key=0
> {noformat}
> The sender to site-B drops the event since it thinks it is already a
> recipient:
> {noformat}
> AbstractGatewaySender.distribute sender=site-B received event from remote
> site receivedCallbackArg=GatewaySenderEventCallbackArgument
> [originatingSenderId=1;recipientGatewayReceivers={3, 2}]; region=/data;
> key=0; eventId=EventID[id=25
> bytes;threadID=0x10030|1;sequenceID=0;bucketId=48]
> AbstractGatewaySender.distribute sender=site-B dropping event since it is
> already a recipient
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8612) Remove unused Redis constants
[ https://issues.apache.org/jira/browse/GEODE-8612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sarah Abbey resolved GEODE-8612. Fix Version/s: 1.14.0 Resolution: Fixed > Remove unused Redis constants > - > > Key: GEODE-8612 > URL: https://issues.apache.org/jira/browse/GEODE-8612 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Sarah Abbey >Assignee: Sarah Abbey >Priority: Trivial > Labels: pull-request-available > Fix For: 1.14.0 > > > Remove constants we no longer use in `RedisConstants` -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8585) Redis SCAN, HSCAN, and SSCAN do not detect illegal parameters
[ https://issues.apache.org/jira/browse/GEODE-8585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sarah Abbey resolved GEODE-8585. Fix Version/s: 1.14.0 Resolution: Fixed > Redis SCAN, HSCAN, and SSCAN do not detect illegal parameters > - > > Key: GEODE-8585 > URL: https://issues.apache.org/jira/browse/GEODE-8585 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Sarah Abbey >Assignee: Sarah Abbey >Priority: Minor > Labels: pull-request-available > Fix For: 1.14.0 > > > The parameter parsing for SCAN will not detect some illegal parameters. We > found that if we left off the MATCH keyword it just ignored the match string > we gave it. Native redis throws a syntax error. We also saw that COUNT could > follow MATCH but MATCH could not follow COUNT. I think it also allows COUNT > to be specified twice. HSCAN and SSCAN probably have similar issues. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8621) Redis SPOP can return incorrect string type
[ https://issues.apache.org/jira/browse/GEODE-8621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sarah Abbey resolved GEODE-8621. Fix Version/s: 1.14.0 Assignee: Jens Deppe Resolution: Fixed > Redis SPOP can return incorrect string type > --- > > Key: GEODE-8621 > URL: https://issues.apache.org/jira/browse/GEODE-8621 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > When SPOP is used with just a key argument and no count, the single return > value should be a bulk string and not a simple string. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8610) Add parameter checking to unsupported Redis commands
[ https://issues.apache.org/jira/browse/GEODE-8610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215607#comment-17215607 ] ASF GitHub Bot commented on GEODE-8610: --- sabbey37 opened a new pull request #5635: URL: https://github.com/apache/geode/pull/5635 Create tests/add parameter check 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 parameter checking to unsupported Redis commands > > > Key: GEODE-8610 > URL: https://issues.apache.org/jira/browse/GEODE-8610 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Sarah Abbey >Assignee: Sarah Abbey >Priority: Minor > > Create tests/add parameter check -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8610) Add parameter checking to unsupported Redis commands
[ https://issues.apache.org/jira/browse/GEODE-8610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8610: -- Labels: pull-request-available (was: ) > Add parameter checking to unsupported Redis commands > > > Key: GEODE-8610 > URL: https://issues.apache.org/jira/browse/GEODE-8610 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Sarah Abbey >Assignee: Sarah Abbey >Priority: Minor > Labels: pull-request-available > > Create tests/add parameter check -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8624) Improve INCRBYFLOAT accuracy for very large values
Jens Deppe created GEODE-8624:
-
Summary: Improve INCRBYFLOAT accuracy for very large values
Key: GEODE-8624
URL: https://issues.apache.org/jira/browse/GEODE-8624
Project: Geode
Issue Type: Improvement
Components: redis
Reporter: Jens Deppe
Currently native redis appears to be able to apply {{INCRBYFLOAT}} on values
that are below the max of unsigned long long (18446744073709551615). However,
since we're treating numbers as {{double}}s we can lose precision for very
large values. For example:
{noformat}
set val 18446744073709551614
incrbyfloat val 1{noformat}
incorrectly returns {{18446744073709552000}}
Native redis produces a correct result.
We should consider switching to using {{BigInteger}} for all commands which
perform calculations: {{INCR, INCR, INCRBYFLOAT, HINCRBY, HINCRBYFLOAT}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8622) Redis INCRBYFLOAT should return an error message consistent with native Redis
[
https://issues.apache.org/jira/browse/GEODE-8622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-8622:
--
Labels: pull-request-available (was: )
> Redis INCRBYFLOAT should return an error message consistent with native Redis
> -
>
> Key: GEODE-8622
> URL: https://issues.apache.org/jira/browse/GEODE-8622
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> Geode Redis:
> {noformat}
> 127.0.0.1:6379> set anshin-1 weeble
> OK
> 127.0.0.1:6379> incrbyfloat anshin-1 2.0e2f
> (error) ERR Value at this key cannot be incremented numerically
> {noformat}
> Native Redis:
> {noformat}
> ERR value is not a valid float
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8622) Redis INCRBYFLOAT should return an error message consistent with native Redis
[
https://issues.apache.org/jira/browse/GEODE-8622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215609#comment-17215609
]
ASF GitHub Bot commented on GEODE-8622:
---
jdeppe-pivotal opened a new pull request #5636:
URL: https://github.com/apache/geode/pull/5636
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
> Redis INCRBYFLOAT should return an error message consistent with native Redis
> -
>
> Key: GEODE-8622
> URL: https://issues.apache.org/jira/browse/GEODE-8622
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
>
> Geode Redis:
> {noformat}
> 127.0.0.1:6379> set anshin-1 weeble
> OK
> 127.0.0.1:6379> incrbyfloat anshin-1 2.0e2f
> (error) ERR Value at this key cannot be incremented numerically
> {noformat}
> Native Redis:
> {noformat}
> ERR value is not a valid float
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8615) Update gitignore with tools/gnmsg entries
[ https://issues.apache.org/jira/browse/GEODE-8615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215629#comment-17215629 ] ASF GitHub Bot commented on GEODE-8615: --- pdxcodemonkey merged pull request #677: URL: https://github.com/apache/geode-native/pull/677 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 > Update gitignore with tools/gnmsg entries > - > > Key: GEODE-8615 > URL: https://issues.apache.org/jira/browse/GEODE-8615 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > > Following entries should be added to gitignore: > * /tools/gnmsg/.idea/ > * /tools/gnmsg/__pycache__/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8615) Update gitignore with tools/gnmsg entries
[ https://issues.apache.org/jira/browse/GEODE-8615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215632#comment-17215632 ] ASF subversion and git services commented on GEODE-8615: Commit d8b34deaebe057e20690561d6f613de7af3db8e3 in geode-native's branch refs/heads/develop from Alberto Bustamante Reyes [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=d8b34de ] GEODE-8615: Update gitignore with tools/gnmsg entries (#677) > Update gitignore with tools/gnmsg entries > - > > Key: GEODE-8615 > URL: https://issues.apache.org/jira/browse/GEODE-8615 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > > Following entries should be added to gitignore: > * /tools/gnmsg/.idea/ > * /tools/gnmsg/__pycache__/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8615) Update gitignore with tools/gnmsg entries
[ https://issues.apache.org/jira/browse/GEODE-8615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215633#comment-17215633 ] ASF subversion and git services commented on GEODE-8615: Commit d8b34deaebe057e20690561d6f613de7af3db8e3 in geode-native's branch refs/heads/develop from Alberto Bustamante Reyes [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=d8b34de ] GEODE-8615: Update gitignore with tools/gnmsg entries (#677) > Update gitignore with tools/gnmsg entries > - > > Key: GEODE-8615 > URL: https://issues.apache.org/jira/browse/GEODE-8615 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > > Following entries should be added to gitignore: > * /tools/gnmsg/.idea/ > * /tools/gnmsg/__pycache__/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8593) Update native client examples to use Builder pattern
[
https://issues.apache.org/jira/browse/GEODE-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215634#comment-17215634
]
ASF GitHub Bot commented on GEODE-8593:
---
pdxcodemonkey commented on a change in pull request #675:
URL: https://github.com/apache/geode-native/pull/675#discussion_r506695830
##
File path:
docs/geode-native-docs-cpp/getting-started/getting-started-nc-client.html.md.erb
##
@@ -37,36 +37,37 @@ To connect to a server, your application must follow these
steps:
1. Instantiate a `CacheFactory`, setting characteristics of interest (for
example, `log-level`).
1. Create a cache and use it to instantiate a `PoolFactory`, specifying the
hostname and port for the server locator.
1. Create a named pool of network connections.
-1. Instantiate a region of the desired type (usually CACHING_PROXY or PROXY)
and connect it by name to its counterpart on the server.
+1. Instantiate a region of the desired type (usually PROXY, sometimes
CACHING_PROXY) and connect it by name to its counterpart on the server.
Once the connection pool and the shared region are in place, your client
application is ready to share data with the server.
**Server Connection: C++ Example**
-This example of connecting to the server is taken from the C++
`put-get-remove` example.
-
-Instantiate a `CacheFactory` and set its characteristics:
+Create a cache and use it to instantiate a `CacheFactory` and set its
characteristics:
``` cpp
- auto cacheFactory = CacheFactory(); // instantiate cache factory
- cacheFactory.set("log-level", "none"); // set cache log-level
characteristics
+auto cache = CacheFactory()
+.set("log-level", "debug")
+.set("ssl-enabled", "true")
+.set("ssl-truststore", clientTruststore.string())
+.create();
```
-Create a cache and use it to instantiate a `PoolFactory`:
+Create a pool of network connections, and instantiate a region of the desired
type:
Review comment:
This should probably just read "Create a pool of network connections".
The next block is the one that instantiates the region.
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
> Update native client examples to use Builder pattern
>
>
> Key: GEODE-8593
> URL: https://issues.apache.org/jira/browse/GEODE-8593
> Project: Geode
> Issue Type: Improvement
> Components: docs, native client
>Affects Versions: 1.13.0
>Reporter: Dave Barnes
>Priority: Major
> Labels: pull-request-available
>
> For both C++ and .NET examples, the section of code that creates the
> connection pool should be improved to better illustrate the Builder pattern.
> For example, in the C++ examples, current code is:
> ```
> auto cacheFactory = CacheFactory();
> cacheFactory.set("log-level", "none");
> auto cache = cacheFactory.create();
> auto poolFactory = cache.getPoolManager().createFactory();
>
> poolFactory.addLocator("localhost", 10334);
> auto pool = poolFactory.create("pool");
> ```
> The improved version would be:
> ```
> auto cache = CacheFactory()
>.set("log-level", "debug")
>.set("ssl-enabled", "true")
>.set("ssl-truststore", clientTruststore.string())
>.create();
> cache.getPoolManager()
> .createFactory()
> .addLocator("localhost", 10334)
> .create("pool");
> ```
> Similarly for .NET examples.
> These doc snippets also appear in the user guides, so they'll need updating
> in the docs, as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8622) Redis INCRBYFLOAT should return an error message consistent with native Redis
[
https://issues.apache.org/jira/browse/GEODE-8622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215635#comment-17215635
]
ASF GitHub Bot commented on GEODE-8622:
---
sabbey37 commented on a change in pull request #5636:
URL: https://github.com/apache/geode/pull/5636#discussion_r506675816
##
File path:
geode-redis/src/integrationTest/java/org/apache/geode/redis/internal/executor/string/AbstractIncrByFloatIntegrationTest.java
##
@@ -15,24 +15,25 @@
package org.apache.geode.redis.internal.executor.string;
import static org.assertj.core.api.Assertions.assertThat;
+import static org.assertj.core.api.Assertions.assertThatThrownBy;
-import java.util.Random;
+import java.math.BigDecimal;
import org.junit.After;
import org.junit.Before;
+import org.junit.Ignore;
import org.junit.Test;
import redis.clients.jedis.Jedis;
+import redis.clients.jedis.Protocol;
import org.apache.geode.test.dunit.rules.RedisPortSupplier;
public abstract class AbstractIncrByFloatIntegrationTest implements
RedisPortSupplier {
private Jedis jedis;
- private Random rand;
@Before
public void setUp() {
-rand = new Random();
jedis = new Jedis("localhost", getPort(), 1000);
Review comment:
It would be good to make this timeout the same as the one from
awaitility:
`Math.toIntExact(GeodeAwaitility.getTimeout().toMillis());`
##
File path:
geode-redis/src/main/java/org/apache/geode/redis/internal/executor/string/IncrByFloatExecutor.java
##
@@ -46,15 +44,14 @@ public RedisResponse executeCommand(Command command,
byte[] incrArray = commandElems.get(INCREMENT_INDEX);
String doub = Coder.bytesToString(incrArray).toLowerCase();
if (doub.contains("inf") || doub.contains("nan")) {
Review comment:
Redis uses the methods `isnan`
(https://en.cppreference.com/w/c/numeric/math/isnan) and `isinf`
(https://en.cppreference.com/w/c/numeric/math/isinf) from the math library,
which seem to check more than the string literals. Also, not all strings that
contain `inf` or `nan` would produce NaN or Infinity. Some are just invalid
floats.
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
> Redis INCRBYFLOAT should return an error message consistent with native Redis
> -
>
> Key: GEODE-8622
> URL: https://issues.apache.org/jira/browse/GEODE-8622
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> Geode Redis:
> {noformat}
> 127.0.0.1:6379> set anshin-1 weeble
> OK
> 127.0.0.1:6379> incrbyfloat anshin-1 2.0e2f
> (error) ERR Value at this key cannot be incremented numerically
> {noformat}
> Native Redis:
> {noformat}
> ERR value is not a valid float
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8622) Redis INCRBYFLOAT should return an error message consistent with native Redis
[
https://issues.apache.org/jira/browse/GEODE-8622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215636#comment-17215636
]
ASF GitHub Bot commented on GEODE-8622:
---
sabbey37 commented on a change in pull request #5636:
URL: https://github.com/apache/geode/pull/5636#discussion_r506701058
##
File path:
geode-redis/src/integrationTest/java/org/apache/geode/redis/internal/executor/string/AbstractIncrByFloatIntegrationTest.java
##
@@ -15,24 +15,25 @@
package org.apache.geode.redis.internal.executor.string;
import static org.assertj.core.api.Assertions.assertThat;
+import static org.assertj.core.api.Assertions.assertThatThrownBy;
-import java.util.Random;
+import java.math.BigDecimal;
import org.junit.After;
import org.junit.Before;
+import org.junit.Ignore;
import org.junit.Test;
import redis.clients.jedis.Jedis;
+import redis.clients.jedis.Protocol;
import org.apache.geode.test.dunit.rules.RedisPortSupplier;
public abstract class AbstractIncrByFloatIntegrationTest implements
RedisPortSupplier {
Review comment:
It would be nice to add a test making sure the correct error is returned
when we try to do incrby on a key whose value is not a string.
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
> Redis INCRBYFLOAT should return an error message consistent with native Redis
> -
>
> Key: GEODE-8622
> URL: https://issues.apache.org/jira/browse/GEODE-8622
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> Geode Redis:
> {noformat}
> 127.0.0.1:6379> set anshin-1 weeble
> OK
> 127.0.0.1:6379> incrbyfloat anshin-1 2.0e2f
> (error) ERR Value at this key cannot be incremented numerically
> {noformat}
> Native Redis:
> {noformat}
> ERR value is not a valid float
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8622) Redis INCRBYFLOAT should return an error message consistent with native Redis
[
https://issues.apache.org/jira/browse/GEODE-8622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215637#comment-17215637
]
ASF GitHub Bot commented on GEODE-8622:
---
sabbey37 commented on a change in pull request #5636:
URL: https://github.com/apache/geode/pull/5636#discussion_r506701058
##
File path:
geode-redis/src/integrationTest/java/org/apache/geode/redis/internal/executor/string/AbstractIncrByFloatIntegrationTest.java
##
@@ -15,24 +15,25 @@
package org.apache.geode.redis.internal.executor.string;
import static org.assertj.core.api.Assertions.assertThat;
+import static org.assertj.core.api.Assertions.assertThatThrownBy;
-import java.util.Random;
+import java.math.BigDecimal;
import org.junit.After;
import org.junit.Before;
+import org.junit.Ignore;
import org.junit.Test;
import redis.clients.jedis.Jedis;
+import redis.clients.jedis.Protocol;
import org.apache.geode.test.dunit.rules.RedisPortSupplier;
public abstract class AbstractIncrByFloatIntegrationTest implements
RedisPortSupplier {
Review comment:
It would be nice to add a test making sure the correct error is returned
when we try to do `INCRBYFLOAT` on a key whose value is not a string.
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
> Redis INCRBYFLOAT should return an error message consistent with native Redis
> -
>
> Key: GEODE-8622
> URL: https://issues.apache.org/jira/browse/GEODE-8622
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> Geode Redis:
> {noformat}
> 127.0.0.1:6379> set anshin-1 weeble
> OK
> 127.0.0.1:6379> incrbyfloat anshin-1 2.0e2f
> (error) ERR Value at this key cannot be incremented numerically
> {noformat}
> Native Redis:
> {noformat}
> ERR value is not a valid float
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8593) Update native client examples to use Builder pattern
[
https://issues.apache.org/jira/browse/GEODE-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215641#comment-17215641
]
ASF GitHub Bot commented on GEODE-8593:
---
davebarnes97 commented on a change in pull request #675:
URL: https://github.com/apache/geode-native/pull/675#discussion_r506703285
##
File path:
docs/geode-native-docs-cpp/getting-started/getting-started-nc-client.html.md.erb
##
@@ -37,36 +37,37 @@ To connect to a server, your application must follow these
steps:
1. Instantiate a `CacheFactory`, setting characteristics of interest (for
example, `log-level`).
1. Create a cache and use it to instantiate a `PoolFactory`, specifying the
hostname and port for the server locator.
1. Create a named pool of network connections.
-1. Instantiate a region of the desired type (usually CACHING_PROXY or PROXY)
and connect it by name to its counterpart on the server.
+1. Instantiate a region of the desired type (usually PROXY, sometimes
CACHING_PROXY) and connect it by name to its counterpart on the server.
Once the connection pool and the shared region are in place, your client
application is ready to share data with the server.
**Server Connection: C++ Example**
-This example of connecting to the server is taken from the C++
`put-get-remove` example.
-
-Instantiate a `CacheFactory` and set its characteristics:
+Create a cache and use it to instantiate a `CacheFactory` and set its
characteristics:
``` cpp
- auto cacheFactory = CacheFactory(); // instantiate cache factory
- cacheFactory.set("log-level", "none"); // set cache log-level
characteristics
+auto cache = CacheFactory()
+.set("log-level", "debug")
+.set("ssl-enabled", "true")
+.set("ssl-truststore", clientTruststore.string())
+.create();
```
-Create a cache and use it to instantiate a `PoolFactory`:
+Create a pool of network connections, and instantiate a region of the desired
type:
Review comment:
Good catch - 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
> Update native client examples to use Builder pattern
>
>
> Key: GEODE-8593
> URL: https://issues.apache.org/jira/browse/GEODE-8593
> Project: Geode
> Issue Type: Improvement
> Components: docs, native client
>Affects Versions: 1.13.0
>Reporter: Dave Barnes
>Priority: Major
> Labels: pull-request-available
>
> For both C++ and .NET examples, the section of code that creates the
> connection pool should be improved to better illustrate the Builder pattern.
> For example, in the C++ examples, current code is:
> ```
> auto cacheFactory = CacheFactory();
> cacheFactory.set("log-level", "none");
> auto cache = cacheFactory.create();
> auto poolFactory = cache.getPoolManager().createFactory();
>
> poolFactory.addLocator("localhost", 10334);
> auto pool = poolFactory.create("pool");
> ```
> The improved version would be:
> ```
> auto cache = CacheFactory()
>.set("log-level", "debug")
>.set("ssl-enabled", "true")
>.set("ssl-truststore", clientTruststore.string())
>.create();
> cache.getPoolManager()
> .createFactory()
> .addLocator("localhost", 10334)
> .create("pool");
> ```
> Similarly for .NET examples.
> These doc snippets also appear in the user guides, so they'll need updating
> in the docs, as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8324) Events are not being replicated from one WAN site to another when there are multiple paths between the sites and the direct one is stopped
[
https://issues.apache.org/jira/browse/GEODE-8324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215640#comment-17215640
]
ASF subversion and git services commented on GEODE-8324:
Commit 23cfacff6cc875830416c11c0ccaaaebf15d36d2 in geode's branch
refs/heads/feature/GEODE-8324 from Barry Oglesby
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=23cfacf ]
GEODE-8324: Updated dunit test
> Events are not being replicated from one WAN site to another when there are
> multiple paths between the sites and the direct one is stopped
> --
>
> Key: GEODE-8324
> URL: https://issues.apache.org/jira/browse/GEODE-8324
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: caching-applications, pull-request-available
>
> Scenario
>
> The configuration is a normal star/mesh pattern where each site is connected
> to each other site.
> So, there are 2 paths from site-A to site-B:
> - the direct (site-A -> site-B)
> - the indirect path (site-A -> site-C -> site-B)
> If the direct path (meaning the sender in site-A to site-B) is stopped and a
> put is done in site-A, site-B doesn't receive the event even though the
> indirect path is not stopped.
> Here is the behavior:
> Site-A - dsid=1
> Site-B - dsid=2
> Site-C - dsid=3
> Site-A
> --
> Since site-A is configured with site-B and site-C, its events will contain
> recipient dsids for those sites (2 and 3 below).
> The event sent to site-C will look like:
> {noformat}
> AbstractGatewaySender.distribute sender=site-C processing local event
> newCallbackArg=GatewaySenderEventCallbackArgument
> [originatingSenderId=1;recipientGatewayReceivers={3, 2}]; region=/data; key=0
> {noformat}
> Site-C
> --
> Site-C receives the event:
> {noformat}
> GatewayReceiverCommand.cmdExecute processing create region=/data; key=0
> {noformat}
> The sender to site-B drops the event since it thinks it is already a
> recipient:
> {noformat}
> AbstractGatewaySender.distribute sender=site-B received event from remote
> site receivedCallbackArg=GatewaySenderEventCallbackArgument
> [originatingSenderId=1;recipientGatewayReceivers={3, 2}]; region=/data;
> key=0; eventId=EventID[id=25
> bytes;threadID=0x10030|1;sequenceID=0;bucketId=48]
> AbstractGatewaySender.distribute sender=site-B dropping event since it is
> already a recipient
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8593) Update native client examples to use Builder pattern
[
https://issues.apache.org/jira/browse/GEODE-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215644#comment-17215644
]
ASF subversion and git services commented on GEODE-8593:
Commit 2918ff44b0d3ee6d914f6b31a9fac4465e7f203a in geode-native's branch
refs/heads/develop from Dave Barnes
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=2918ff4 ]
GEODE-8593: Update geode-native examples to use builder pattern: C++ (#675)
* GEODE-8593: Update geode-native examples to use builder pattern: C++ examples
and docs
> Update native client examples to use Builder pattern
>
>
> Key: GEODE-8593
> URL: https://issues.apache.org/jira/browse/GEODE-8593
> Project: Geode
> Issue Type: Improvement
> Components: docs, native client
>Affects Versions: 1.13.0
>Reporter: Dave Barnes
>Priority: Major
> Labels: pull-request-available
>
> For both C++ and .NET examples, the section of code that creates the
> connection pool should be improved to better illustrate the Builder pattern.
> For example, in the C++ examples, current code is:
> ```
> auto cacheFactory = CacheFactory();
> cacheFactory.set("log-level", "none");
> auto cache = cacheFactory.create();
> auto poolFactory = cache.getPoolManager().createFactory();
>
> poolFactory.addLocator("localhost", 10334);
> auto pool = poolFactory.create("pool");
> ```
> The improved version would be:
> ```
> auto cache = CacheFactory()
>.set("log-level", "debug")
>.set("ssl-enabled", "true")
>.set("ssl-truststore", clientTruststore.string())
>.create();
> cache.getPoolManager()
> .createFactory()
> .addLocator("localhost", 10334)
> .create("pool");
> ```
> Similarly for .NET examples.
> These doc snippets also appear in the user guides, so they'll need updating
> in the docs, as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8593) Update native client examples to use Builder pattern
[
https://issues.apache.org/jira/browse/GEODE-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215642#comment-17215642
]
ASF subversion and git services commented on GEODE-8593:
Commit 2918ff44b0d3ee6d914f6b31a9fac4465e7f203a in geode-native's branch
refs/heads/develop from Dave Barnes
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=2918ff4 ]
GEODE-8593: Update geode-native examples to use builder pattern: C++ (#675)
* GEODE-8593: Update geode-native examples to use builder pattern: C++ examples
and docs
> Update native client examples to use Builder pattern
>
>
> Key: GEODE-8593
> URL: https://issues.apache.org/jira/browse/GEODE-8593
> Project: Geode
> Issue Type: Improvement
> Components: docs, native client
>Affects Versions: 1.13.0
>Reporter: Dave Barnes
>Priority: Major
> Labels: pull-request-available
>
> For both C++ and .NET examples, the section of code that creates the
> connection pool should be improved to better illustrate the Builder pattern.
> For example, in the C++ examples, current code is:
> ```
> auto cacheFactory = CacheFactory();
> cacheFactory.set("log-level", "none");
> auto cache = cacheFactory.create();
> auto poolFactory = cache.getPoolManager().createFactory();
>
> poolFactory.addLocator("localhost", 10334);
> auto pool = poolFactory.create("pool");
> ```
> The improved version would be:
> ```
> auto cache = CacheFactory()
>.set("log-level", "debug")
>.set("ssl-enabled", "true")
>.set("ssl-truststore", clientTruststore.string())
>.create();
> cache.getPoolManager()
> .createFactory()
> .addLocator("localhost", 10334)
> .create("pool");
> ```
> Similarly for .NET examples.
> These doc snippets also appear in the user guides, so they'll need updating
> in the docs, as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8593) Update native client examples to use Builder pattern
[
https://issues.apache.org/jira/browse/GEODE-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215643#comment-17215643
]
ASF GitHub Bot commented on GEODE-8593:
---
davebarnes97 merged pull request #675:
URL: https://github.com/apache/geode-native/pull/675
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
> Update native client examples to use Builder pattern
>
>
> Key: GEODE-8593
> URL: https://issues.apache.org/jira/browse/GEODE-8593
> Project: Geode
> Issue Type: Improvement
> Components: docs, native client
>Affects Versions: 1.13.0
>Reporter: Dave Barnes
>Priority: Major
> Labels: pull-request-available
>
> For both C++ and .NET examples, the section of code that creates the
> connection pool should be improved to better illustrate the Builder pattern.
> For example, in the C++ examples, current code is:
> ```
> auto cacheFactory = CacheFactory();
> cacheFactory.set("log-level", "none");
> auto cache = cacheFactory.create();
> auto poolFactory = cache.getPoolManager().createFactory();
>
> poolFactory.addLocator("localhost", 10334);
> auto pool = poolFactory.create("pool");
> ```
> The improved version would be:
> ```
> auto cache = CacheFactory()
>.set("log-level", "debug")
>.set("ssl-enabled", "true")
>.set("ssl-truststore", clientTruststore.string())
>.create();
> cache.getPoolManager()
> .createFactory()
> .addLocator("localhost", 10334)
> .create("pool");
> ```
> Similarly for .NET examples.
> These doc snippets also appear in the user guides, so they'll need updating
> in the docs, as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8615) Update gitignore with tools/gnmsg entries
[ https://issues.apache.org/jira/browse/GEODE-8615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Bustamante Reyes resolved GEODE-8615. - Fix Version/s: 1.14.0 Resolution: Fixed > Update gitignore with tools/gnmsg entries > - > > Key: GEODE-8615 > URL: https://issues.apache.org/jira/browse/GEODE-8615 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > Following entries should be added to gitignore: > * /tools/gnmsg/.idea/ > * /tools/gnmsg/__pycache__/ -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8625) If the GatewaySenderEventImpl is retrieved from disk while marking events as possible duplicate, then the possibleDuplicate setting isn't retained
Barrett Oglesby created GEODE-8625:
--
Summary: If the GatewaySenderEventImpl is retrieved from disk
while marking events as possible duplicate, then the possibleDuplicate setting
isn't retained
Key: GEODE-8625
URL: https://issues.apache.org/jira/browse/GEODE-8625
Project: Geode
Issue Type: Bug
Components: wan
Reporter: Barrett Oglesby
By default, when starting a member with a persisted region, the values are not
read from disk. This includes WAN queues. One of the things that occurs after
the primary lock is acquired for a bucket is to mark all events in the queue as
possible duplicates. The markEventsAsDuplicate method uses LocalRegion.getNoLRU
to retrieve the GatewaySenderEventImpl. This method doesn't retain the value in
the region, so setting possibleDuplicate to true is lost.
Here is a stack dump of the call:
{noformat}
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1333)
at
org.apache.geode.internal.cache.LocalRegion.getNoLRU(LocalRegion.java:3558)
at
org.apache.geode.internal.cache.AbstractBucketRegionQueue.markEventsAsDuplicate(AbstractBucketRegionQueue.java:277)
at
org.apache.geode.internal.cache.BucketRegionQueue.beforeAcquiringPrimaryState(BucketRegionQueue.java:206)
at
org.apache.geode.internal.cache.BucketAdvisor.acquiredPrimaryLock(BucketAdvisor.java:1165)
at
org.apache.geode.internal.cache.BucketAdvisor.acquirePrimaryRecursivelyForColocated(BucketAdvisor.java:1305)
at
org.apache.geode.internal.cache.BucketAdvisor.access$700(BucketAdvisor.java:84)
at
org.apache.geode.internal.cache.BucketAdvisor$VolunteeringDelegate.doVolunteerForPrimary(BucketAdvisor.java:2530)
at
org.apache.geode.internal.cache.BucketAdvisor$VolunteeringDelegate.lambda$consumeQueue$0(BucketAdvisor.java:2728)
{noformat}
Here is an example for event at shadowKey=1857.
After the above call that event shows possibleDuplicate=true:
{noformat}
GatewaySenderEventImpl[region=/data;key=1537;value=Trade[id=1537; cusip=VMW;
shares=54; price=993];possibleDuplicate=true;shadowKey=1857;...]
{noformat}
Dumping the events in the queue after recovery has completed (after the above
call) shows the value as NOT_AVAILABLE:
{noformat}
RegionEntry (a VMThinDiskLRURegionEntryHeapLongKey) contains: [key
class=java.lang.Long; value=1857]; [value
class=org.apache.geode.internal.cache.Token$NotAvailable; value=NOT_AVAILABLE]
{noformat}
And when a member in the remote site is started, the batch containing that
event shows possibleDuplicate=false:
{noformat}
GatewaySenderEventImpl[region=/data;key=1537;value=Trade[id=1537; cusip=VMW;
shares=54; price=993];possibleDuplicate=false;shadowKey=1857;...]
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8610) Add parameter checking to unsupported Redis commands
[ https://issues.apache.org/jira/browse/GEODE-8610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215662#comment-17215662 ] ASF GitHub Bot commented on GEODE-8610: --- sabbey37 merged pull request #5635: URL: https://github.com/apache/geode/pull/5635 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 parameter checking to unsupported Redis commands > > > Key: GEODE-8610 > URL: https://issues.apache.org/jira/browse/GEODE-8610 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Sarah Abbey >Assignee: Sarah Abbey >Priority: Minor > Labels: pull-request-available > > Create tests/add parameter check -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8610) Add parameter checking to unsupported Redis commands
[ https://issues.apache.org/jira/browse/GEODE-8610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215663#comment-17215663 ] ASF subversion and git services commented on GEODE-8610: Commit f46d7ae956d98ac0df27cf093bb4d4a3dee33745 in geode's branch refs/heads/develop from Sarah [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f46d7ae ] GEODE-8610: Add parameter checking to unsupported Redis commands (#5635) > Add parameter checking to unsupported Redis commands > > > Key: GEODE-8610 > URL: https://issues.apache.org/jira/browse/GEODE-8610 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Sarah Abbey >Assignee: Sarah Abbey >Priority: Minor > Labels: pull-request-available > Fix For: 1.14.0 > > > Create tests/add parameter check -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8610) Add parameter checking to unsupported Redis commands
[ https://issues.apache.org/jira/browse/GEODE-8610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sarah Abbey resolved GEODE-8610. Fix Version/s: 1.14.0 Resolution: Fixed > Add parameter checking to unsupported Redis commands > > > Key: GEODE-8610 > URL: https://issues.apache.org/jira/browse/GEODE-8610 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Sarah Abbey >Assignee: Sarah Abbey >Priority: Minor > Labels: pull-request-available > Fix For: 1.14.0 > > > Create tests/add parameter check -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8593) Update native client examples to use Builder pattern
[
https://issues.apache.org/jira/browse/GEODE-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215677#comment-17215677
]
ASF subversion and git services commented on GEODE-8593:
Commit 03f16b7e17426dc940139e97c466041d4e8960c2 in geode-native's branch
refs/heads/support/1.13 from Dave Barnes
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=03f16b7 ]
GEODE-8593: Update geode-native examples to use builder pattern: C++
> Update native client examples to use Builder pattern
>
>
> Key: GEODE-8593
> URL: https://issues.apache.org/jira/browse/GEODE-8593
> Project: Geode
> Issue Type: Improvement
> Components: docs, native client
>Affects Versions: 1.13.0
>Reporter: Dave Barnes
>Priority: Major
> Labels: pull-request-available
>
> For both C++ and .NET examples, the section of code that creates the
> connection pool should be improved to better illustrate the Builder pattern.
> For example, in the C++ examples, current code is:
> ```
> auto cacheFactory = CacheFactory();
> cacheFactory.set("log-level", "none");
> auto cache = cacheFactory.create();
> auto poolFactory = cache.getPoolManager().createFactory();
>
> poolFactory.addLocator("localhost", 10334);
> auto pool = poolFactory.create("pool");
> ```
> The improved version would be:
> ```
> auto cache = CacheFactory()
>.set("log-level", "debug")
>.set("ssl-enabled", "true")
>.set("ssl-truststore", clientTruststore.string())
>.create();
> cache.getPoolManager()
> .createFactory()
> .addLocator("localhost", 10334)
> .create("pool");
> ```
> Similarly for .NET examples.
> These doc snippets also appear in the user guides, so they'll need updating
> in the docs, as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8593) Update native client examples to use Builder pattern
[
https://issues.apache.org/jira/browse/GEODE-8593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17215678#comment-17215678
]
ASF subversion and git services commented on GEODE-8593:
Commit 03f16b7e17426dc940139e97c466041d4e8960c2 in geode-native's branch
refs/heads/support/1.13 from Dave Barnes
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=03f16b7 ]
GEODE-8593: Update geode-native examples to use builder pattern: C++
> Update native client examples to use Builder pattern
>
>
> Key: GEODE-8593
> URL: https://issues.apache.org/jira/browse/GEODE-8593
> Project: Geode
> Issue Type: Improvement
> Components: docs, native client
>Affects Versions: 1.13.0
>Reporter: Dave Barnes
>Priority: Major
> Labels: pull-request-available
>
> For both C++ and .NET examples, the section of code that creates the
> connection pool should be improved to better illustrate the Builder pattern.
> For example, in the C++ examples, current code is:
> ```
> auto cacheFactory = CacheFactory();
> cacheFactory.set("log-level", "none");
> auto cache = cacheFactory.create();
> auto poolFactory = cache.getPoolManager().createFactory();
>
> poolFactory.addLocator("localhost", 10334);
> auto pool = poolFactory.create("pool");
> ```
> The improved version would be:
> ```
> auto cache = CacheFactory()
>.set("log-level", "debug")
>.set("ssl-enabled", "true")
>.set("ssl-truststore", clientTruststore.string())
>.create();
> cache.getPoolManager()
> .createFactory()
> .addLocator("localhost", 10334)
> .create("pool");
> ```
> Similarly for .NET examples.
> These doc snippets also appear in the user guides, so they'll need updating
> in the docs, as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8536) StackOverflow can occur when Lucene IndexWriter is unable to be created
[
https://issues.apache.org/jira/browse/GEODE-8536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans resolved GEODE-8536.
Fix Version/s: 1.14.0
Resolution: Fixed
> StackOverflow can occur when Lucene IndexWriter is unable to be created
> ---
>
> Key: GEODE-8536
> URL: https://issues.apache.org/jira/browse/GEODE-8536
> Project: Geode
> Issue Type: Bug
> Components: functions, lucene
>Affects Versions: 1.12.0, 1.13.0, 1.14.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> If, during a call to IndexRepositoryFactory.computeIndexRepository(), an
> IOException is encountered when attempting to construct an IndexWriter, the
> function retry logic will reattempt the execution. This allows transient
> exceptions caused by concurrent modification of the fileAndChunk region to be
> ignored and subsequent executions to succeed (see GEODE-7703). However, if
> the IOException is consistently thrown, the infinitely retrying function can
> cause a StackOverflow:
> {noformat}
> java.lang.StackOverflowError
> at
> org.apache.geode.SystemFailure.startWatchDog(SystemFailure.java:320)
> at
> org.apache.geode.SystemFailure.notifyWatchDog(SystemFailure.java:758)
> at org.apache.geode.SystemFailure.setFailure(SystemFailure.java:813)
> at
> org.apache.geode.SystemFailure.initiateFailure(SystemFailure.java:790)
> at
> org.apache.geode.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2251)
> at
> org.apache.geode.internal.InternalDataSerializer.basicWriteObject(InternalDataSerializer.java:2031)
> at
> org.apache.geode.DataSerializer.writeObject(DataSerializer.java:2839)
> at
> org.apache.geode.internal.cache.partitioned.PartitionedRegionFunctionStreamingMessage.toData(PartitionedRegionFunctionStreamingMessage.java:192)
> at
> org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.invokeToData(DSFIDSerializerImpl.java:213)
> at
> org.apache.geode.internal.serialization.internal.DSFIDSerializerImpl.write(DSFIDSerializerImpl.java:137)
> at
> org.apache.geode.internal.InternalDataSerializer.writeDSFID(InternalDataSerializer.java:1484)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:247)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:306)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:511)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2058)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1986)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2023)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
> at
> org.apache.geode.internal.cache.execute.PartitionedRegionFunctionResultWaiter.getPartitionedDataFrom(PartitionedRegionFunctionResultWaiter.java:89)
> at
> org.apache.geode.internal.cache.PartitionedRegion.executeOnAllBuckets(PartitionedRegion.java:4079)
> at
> org.apache.geode.internal.cache.PartitionedRegion.executeFunction(PartitionedRegion.java:3583)
> at
> org.apache.geode.internal.cache.execute.PartitionedRegionFunctionExecutor.executeFunction(PartitionedRegionFunctionExecutor.java:220)
> at
> org.apache.geode.internal.cache.execute.AbstractExecution.execute(AbstractExecution.java:376)
> at
> org.apache.geode.internal.cache.execute.AbstractExecution.execute(AbstractExecution.java:359)
> at
> org.apache.geode.internal.cache.execute.LocalResultCollectorImpl.getResultInternal(LocalResultCollectorImpl.java:139)
> at
> org.apache.geode.internal.cache.execute.ResultCollectorHolder.getResult(ResultCollectorHolder.java:53)
> at
> org.apache.geode.internal.cache.execute.LocalResultCollectorImpl.getResult(LocalResultCollectorImpl.java:112)
> at
> org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResultInternal(PRFunctionStreamingResultCollector.java
