[jira] [Commented] (GEODE-8149) Introduce new parameter to control the feature
[ https://issues.apache.org/jira/browse/GEODE-8149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17113814#comment-17113814 ] ASF GitHub Bot commented on GEODE-8149: --- jvarenina commented on a change in pull request #5139: URL: https://github.com/apache/geode/pull/5139#discussion_r429084330 ## File path: geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java ## @@ -2032,6 +2032,23 @@ * Default: empty. All security components use basic (username/password) authentication */ String SECURITY_AUTH_TOKEN_ENABLED_COMPONENTS = SECURITY_PREFIX + "auth-token-enabled-components"; + + /** + * The static String definition of the "security-cn-auth-enabled" property + * + * + * Description This parameter only works if SSL with two-way handshake is enabled on + * all components and security manager is enabled. This property will determine if common name + * from client certificate will be used for authentication and authorization. Review comment: Thanks for the comments. I will rephrase it as you suggested. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Introduce new parameter to control the feature > -- > > Key: GEODE-8149 > URL: https://issues.apache.org/jira/browse/GEODE-8149 > Project: Geode > Issue Type: Sub-task >Reporter: Jakov Varenina >Assignee: Jakov Varenina >Priority: Major > > * New parameter _security-cn-auth-enabled_ (default value "false") parameter > should be introduced to control this new feature. It should be allowed to set > only if mutual SSL is enabled on all components: _ssl- > ssl-require-authentication == true && ssl-web-require-authentication == true > && ssl-enabled-components==(ALL or all components listed) && > security-manager.isSet == true_ > * New property _security-common-name_ for _security-manager.authentication_ > method should be introduced > * New integration and unit tests -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8149) Introduce new parameter to control the feature
[ https://issues.apache.org/jira/browse/GEODE-8149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17113819#comment-17113819 ] ASF GitHub Bot commented on GEODE-8149: --- jvarenina commented on pull request #5139: URL: https://github.com/apache/geode/pull/5139#issuecomment-632540478 > This PR provides documentation at the Javadoc level. > Consider where in the User Guide this should be mentioned, then > > * add a User Guide explanation as part of this PR/JIRA combination, or > > * add a subticket to GEODE-8118, the parent ticket of this one (GEODE-8149) to handle the User Guide docs. > Either of the above will satisfy my concern. Thanks. OK, I will create sub-ticket to handle User Guide docs. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Introduce new parameter to control the feature > -- > > Key: GEODE-8149 > URL: https://issues.apache.org/jira/browse/GEODE-8149 > Project: Geode > Issue Type: Sub-task >Reporter: Jakov Varenina >Assignee: Jakov Varenina >Priority: Major > > * New parameter _security-cn-auth-enabled_ (default value "false") parameter > should be introduced to control this new feature. It should be allowed to set > only if mutual SSL is enabled on all components: _ssl- > ssl-require-authentication == true && ssl-web-require-authentication == true > && ssl-enabled-components==(ALL or all components listed) && > security-manager.isSet == true_ > * New property _security-common-name_ for _security-manager.authentication_ > method should be introduced > * New integration and unit tests -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7971) Gateway sender to deliver transaction events atomically to gateway receivers
[ https://issues.apache.org/jira/browse/GEODE-7971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17113863#comment-17113863 ] ASF GitHub Bot commented on GEODE-7971: --- albertogpz commented on pull request #4928: URL: https://github.com/apache/geode/pull/4928#issuecomment-632576516 > > > The problem with the doc comments was not that they were extensive, but that they got modified when you pasted the diff here and the resulting test was not a valid diff I could apply. > > > > > > I lack permissions to push my commit to your fork. It consists of four edited files. What would you suggest? > > You can send me the diff file attached to my e-mail address. I will apply the diff and then give comments if any here. I just pushed a couple of commits. - One with your comments about the documentation: I accepted all of them, thanks a lot for them. - The second one merging the latest of development. 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 > Gateway sender to deliver transaction events atomically to gateway receivers > > > Key: GEODE-7971 > URL: https://issues.apache.org/jira/browse/GEODE-7971 > Project: Geode > Issue Type: Improvement > Components: wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > The goal of this ticket is to implement the necessary changes in the gateway > sender to prevent that events belonging to the same transaction are spread > across different batches. In other words, to ensure that events from the same > transaction are sent inside the same batch. > This will be an optional feature on gateway senders to be enabled via a new > parameter (--group-transaction-events) and will be restricted to serial > gateway senders with just one dispatcher thread or to parallel gateway > senders. > Apart from the above restriction, grouping of events for a transaction inside > the same batch may only be attained if the regions to which the events belong > are replicated by the same set of gateway senders with the > --group-transaction-events flag enabled. If this condition is not met, the > events will be correctly delivered by the gateway senders but it will not be > guaranteed that all events will always be sent inside the same batch. > For more details see: > [https://cwiki.apache.org/confluence/display/GEODE/Gw+sender+to+deliver+transaction+events+atomically+to+receivers] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8172) CI failure: ParallelWANPersistenceEnabledGatewaySenderOffHeapDUnitTest.testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
[
https://issues.apache.org/jira/browse/GEODE-8172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17113868#comment-17113868
]
ASF GitHub Bot commented on GEODE-8172:
---
mivanac opened a new pull request #5148:
URL: https://github.com/apache/geode/pull/5148
WIP
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
> CI failure:
> ParallelWANPersistenceEnabledGatewaySenderOffHeapDUnitTest.testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
> ---
>
> Key: GEODE-8172
> URL: https://issues.apache.org/jira/browse/GEODE-8172
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Bruce J Schuchardt
>Assignee: Mario Ivanac
>Priority: Major
>
> Failed in a CI run
> (https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/191#A).
> No previous failures for this issue are found in JIRA and no recent WAN
> changes could be detected. Flaky?
> {noformat}
> > Task :geode-wan:distributedTest
> org.apache.geode.internal.cache.wan.offheap.ParallelWANPersistenceEnabledGatewaySenderOffHeapDUnitTest
> >
> testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
> FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.parallel.ParallelWANPersistenceEnabledGatewaySenderDUnitTest$$Lambda$487/908301056.run
> in VM 2 running on Host 8e35f765a792 with 8 VMs
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.wan.WANTestBase that uses int,
> intorg.apache.geode.cache.Region Expected region entries: 0 but actual
> entries: 20 present region keyset [3, 5, 8, 13, 16, 21, 27, 30, 35, 38, 43,
> 45, 50, 54, 58, 62, 65, 68, 73, 78] expected:<0> but was:<20> within 5
> minutes.
> Caused by:
> java.lang.AssertionError: Expected region entries: 0 but actual
> entries: 20 present region keyset [3, 5, 8, 13, 16, 21, 27, 30, 35, 38, 43,
> 45, 50, 54, 58, 62, 65, 68, 73, 78] expected:<0> but was:<20>
> 824 tests completed, 1 failed, 59 skipped
> > Task :geode-wan:distributedTest FAILED
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8138) Improve semantics of the redis-port option
[
https://issues.apache.org/jira/browse/GEODE-8138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114051#comment-17114051
]
ASF GitHub Bot commented on GEODE-8138:
---
sabbeyPivotal commented on a change in pull request #5142:
URL: https://github.com/apache/geode/pull/5142#discussion_r429255221
##
File path:
geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java
##
@@ -1943,6 +1931,36 @@
* Default: ""
*/
String REDIS_PASSWORD = "redis-password";
+ /**
+ * The static String definition of the "redis-port" property
+ *
+ * Description: Specifies the port used by Redis API for Geode which
enables Redis
+ * clients to connect and store data in GemFire distributed system. A value
of 0 will select a
+ * random port.
+ *
+ * Default: "6379"
+ *
+ * Allowed values: 0..65535
+ */
+ String REDIS_PORT = "redis-port";
+ /**
+ * The static String definition of the "redis-service-enabled"
property
+ *
+ * Description: When the default value of false, the Redis API for
Geode is not available.
+ * Set to true to enable the Redis API for Geode.
+ *
+ * Default: false
+ * redis-service-enabled
+ * When the default value of false, the Redis API for
<%=vars.product_name%> is not available.
+ * Set
+ * to true to enable the Redis API for <%=vars.product_name%>.
+ * S
+ * false
+ *
+ *
+ */
+ String REDIS_SERVICE_ENABLED = "redis-service-enabled";
Review comment:
Yeah, we can make it `redis-enabled`
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
> Improve semantics of the redis-port option
> --
>
> Key: GEODE-8138
> URL: https://issues.apache.org/jira/browse/GEODE-8138
> Project: Geode
> Issue Type: New Feature
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
>
> Currently when {{redis-port=0}} the Redis service is not enabled. Recently we
> added the ability to pick an ephemeral port by setting {{redis-port=-1}}.
> However the typical norm is that a port of {{0}} should indicate the use of
> an ephemeral port.
> If we allow this then we need a different way of enabling/disabling the
> service.
> One possibility is that the service is disabled when {{redis-port=-1}}. (or <
> 0). However anyone already setting the property to {{0}} would then suddenly
> activate the service.
> Another possibility is to add a new Geode property to explicitly
> enable/disable the service. (Off by default). That way users, switching to
> this version, would still experience the same behavior regardless of their
> {{redis-port}} setting.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8151) Convert all redis commands to return RedisResponse
[
https://issues.apache.org/jira/browse/GEODE-8151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114065#comment-17114065
]
ASF GitHub Bot commented on GEODE-8151:
---
jdeppe-pivotal commented on a change in pull request #5140:
URL: https://github.com/apache/geode/pull/5140#discussion_r429265420
##
File path:
geode-redis/src/main/java/org/apache/geode/redis/internal/executor/hash/HExistsExecutor.java
##
@@ -53,12 +54,7 @@ public void executeCommand(Command command,
ExecutionHandlerContext context) {
RedisHash map = getRedisHash(context, key);
boolean hasField = map.containsKey(field);
-if (hasField) {
-
command.setResponse(Coder.getIntegerResponse(context.getByteBufAllocator(),
EXISTS));
-} else {
-
command.setResponse(Coder.getIntegerResponse(context.getByteBufAllocator(),
NOT_EXISTS));
-}
-
+return RedisResponse.integer(hasField ? EXISTS : NOT_EXISTS);
Review comment:
Yes, good idea.
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
> Convert all redis commands to return RedisResponse
> --
>
> Key: GEODE-8151
> URL: https://issues.apache.org/jira/browse/GEODE-8151
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
>
> This is an ongoing effort to refactor all redis commands to return
> RedisResponse
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8168) Redis pipelined command responses can be corrupted
[ https://issues.apache.org/jira/browse/GEODE-8168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114067#comment-17114067 ] ASF GitHub Bot commented on GEODE-8168: --- jdeppe-pivotal commented on pull request #5145: URL: https://github.com/apache/geode/pull/5145#issuecomment-632707135 @prettyClouds For your review... 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 pipelined command responses can be corrupted > -- > > Key: GEODE-8168 > URL: https://issues.apache.org/jira/browse/GEODE-8168 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > > Redis clients can send pipelined commands where commands are sent as batches. > Responses are expected in the same order as the commands. > Since we switched the responses of PUBLISH commands to be asynchronous, now > command responses can be interleaved incorrectly which results in clients to > break. For example the client is expecting a response from PUBLISH but, > instead, gets a response to HMSET. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8108) remove System.out.print calls from geode redis code
[ https://issues.apache.org/jira/browse/GEODE-8108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Bustamante Reyes reassigned GEODE-8108: --- Assignee: Alberto Bustamante Reyes > remove System.out.print calls from geode redis code > --- > > Key: GEODE-8108 > URL: https://issues.apache.org/jira/browse/GEODE-8108 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Alberto Bustamante Reyes >Priority: Major > > I noticed in SMoveExecutor a number of System.out.println calls. This should > not be done. > Either remove the calls (that is what I recommend for SMoveExecutor) or use a > logger. > I don't know if SMoveExecutor is the only place this happens so a code scan > should be done. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8108) remove System.out.print calls from geode redis code
[ https://issues.apache.org/jira/browse/GEODE-8108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114078#comment-17114078 ] ASF GitHub Bot commented on GEODE-8108: --- alb3rtobr opened a new pull request #5149: URL: https://github.com/apache/geode/pull/5149 Ticket description, reported by @dschneider-pivotal : > > I noticed in SMoveExecutor a number of System.out.println calls. This should not be done. > Either remove the calls (that is what I recommend for SMoveExecutor) or use a logger. > I don't know if SMoveExecutor is the only place this happens so a code scan should be done. `SMoveExecutor` class was already fixed but I searched for other calls to `System.out.println` in `geode-redis` and I have removed them. I also updated the logger of `GeodeRedisServer` class. 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 System.out.print calls from geode redis code > --- > > Key: GEODE-8108 > URL: https://issues.apache.org/jira/browse/GEODE-8108 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Alberto Bustamante Reyes >Priority: Major > > I noticed in SMoveExecutor a number of System.out.println calls. This should > not be done. > Either remove the calls (that is what I recommend for SMoveExecutor) or use a > logger. > I don't know if SMoveExecutor is the only place this happens so a code scan > should be done. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8108) remove System.out.print calls from geode redis code
[ https://issues.apache.org/jira/browse/GEODE-8108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Bustamante Reyes updated GEODE-8108: Labels: pull-request-available (was: ) > remove System.out.print calls from geode redis code > --- > > Key: GEODE-8108 > URL: https://issues.apache.org/jira/browse/GEODE-8108 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > > I noticed in SMoveExecutor a number of System.out.println calls. This should > not be done. > Either remove the calls (that is what I recommend for SMoveExecutor) or use a > logger. > I don't know if SMoveExecutor is the only place this happens so a code scan > should be done. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8144) endpoint identification in servers is not working
[
https://issues.apache.org/jira/browse/GEODE-8144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114097#comment-17114097
]
ASF GitHub Bot commented on GEODE-8144:
---
bschuchardt commented on a change in pull request #5131:
URL: https://github.com/apache/geode/pull/5131#discussion_r429282471
##
File path:
geode-core/src/main/java/org/apache/geode/internal/net/SocketCreator.java
##
@@ -791,7 +792,19 @@ private boolean setServerNames(SSLParameters
modifiedParams, HostAndPort addr) {
return false;
}
-serverNames.add(new SNIHostName(addr.getHostName()));
+String hostName = addr.getHostName();
+if (this.sslConfig.doEndpointIdentification()
+&& InetAddressValidator.getInstance().isValid(hostName)) {
+ // endpoint validation typically uses a hostname in the sniServer
parameter that the handshake
+ // will compare against the subject alternative addresses in the
server's certificate. Here
+ // we attempt to get a hostname instead of the proffered numeric address
+ try {
+hostName = InetAddress.getByName(hostName).getCanonicalHostName();
Review comment:
@pivotal-jbarrett if you will look at the implementation of
getCanonicalHostName, I think you will find that it already addresses your
concerns.
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
> endpoint identification in servers is not working
> -
>
> Key: GEODE-8144
> URL: https://issues.apache.org/jira/browse/GEODE-8144
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Priority: Major
>
> *update 5/20/2020*: this needs to be ported to 1.13 so it's picked up ASAP by
> TGF for VMs.
> If you enable endpoint identification in a server the server will not start.
> It will log exceptions like this:
>
> {noformat}
> javax.net.ssl.SSLHandshakeException: General SSLEngine problem
> at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1566)
> at
> sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:545)
> at
> sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1217)
> at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1185)
> at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:471)
> at
> org.apache.geode.internal.net.NioSslEngine.handshake(NioSslEngine.java:158)
> at
> org.apache.geode.internal.net.SocketCreator.handshakeSSLSocketChannel(SocketCreator.java:597)
> at
> org.apache.geode.internal.tcp.Connection.createIoFilter(Connection.java:1731)
> at org.apache.geode.internal.tcp.Connection.(Connection.java:1167)
> at
> org.apache.geode.internal.tcp.Connection.createSender(Connection.java:1004)
> at
> org.apache.geode.internal.tcp.ConnectionTable.handleNewPendingConnection(ConnectionTable.java:288)
> at
> org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:392)
> at
> org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:571)
> at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:800)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:451)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:268)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:510)
> 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.StartupOperation.sendStartupMessage(StartupOperation.java:74)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1623)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:361)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initiali
[jira] [Commented] (GEODE-8137) Implement loadService on JBossModuleService
[ https://issues.apache.org/jira/browse/GEODE-8137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114101#comment-17114101 ] ASF subversion and git services commented on GEODE-8137: Commit 387f21b49404d834dd9da5cc0a153ff1201256c4 in geode's branch refs/heads/feature/GEODE-8067 from Patrick Johnson [ https://gitbox.apache.org/repos/asf?p=geode.git;h=387f21b ] GEODE-8137 - Implement loadService. (#5136) > Implement loadService on JBossModuleService > --- > > Key: GEODE-8137 > URL: https://issues.apache.org/jira/browse/GEODE-8137 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Implement loadService to load implementations of a given interface from JBoss > Modules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8137) Implement loadService on JBossModuleService
[ https://issues.apache.org/jira/browse/GEODE-8137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114098#comment-17114098 ] ASF GitHub Bot commented on GEODE-8137: --- kohlmu-pivotal merged pull request #5136: URL: https://github.com/apache/geode/pull/5136 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 > Implement loadService on JBossModuleService > --- > > Key: GEODE-8137 > URL: https://issues.apache.org/jira/browse/GEODE-8137 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Implement loadService to load implementations of a given interface from JBoss > Modules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8144) endpoint identification in servers is not working
[
https://issues.apache.org/jira/browse/GEODE-8144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114106#comment-17114106
]
ASF GitHub Bot commented on GEODE-8144:
---
bschuchardt commented on a change in pull request #5131:
URL: https://github.com/apache/geode/pull/5131#discussion_r429282471
##
File path:
geode-core/src/main/java/org/apache/geode/internal/net/SocketCreator.java
##
@@ -791,7 +792,19 @@ private boolean setServerNames(SSLParameters
modifiedParams, HostAndPort addr) {
return false;
}
-serverNames.add(new SNIHostName(addr.getHostName()));
+String hostName = addr.getHostName();
+if (this.sslConfig.doEndpointIdentification()
+&& InetAddressValidator.getInstance().isValid(hostName)) {
+ // endpoint validation typically uses a hostname in the sniServer
parameter that the handshake
+ // will compare against the subject alternative addresses in the
server's certificate. Here
+ // we attempt to get a hostname instead of the proffered numeric address
+ try {
+hostName = InetAddress.getByName(hostName).getCanonicalHostName();
Review comment:
@pivotal-jbarrett if you will look at the implementation of
getCanonicalHostName, I think you will find that it already addresses your
concerns. Also, this is just setting the sniServerName field, not redirecting
the socket to connect to a different address.
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
> endpoint identification in servers is not working
> -
>
> Key: GEODE-8144
> URL: https://issues.apache.org/jira/browse/GEODE-8144
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Priority: Major
>
> *update 5/20/2020*: this needs to be ported to 1.13 so it's picked up ASAP by
> TGF for VMs.
> If you enable endpoint identification in a server the server will not start.
> It will log exceptions like this:
>
> {noformat}
> javax.net.ssl.SSLHandshakeException: General SSLEngine problem
> at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1566)
> at
> sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:545)
> at
> sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1217)
> at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1185)
> at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:471)
> at
> org.apache.geode.internal.net.NioSslEngine.handshake(NioSslEngine.java:158)
> at
> org.apache.geode.internal.net.SocketCreator.handshakeSSLSocketChannel(SocketCreator.java:597)
> at
> org.apache.geode.internal.tcp.Connection.createIoFilter(Connection.java:1731)
> at org.apache.geode.internal.tcp.Connection.(Connection.java:1167)
> at
> org.apache.geode.internal.tcp.Connection.createSender(Connection.java:1004)
> at
> org.apache.geode.internal.tcp.ConnectionTable.handleNewPendingConnection(ConnectionTable.java:288)
> at
> org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:392)
> at
> org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:571)
> at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:800)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:451)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:268)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:510)
> 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.StartupOperation.sendStartupMessage(StartupOperation.java:74)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1623)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(Cluster
[jira] [Commented] (GEODE-8144) endpoint identification in servers is not working
[
https://issues.apache.org/jira/browse/GEODE-8144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114124#comment-17114124
]
ASF GitHub Bot commented on GEODE-8144:
---
bschuchardt commented on a change in pull request #5131:
URL: https://github.com/apache/geode/pull/5131#discussion_r429282471
##
File path:
geode-core/src/main/java/org/apache/geode/internal/net/SocketCreator.java
##
@@ -791,7 +792,19 @@ private boolean setServerNames(SSLParameters
modifiedParams, HostAndPort addr) {
return false;
}
-serverNames.add(new SNIHostName(addr.getHostName()));
+String hostName = addr.getHostName();
+if (this.sslConfig.doEndpointIdentification()
+&& InetAddressValidator.getInstance().isValid(hostName)) {
+ // endpoint validation typically uses a hostname in the sniServer
parameter that the handshake
+ // will compare against the subject alternative addresses in the
server's certificate. Here
+ // we attempt to get a hostname instead of the proffered numeric address
+ try {
+hostName = InetAddress.getByName(hostName).getCanonicalHostName();
Review comment:
@pivotal-jbarrett if you will look at the implementation of
getCanonicalHostName, I think you will find that it already addresses your
concerns. Also, this is just setting the sniServerName field, not redirecting
the socket to connect to a different address.
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
> endpoint identification in servers is not working
> -
>
> Key: GEODE-8144
> URL: https://issues.apache.org/jira/browse/GEODE-8144
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Priority: Major
>
> *update 5/20/2020*: this needs to be ported to 1.13 so it's picked up ASAP by
> TGF for VMs.
> If you enable endpoint identification in a server the server will not start.
> It will log exceptions like this:
>
> {noformat}
> javax.net.ssl.SSLHandshakeException: General SSLEngine problem
> at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1566)
> at
> sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:545)
> at
> sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1217)
> at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1185)
> at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:471)
> at
> org.apache.geode.internal.net.NioSslEngine.handshake(NioSslEngine.java:158)
> at
> org.apache.geode.internal.net.SocketCreator.handshakeSSLSocketChannel(SocketCreator.java:597)
> at
> org.apache.geode.internal.tcp.Connection.createIoFilter(Connection.java:1731)
> at org.apache.geode.internal.tcp.Connection.(Connection.java:1167)
> at
> org.apache.geode.internal.tcp.Connection.createSender(Connection.java:1004)
> at
> org.apache.geode.internal.tcp.ConnectionTable.handleNewPendingConnection(ConnectionTable.java:288)
> at
> org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:392)
> at
> org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:571)
> at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:800)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:451)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:268)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:510)
> 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.StartupOperation.sendStartupMessage(StartupOperation.java:74)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1623)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(Cluster
[jira] [Commented] (GEODE-8171) javadoc for putAll need to have accurate exception
[ https://issues.apache.org/jira/browse/GEODE-8171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114142#comment-17114142 ] ASF GitHub Bot commented on GEODE-8171: --- karensmolermiller commented on a change in pull request #5147: URL: https://github.com/apache/geode/pull/5147#discussion_r429308490 ## File path: geode-core/src/main/java/org/apache/geode/cache/Region.java ## @@ -1359,10 +1359,30 @@ Object selectValue(String queryPredicate) throws FunctionDomainException, TypeMi * in the specified map. This operation will be distributed to other caches if the scope is not * Scope.LOCAL. * - * @param map the key/value pairs to put in this region. - * @since GemFire 5.0 + * If any exception is thrown due to this call, it can imply that there may have been a partial + * update performed on the region. Use putAll from within a transaction to get atomicity with all + * the + * entries. Review comment: This sentence is missing some pronouns, and the last sentence might be worded better. Here's my attempt at a rewrite: If an exception is thrown due to this call, it can imply that there may have been a partial * update performed on the region. Use putAll from within a transaction to obtain * an atomic update. 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 > javadoc for putAll need to have accurate exception > --- > > Key: GEODE-8171 > URL: https://issues.apache.org/jira/browse/GEODE-8171 > Project: Geode > Issue Type: Improvement >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI > > Both the javadocs and the user guide need a more accurate description of the > exceptions that can be thrown when an app calls putAll(). > Correct the javadocs to list all exceptions that may be thrown. > Add a code fragment example to the user guide (and to the javadocs, if > appropriate) that shows a best practice for an app to call putAll() and > handle exceptions. > Describe what might cause the exceptions and let users know how to adjust > cluster configuration mitigate the exceptions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8041) Create ManagementService Interface
[ https://issues.apache.org/jira/browse/GEODE-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114161#comment-17114161 ] ASF subversion and git services commented on GEODE-8041: Commit 6daf75ba06dfcaf2b154f628e162ead5ad58ce0e in geode's branch refs/heads/feature/GEODE-8067 from Patrick Johnson [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6daf75b ] GEODE-8041 - Create ManagementService interface. (#5062) > Create ManagementService Interface > -- > > Key: GEODE-8041 > URL: https://issues.apache.org/jira/browse/GEODE-8041 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Create a ManagementService interface. The ManagementService will configure > and start Geode (create a Cache given some configuration properties) after > the BootstrappingService has bootstrapped the environment and loaded the > relevant modules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8137) Implement loadService on JBossModuleService
[ https://issues.apache.org/jira/browse/GEODE-8137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114163#comment-17114163 ] ASF subversion and git services commented on GEODE-8137: Commit e98d2a0f2ab3794c3e770bda0ad446e5ac4d8bd6 in geode's branch refs/heads/feature/GEODE-8067 from Patrick Johnson [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e98d2a0 ] GEODE-8137 - Implement loadService. (#5136) > Implement loadService on JBossModuleService > --- > > Key: GEODE-8137 > URL: https://issues.apache.org/jira/browse/GEODE-8137 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Implement loadService to load implementations of a given interface from JBoss > Modules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8043) Create JBoss-Modules ModuleService Implementation - loadModule
[ https://issues.apache.org/jira/browse/GEODE-8043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114162#comment-17114162 ] ASF subversion and git services commented on GEODE-8043: Commit cb7260135299ff42b9ddf8a6a37752a368c247a9 in geode's branch refs/heads/feature/GEODE-8067 from Udo Kohlmeyer [ https://gitbox.apache.org/repos/asf?p=geode.git;h=cb72601 ] GEODE-8043 - Create JBossModuleService and implement loadModule. (#5081) > Create JBoss-Modules ModuleService Implementation - loadModule > -- > > Key: GEODE-8043 > URL: https://issues.apache.org/jira/browse/GEODE-8043 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Implement the loadModule method of the ModuleService interface using > JBoss-Modules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8131) reader thread blocked attempting to issue an alert
[
https://issues.apache.org/jira/browse/GEODE-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114159#comment-17114159
]
ASF subversion and git services commented on GEODE-8131:
Commit 358fd7067cc56b1ceb8c3d7c271c3a5254d7ee93 in geode's branch
refs/heads/feature/GEODE-8067 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=358fd70 ]
GEODE-8131: reader thread blocked attempting to issue an alert (#5132)
* GEODE-8131: reader thread blocked attempting to issue an alert
This PR does not solve the problem of the alert system causing a P2P
message reader to block but instead ensures that the reader thread will
write deserialization information to the log before issuing a fatal
alert. If the alert level is set to "info" this won't help, but no-one
would set the alert level to that level.
Along the way I removed some duplicate strings.
* removing duplicate code & logging toString of exceptions at fatal-level
> reader thread blocked attempting to issue an alert
> --
>
> Key: GEODE-8131
> URL: https://issues.apache.org/jira/browse/GEODE-8131
> Project: Geode
> Issue Type: Bug
> Components: logging, membership
>Reporter: Bruce J Schuchardt
>Priority: Major
>
> This v1.8 TcpConduit reader thread was blocked in a production system. It
> had experienced a deserialization error and was trying to log the exception.
> A Manager was present in the cluster and had registered as an alert listener.
> Another thread was blocked sending something on the shared/unordered
> connection that this alert should be sent on. This persisted for over 6
> hours and we never saw the serialization exception in the log file.
> Consequently we had to recommend setting the alert level to None and have
> them run into the serialization problem again.
> This is a serious flaw in the alerting system and it's caused us grief many
> times. We should log alerts before attempting to send them to
> alert-listeners.
>
> {noformat}
> "P2P message reader for 10.236.28.120(servername-removed):56152 shared
> unordered uid=9 port=41204" tid=0xd49 (in native) java.lang.Thread.State:
> RUNNABLE at sun.nio.ch.FileDispatcherImpl.write0(Native Method) at
> sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) at
> sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) at
> sun.nio.ch.IOUtil.write(IOUtil.java:51) at
> sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471) - locked
> java.lang.Object@24528b9b at
> org.apache.geode.internal.tcp.Connection.nioWriteFully(Connection.java:3291)
> - locked java.lang.Object@42a1a79b at
> org.apache.geode.internal.tcp.Connection.sendPreserialized(Connection.java:2527)
> at org.apache.geode.internal.tcp.MsgStreamer.realFlush(MsgStreamer.java:319)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:244)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:393)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:250)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:615)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.directChannelSend(GMSMembershipManager.java:1717)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.send(GMSMembershipManager.java:1898)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2878)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:2798)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2837)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1531)
> at
> org.apache.geode.internal.alerting.AlertMessaging.sendAlert(AlertMessaging.java:75)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender.sendAlertMessage(AlertAppender.java:188)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender.doAppend(AlertAppender.java:163)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender.lambda$append$0(AlertAppender.java:159)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender$$Lambda$168/1102181662.run(Unknown
> Source) at
> org.apache.geode.internal.alerting.AlertingAction.execute(AlertingAction.java:29)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender.append(AlertAppender.java:159)
> at
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
> at
> org.apache.logging.log4j.core.config.
[jira] [Commented] (GEODE-8150) Downgrade ClassGraph to 4.8.52
[
https://issues.apache.org/jira/browse/GEODE-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114153#comment-17114153
]
ASF subversion and git services commented on GEODE-8150:
Commit 07bf3dd827f29a5deb8619f79203d94847a1a823 in geode's branch
refs/heads/feature/GEODE-8067 from Juan José Ramos
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=07bf3dd ]
GEODE-8150: Downgrade classgraph to 4.8.52 (#5138)
A performance degradation was introduced when upgrading this library
to a more recent version, downgrading to the last known working one
until a full fix is found.
> Downgrade ClassGraph to 4.8.52
> --
>
> Key: GEODE-8150
> URL: https://issues.apache.org/jira/browse/GEODE-8150
> Project: Geode
> Issue Type: Bug
> Components: management
>Affects Versions: 1.13.0
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
> Labels: caching-applications
> Fix For: 1.13.0, 1.14.0
>
>
> While running an internal performance testing scenario, we noticed a
> degradation of around 15% average between the time an entry is added to the
> server region and the time a client with registered CQs receives the
> {{onEvent}} listener callback.
> The scenario itself uses two empty feeder members ({{DataPolicy.EMPTY}}) and
> 4 data members ({{DataPolicy.REPLICATE}}), there are also 8 regular clients
> with {{CQs}} registered on the servers. The feeders continuously
> insert/update custom objects into the region (the entries have a
> {{timestamp}}) and the clients measure the latency between the original
> {{timestamp}} and the one at which they receive the event through the
> {{CqListener.onEvent}} callback.
> After troubleshooting the issue we were able to pinpoint a specific commit
> on which we start seeing the increase in latency:
> {noformat}
> commit e9993c15d88a5edd2a486fd64339deba37c24945
> Author: Anthony Baker
> Date: Sat Mar 28 15:35:15 2020 -0700
> GEODE-7765: Update dependencies for v1.13
> Update many but not all dependencies.
> {noformat}
> The above commit is just an upgrade of several external dependencies, so we
> went ahead and executed the internal scenario using various combinations and
> reverting several dependencies to the "working" version until we found the
> one that's causing the issue: the upgrade of {{classgraph}} from version
> {{4.8.52}} to {{4.8.68}}.
> We've tried upgrading the dependency to the latest released version
> {{4.8.78}} and also increasing the memory to alleviate the extra garbage
> generated (this worked in the past for another degradation introduced by
> upgrading the same library) without luck, the degradation is still there.
> Further troubleshooting demonstrated that the actual latency in our test is
> introduced when moving from {{classgraph-4.8.61}} to {{classgraph-4.8.62}},
> so the purpose of this ticket is to downgrade the library to version
> {{4.8.61}}.
> {noformat}
>
> CLASSGRAPH 4.8.62
>
> TEST STATSPEC OP#0 #1#2#3#4#5#6
> #7#8
> 63c681d217 e9993c15d8
> e9993c15d8 + classgraph-4.8.62
> **
> #
> scale081 putResponseTime del --- --- -1.02 --- --- --- 1.01
> 1.01 ---
> putsPerSecond avg --- --- -1.02 --- -1.01 --- 1.01
> --- -1.01
> updateEventsPerSecond avg --- --- -1.02 --- --- --- ---
> --- ---
> updateLatency del --- --- -1.01 -1.15 -1.19 -1.18 -1.15
> -1.13 -1.18
>
> --- = Statistic value is less than the ratio threshold
> +inf = Statistic value went from zero to non-zero or vice versa and this is
> good
> -inf = Statistic value went from zero to non-zero or vice versa and this is
> bad
>
>
> CLASSGRAPH 4.8.61
>
> TEST STATSPEC OP#0 #1#2#3#4#5#6
> #7#8
> 63c681d217 e9993c15d8
> e9993c15d8 + classgraph-4.8.61
> **
> #
> scale081 putResponseTime del --- --- -1.02
[jira] [Commented] (GEODE-8170) Change all redis set and hash commands to use function+delta
[ https://issues.apache.org/jira/browse/GEODE-8170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114155#comment-17114155 ] ASF subversion and git services commented on GEODE-8170: Commit 9a0563ef1061ca2834db257b50c3a80c1941fb07 in geode's branch refs/heads/feature/GEODE-8067 from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9a0563e ] GEODE-8170: change all hash and set commands to use function (#5125) All hash and set commands now use the new function+delta data model. This allowed the synchronized keyword to be removed from RedisHash and RedisSet. > Change all redis set and hash commands to use function+delta > > > Key: GEODE-8170 > URL: https://issues.apache.org/jira/browse/GEODE-8170 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.14.0 > > > All the existing commands that access the RedisHash or RedisSet class should > do so using the CommandFunction. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8037) Create BootstrappingService Interface
[ https://issues.apache.org/jira/browse/GEODE-8037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114160#comment-17114160 ] ASF subversion and git services commented on GEODE-8037: Commit 9777e76c6aaaceb8c6d1d53e35c9396461fec999 in geode's branch refs/heads/feature/GEODE-8067 from Patrick Johnson [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9777e76 ] GEODE-8037 - Create BootstrappingService interface. (#5046) > Create BootstrappingService Interface > - > > Key: GEODE-8037 > URL: https://issues.apache.org/jira/browse/GEODE-8037 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Create a BootstrapingService interface. The BootstrappingService will use the > ModuleService to bootstrap Geode in a classloader-isolated way, i.e. loading > the necessary modules to run Geode. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8131) reader thread blocked attempting to issue an alert
[
https://issues.apache.org/jira/browse/GEODE-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114158#comment-17114158
]
ASF subversion and git services commented on GEODE-8131:
Commit 358fd7067cc56b1ceb8c3d7c271c3a5254d7ee93 in geode's branch
refs/heads/feature/GEODE-8067 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=358fd70 ]
GEODE-8131: reader thread blocked attempting to issue an alert (#5132)
* GEODE-8131: reader thread blocked attempting to issue an alert
This PR does not solve the problem of the alert system causing a P2P
message reader to block but instead ensures that the reader thread will
write deserialization information to the log before issuing a fatal
alert. If the alert level is set to "info" this won't help, but no-one
would set the alert level to that level.
Along the way I removed some duplicate strings.
* removing duplicate code & logging toString of exceptions at fatal-level
> reader thread blocked attempting to issue an alert
> --
>
> Key: GEODE-8131
> URL: https://issues.apache.org/jira/browse/GEODE-8131
> Project: Geode
> Issue Type: Bug
> Components: logging, membership
>Reporter: Bruce J Schuchardt
>Priority: Major
>
> This v1.8 TcpConduit reader thread was blocked in a production system. It
> had experienced a deserialization error and was trying to log the exception.
> A Manager was present in the cluster and had registered as an alert listener.
> Another thread was blocked sending something on the shared/unordered
> connection that this alert should be sent on. This persisted for over 6
> hours and we never saw the serialization exception in the log file.
> Consequently we had to recommend setting the alert level to None and have
> them run into the serialization problem again.
> This is a serious flaw in the alerting system and it's caused us grief many
> times. We should log alerts before attempting to send them to
> alert-listeners.
>
> {noformat}
> "P2P message reader for 10.236.28.120(servername-removed):56152 shared
> unordered uid=9 port=41204" tid=0xd49 (in native) java.lang.Thread.State:
> RUNNABLE at sun.nio.ch.FileDispatcherImpl.write0(Native Method) at
> sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) at
> sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) at
> sun.nio.ch.IOUtil.write(IOUtil.java:51) at
> sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471) - locked
> java.lang.Object@24528b9b at
> org.apache.geode.internal.tcp.Connection.nioWriteFully(Connection.java:3291)
> - locked java.lang.Object@42a1a79b at
> org.apache.geode.internal.tcp.Connection.sendPreserialized(Connection.java:2527)
> at org.apache.geode.internal.tcp.MsgStreamer.realFlush(MsgStreamer.java:319)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:244)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:393)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:250)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:615)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.directChannelSend(GMSMembershipManager.java:1717)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.send(GMSMembershipManager.java:1898)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2878)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:2798)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2837)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1531)
> at
> org.apache.geode.internal.alerting.AlertMessaging.sendAlert(AlertMessaging.java:75)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender.sendAlertMessage(AlertAppender.java:188)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender.doAppend(AlertAppender.java:163)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender.lambda$append$0(AlertAppender.java:159)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender$$Lambda$168/1102181662.run(Unknown
> Source) at
> org.apache.geode.internal.alerting.AlertingAction.execute(AlertingAction.java:29)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender.append(AlertAppender.java:159)
> at
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
> at
> org.apache.logging.log4j.core.config.
[jira] [Commented] (GEODE-8145) Add Redis configuration properties to gemfire_properties.html
[ https://issues.apache.org/jira/browse/GEODE-8145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114156#comment-17114156 ] ASF subversion and git services commented on GEODE-8145: Commit 0f8da9e2894979d61d8b6cd58234dfbcc3817e85 in geode's branch refs/heads/feature/GEODE-8067 from Sarah Abbey [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0f8da9e ] GEODE-8145: Add Redis configuration properties to gemfire_properties.html (#5130) > Add Redis configuration properties to gemfire_properties.html > - > > Key: GEODE-8145 > URL: https://issues.apache.org/jira/browse/GEODE-8145 > Project: Geode > Issue Type: Improvement > Components: docs, redis >Reporter: Sarah Abbey >Priority: Minor > Fix For: 1.14.0 > > > redis-password, redis-bind-address, and redis-port need to be added to this > page -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8146) Restore winrm-cli to latest from source
[ https://issues.apache.org/jira/browse/GEODE-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114157#comment-17114157 ] ASF subversion and git services commented on GEODE-8146: Commit f2392d0403a292f8e85c5d466329bce5f0d5b819 in geode's branch refs/heads/feature/GEODE-8067 from Robert Houghton [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f2392d0 ] GEODE-8146: use latest winrm in tools image (#5134) * Built cleanly in multistage build * Moved from python2 -> python3 * Pin concourse-pipeline resource Authored-by: Robert Houghton > Restore winrm-cli to latest from source > --- > > Key: GEODE-8146 > URL: https://issues.apache.org/jira/browse/GEODE-8146 > Project: Geode > Issue Type: Improvement > Components: ci, tests >Reporter: Robert Houghton >Priority: Major > Fix For: 1.14.0 > > > winrm-cli has updated to fix the bug causing GEODE-7788, as reported in > [their github|https://github.com/masterzen/winrm/issues/101] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8112) Need to add a member option in query command
[ https://issues.apache.org/jira/browse/GEODE-8112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114154#comment-17114154 ] ASF subversion and git services commented on GEODE-8112: Commit d08847baebcd2c975941be4641e8db2b7612ab6b in geode's branch refs/heads/feature/GEODE-8067 from Eric Shu [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d08847b ] GEODE-8112: Add --member option in query command. (#5102) > Need to add a member option in query command > > > Key: GEODE-8112 > URL: https://issues.apache.org/jira/browse/GEODE-8112 > Project: Geode > Issue Type: Bug > Components: gfsh, querying >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: caching-applications > Fix For: 1.14.0 > > > When gfsh query running on replicate proxy region, it will return 0 results > as no data stored on the proxy region. > To help solving this issue, gfsh querying can add a member option so that > query can route to a particular data host member to get the needed results. > User can use "describe region" to find out which data host, then use it in > the query. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8131) reader thread blocked attempting to issue an alert
[
https://issues.apache.org/jira/browse/GEODE-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114169#comment-17114169
]
ASF subversion and git services commented on GEODE-8131:
Commit 358fd7067cc56b1ceb8c3d7c271c3a5254d7ee93 in geode's branch
refs/heads/feature/GEODE-8067 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=358fd70 ]
GEODE-8131: reader thread blocked attempting to issue an alert (#5132)
* GEODE-8131: reader thread blocked attempting to issue an alert
This PR does not solve the problem of the alert system causing a P2P
message reader to block but instead ensures that the reader thread will
write deserialization information to the log before issuing a fatal
alert. If the alert level is set to "info" this won't help, but no-one
would set the alert level to that level.
Along the way I removed some duplicate strings.
* removing duplicate code & logging toString of exceptions at fatal-level
> reader thread blocked attempting to issue an alert
> --
>
> Key: GEODE-8131
> URL: https://issues.apache.org/jira/browse/GEODE-8131
> Project: Geode
> Issue Type: Bug
> Components: logging, membership
>Reporter: Bruce J Schuchardt
>Priority: Major
>
> This v1.8 TcpConduit reader thread was blocked in a production system. It
> had experienced a deserialization error and was trying to log the exception.
> A Manager was present in the cluster and had registered as an alert listener.
> Another thread was blocked sending something on the shared/unordered
> connection that this alert should be sent on. This persisted for over 6
> hours and we never saw the serialization exception in the log file.
> Consequently we had to recommend setting the alert level to None and have
> them run into the serialization problem again.
> This is a serious flaw in the alerting system and it's caused us grief many
> times. We should log alerts before attempting to send them to
> alert-listeners.
>
> {noformat}
> "P2P message reader for 10.236.28.120(servername-removed):56152 shared
> unordered uid=9 port=41204" tid=0xd49 (in native) java.lang.Thread.State:
> RUNNABLE at sun.nio.ch.FileDispatcherImpl.write0(Native Method) at
> sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) at
> sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) at
> sun.nio.ch.IOUtil.write(IOUtil.java:51) at
> sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471) - locked
> java.lang.Object@24528b9b at
> org.apache.geode.internal.tcp.Connection.nioWriteFully(Connection.java:3291)
> - locked java.lang.Object@42a1a79b at
> org.apache.geode.internal.tcp.Connection.sendPreserialized(Connection.java:2527)
> at org.apache.geode.internal.tcp.MsgStreamer.realFlush(MsgStreamer.java:319)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:244)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:393)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:250)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:615)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.directChannelSend(GMSMembershipManager.java:1717)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.send(GMSMembershipManager.java:1898)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2878)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:2798)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2837)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1531)
> at
> org.apache.geode.internal.alerting.AlertMessaging.sendAlert(AlertMessaging.java:75)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender.sendAlertMessage(AlertAppender.java:188)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender.doAppend(AlertAppender.java:163)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender.lambda$append$0(AlertAppender.java:159)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender$$Lambda$168/1102181662.run(Unknown
> Source) at
> org.apache.geode.internal.alerting.AlertingAction.execute(AlertingAction.java:29)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender.append(AlertAppender.java:159)
> at
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
> at
> org.apache.logging.log4j.core.config.
[jira] [Commented] (GEODE-8037) Create BootstrappingService Interface
[ https://issues.apache.org/jira/browse/GEODE-8037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114171#comment-17114171 ] ASF subversion and git services commented on GEODE-8037: Commit 9777e76c6aaaceb8c6d1d53e35c9396461fec999 in geode's branch refs/heads/feature/GEODE-8067 from Patrick Johnson [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9777e76 ] GEODE-8037 - Create BootstrappingService interface. (#5046) > Create BootstrappingService Interface > - > > Key: GEODE-8037 > URL: https://issues.apache.org/jira/browse/GEODE-8037 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Create a BootstrapingService interface. The BootstrappingService will use the > ModuleService to bootstrap Geode in a classloader-isolated way, i.e. loading > the necessary modules to run Geode. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8170) Change all redis set and hash commands to use function+delta
[ https://issues.apache.org/jira/browse/GEODE-8170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114166#comment-17114166 ] ASF subversion and git services commented on GEODE-8170: Commit 9a0563ef1061ca2834db257b50c3a80c1941fb07 in geode's branch refs/heads/feature/GEODE-8067 from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9a0563e ] GEODE-8170: change all hash and set commands to use function (#5125) All hash and set commands now use the new function+delta data model. This allowed the synchronized keyword to be removed from RedisHash and RedisSet. > Change all redis set and hash commands to use function+delta > > > Key: GEODE-8170 > URL: https://issues.apache.org/jira/browse/GEODE-8170 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.14.0 > > > All the existing commands that access the RedisHash or RedisSet class should > do so using the CommandFunction. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8150) Downgrade ClassGraph to 4.8.52
[
https://issues.apache.org/jira/browse/GEODE-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114164#comment-17114164
]
ASF subversion and git services commented on GEODE-8150:
Commit 07bf3dd827f29a5deb8619f79203d94847a1a823 in geode's branch
refs/heads/feature/GEODE-8067 from Juan José Ramos
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=07bf3dd ]
GEODE-8150: Downgrade classgraph to 4.8.52 (#5138)
A performance degradation was introduced when upgrading this library
to a more recent version, downgrading to the last known working one
until a full fix is found.
> Downgrade ClassGraph to 4.8.52
> --
>
> Key: GEODE-8150
> URL: https://issues.apache.org/jira/browse/GEODE-8150
> Project: Geode
> Issue Type: Bug
> Components: management
>Affects Versions: 1.13.0
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
> Labels: caching-applications
> Fix For: 1.13.0, 1.14.0
>
>
> While running an internal performance testing scenario, we noticed a
> degradation of around 15% average between the time an entry is added to the
> server region and the time a client with registered CQs receives the
> {{onEvent}} listener callback.
> The scenario itself uses two empty feeder members ({{DataPolicy.EMPTY}}) and
> 4 data members ({{DataPolicy.REPLICATE}}), there are also 8 regular clients
> with {{CQs}} registered on the servers. The feeders continuously
> insert/update custom objects into the region (the entries have a
> {{timestamp}}) and the clients measure the latency between the original
> {{timestamp}} and the one at which they receive the event through the
> {{CqListener.onEvent}} callback.
> After troubleshooting the issue we were able to pinpoint a specific commit
> on which we start seeing the increase in latency:
> {noformat}
> commit e9993c15d88a5edd2a486fd64339deba37c24945
> Author: Anthony Baker
> Date: Sat Mar 28 15:35:15 2020 -0700
> GEODE-7765: Update dependencies for v1.13
> Update many but not all dependencies.
> {noformat}
> The above commit is just an upgrade of several external dependencies, so we
> went ahead and executed the internal scenario using various combinations and
> reverting several dependencies to the "working" version until we found the
> one that's causing the issue: the upgrade of {{classgraph}} from version
> {{4.8.52}} to {{4.8.68}}.
> We've tried upgrading the dependency to the latest released version
> {{4.8.78}} and also increasing the memory to alleviate the extra garbage
> generated (this worked in the past for another degradation introduced by
> upgrading the same library) without luck, the degradation is still there.
> Further troubleshooting demonstrated that the actual latency in our test is
> introduced when moving from {{classgraph-4.8.61}} to {{classgraph-4.8.62}},
> so the purpose of this ticket is to downgrade the library to version
> {{4.8.61}}.
> {noformat}
>
> CLASSGRAPH 4.8.62
>
> TEST STATSPEC OP#0 #1#2#3#4#5#6
> #7#8
> 63c681d217 e9993c15d8
> e9993c15d8 + classgraph-4.8.62
> **
> #
> scale081 putResponseTime del --- --- -1.02 --- --- --- 1.01
> 1.01 ---
> putsPerSecond avg --- --- -1.02 --- -1.01 --- 1.01
> --- -1.01
> updateEventsPerSecond avg --- --- -1.02 --- --- --- ---
> --- ---
> updateLatency del --- --- -1.01 -1.15 -1.19 -1.18 -1.15
> -1.13 -1.18
>
> --- = Statistic value is less than the ratio threshold
> +inf = Statistic value went from zero to non-zero or vice versa and this is
> good
> -inf = Statistic value went from zero to non-zero or vice versa and this is
> bad
>
>
> CLASSGRAPH 4.8.61
>
> TEST STATSPEC OP#0 #1#2#3#4#5#6
> #7#8
> 63c681d217 e9993c15d8
> e9993c15d8 + classgraph-4.8.61
> **
> #
> scale081 putResponseTime del --- --- -1.02
[jira] [Commented] (GEODE-8145) Add Redis configuration properties to gemfire_properties.html
[ https://issues.apache.org/jira/browse/GEODE-8145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114167#comment-17114167 ] ASF subversion and git services commented on GEODE-8145: Commit 0f8da9e2894979d61d8b6cd58234dfbcc3817e85 in geode's branch refs/heads/feature/GEODE-8067 from Sarah Abbey [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0f8da9e ] GEODE-8145: Add Redis configuration properties to gemfire_properties.html (#5130) > Add Redis configuration properties to gemfire_properties.html > - > > Key: GEODE-8145 > URL: https://issues.apache.org/jira/browse/GEODE-8145 > Project: Geode > Issue Type: Improvement > Components: docs, redis >Reporter: Sarah Abbey >Priority: Minor > Fix For: 1.14.0 > > > redis-password, redis-bind-address, and redis-port need to be added to this > page -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8043) Create JBoss-Modules ModuleService Implementation - loadModule
[ https://issues.apache.org/jira/browse/GEODE-8043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114173#comment-17114173 ] ASF subversion and git services commented on GEODE-8043: Commit cb7260135299ff42b9ddf8a6a37752a368c247a9 in geode's branch refs/heads/feature/GEODE-8067 from Udo Kohlmeyer [ https://gitbox.apache.org/repos/asf?p=geode.git;h=cb72601 ] GEODE-8043 - Create JBossModuleService and implement loadModule. (#5081) > Create JBoss-Modules ModuleService Implementation - loadModule > -- > > Key: GEODE-8043 > URL: https://issues.apache.org/jira/browse/GEODE-8043 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Implement the loadModule method of the ModuleService interface using > JBoss-Modules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8112) Need to add a member option in query command
[ https://issues.apache.org/jira/browse/GEODE-8112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114165#comment-17114165 ] ASF subversion and git services commented on GEODE-8112: Commit d08847baebcd2c975941be4641e8db2b7612ab6b in geode's branch refs/heads/feature/GEODE-8067 from Eric Shu [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d08847b ] GEODE-8112: Add --member option in query command. (#5102) > Need to add a member option in query command > > > Key: GEODE-8112 > URL: https://issues.apache.org/jira/browse/GEODE-8112 > Project: Geode > Issue Type: Bug > Components: gfsh, querying >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: caching-applications > Fix For: 1.14.0 > > > When gfsh query running on replicate proxy region, it will return 0 results > as no data stored on the proxy region. > To help solving this issue, gfsh querying can add a member option so that > query can route to a particular data host member to get the needed results. > User can use "describe region" to find out which data host, then use it in > the query. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8041) Create ManagementService Interface
[ https://issues.apache.org/jira/browse/GEODE-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114172#comment-17114172 ] ASF subversion and git services commented on GEODE-8041: Commit 6daf75ba06dfcaf2b154f628e162ead5ad58ce0e in geode's branch refs/heads/feature/GEODE-8067 from Patrick Johnson [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6daf75b ] GEODE-8041 - Create ManagementService interface. (#5062) > Create ManagementService Interface > -- > > Key: GEODE-8041 > URL: https://issues.apache.org/jira/browse/GEODE-8041 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Create a ManagementService interface. The ManagementService will configure > and start Geode (create a Cache given some configuration properties) after > the BootstrappingService has bootstrapped the environment and loaded the > relevant modules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8131) reader thread blocked attempting to issue an alert
[
https://issues.apache.org/jira/browse/GEODE-8131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114170#comment-17114170
]
ASF subversion and git services commented on GEODE-8131:
Commit 358fd7067cc56b1ceb8c3d7c271c3a5254d7ee93 in geode's branch
refs/heads/feature/GEODE-8067 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=358fd70 ]
GEODE-8131: reader thread blocked attempting to issue an alert (#5132)
* GEODE-8131: reader thread blocked attempting to issue an alert
This PR does not solve the problem of the alert system causing a P2P
message reader to block but instead ensures that the reader thread will
write deserialization information to the log before issuing a fatal
alert. If the alert level is set to "info" this won't help, but no-one
would set the alert level to that level.
Along the way I removed some duplicate strings.
* removing duplicate code & logging toString of exceptions at fatal-level
> reader thread blocked attempting to issue an alert
> --
>
> Key: GEODE-8131
> URL: https://issues.apache.org/jira/browse/GEODE-8131
> Project: Geode
> Issue Type: Bug
> Components: logging, membership
>Reporter: Bruce J Schuchardt
>Priority: Major
>
> This v1.8 TcpConduit reader thread was blocked in a production system. It
> had experienced a deserialization error and was trying to log the exception.
> A Manager was present in the cluster and had registered as an alert listener.
> Another thread was blocked sending something on the shared/unordered
> connection that this alert should be sent on. This persisted for over 6
> hours and we never saw the serialization exception in the log file.
> Consequently we had to recommend setting the alert level to None and have
> them run into the serialization problem again.
> This is a serious flaw in the alerting system and it's caused us grief many
> times. We should log alerts before attempting to send them to
> alert-listeners.
>
> {noformat}
> "P2P message reader for 10.236.28.120(servername-removed):56152 shared
> unordered uid=9 port=41204" tid=0xd49 (in native) java.lang.Thread.State:
> RUNNABLE at sun.nio.ch.FileDispatcherImpl.write0(Native Method) at
> sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) at
> sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) at
> sun.nio.ch.IOUtil.write(IOUtil.java:51) at
> sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471) - locked
> java.lang.Object@24528b9b at
> org.apache.geode.internal.tcp.Connection.nioWriteFully(Connection.java:3291)
> - locked java.lang.Object@42a1a79b at
> org.apache.geode.internal.tcp.Connection.sendPreserialized(Connection.java:2527)
> at org.apache.geode.internal.tcp.MsgStreamer.realFlush(MsgStreamer.java:319)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:244)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:393)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:250)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:615)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.directChannelSend(GMSMembershipManager.java:1717)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.send(GMSMembershipManager.java:1898)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2878)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:2798)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2837)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1531)
> at
> org.apache.geode.internal.alerting.AlertMessaging.sendAlert(AlertMessaging.java:75)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender.sendAlertMessage(AlertAppender.java:188)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender.doAppend(AlertAppender.java:163)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender.lambda$append$0(AlertAppender.java:159)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender$$Lambda$168/1102181662.run(Unknown
> Source) at
> org.apache.geode.internal.alerting.AlertingAction.execute(AlertingAction.java:29)
> at
> org.apache.geode.internal.logging.log4j.AlertAppender.append(AlertAppender.java:159)
> at
> org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
> at
> org.apache.logging.log4j.core.config.
[jira] [Commented] (GEODE-8137) Implement loadService on JBossModuleService
[ https://issues.apache.org/jira/browse/GEODE-8137?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114174#comment-17114174 ] ASF subversion and git services commented on GEODE-8137: Commit e98d2a0f2ab3794c3e770bda0ad446e5ac4d8bd6 in geode's branch refs/heads/feature/GEODE-8067 from Patrick Johnson [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e98d2a0 ] GEODE-8137 - Implement loadService. (#5136) > Implement loadService on JBossModuleService > --- > > Key: GEODE-8137 > URL: https://issues.apache.org/jira/browse/GEODE-8137 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Implement loadService to load implementations of a given interface from JBoss > Modules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8146) Restore winrm-cli to latest from source
[ https://issues.apache.org/jira/browse/GEODE-8146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114168#comment-17114168 ] ASF subversion and git services commented on GEODE-8146: Commit f2392d0403a292f8e85c5d466329bce5f0d5b819 in geode's branch refs/heads/feature/GEODE-8067 from Robert Houghton [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f2392d0 ] GEODE-8146: use latest winrm in tools image (#5134) * Built cleanly in multistage build * Moved from python2 -> python3 * Pin concourse-pipeline resource Authored-by: Robert Houghton > Restore winrm-cli to latest from source > --- > > Key: GEODE-8146 > URL: https://issues.apache.org/jira/browse/GEODE-8146 > Project: Geode > Issue Type: Improvement > Components: ci, tests >Reporter: Robert Houghton >Priority: Major > Fix For: 1.14.0 > > > winrm-cli has updated to fix the bug causing GEODE-7788, as reported in > [their github|https://github.com/masterzen/winrm/issues/101] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8144) endpoint identification in servers is not working
[
https://issues.apache.org/jira/browse/GEODE-8144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114177#comment-17114177
]
ASF GitHub Bot commented on GEODE-8144:
---
pivotal-jbarrett commented on a change in pull request #5131:
URL: https://github.com/apache/geode/pull/5131#discussion_r429315845
##
File path:
geode-core/src/main/java/org/apache/geode/internal/net/SocketCreator.java
##
@@ -791,7 +792,19 @@ private boolean setServerNames(SSLParameters
modifiedParams, HostAndPort addr) {
return false;
}
-serverNames.add(new SNIHostName(addr.getHostName()));
+String hostName = addr.getHostName();
+if (this.sslConfig.doEndpointIdentification()
+&& InetAddressValidator.getInstance().isValid(hostName)) {
+ // endpoint validation typically uses a hostname in the sniServer
parameter that the handshake
+ // will compare against the subject alternative addresses in the
server's certificate. Here
+ // we attempt to get a hostname instead of the proffered numeric address
+ try {
+hostName = InetAddress.getByName(hostName).getCanonicalHostName();
Review comment:
As you mentioned offline, the same malicious entity could inject the IP
into their SAN and we would validate that. I don't think this code makes
anything any less secure from that standpoint so I am removing my block.
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
> endpoint identification in servers is not working
> -
>
> Key: GEODE-8144
> URL: https://issues.apache.org/jira/browse/GEODE-8144
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Priority: Major
>
> *update 5/20/2020*: this needs to be ported to 1.13 so it's picked up ASAP by
> TGF for VMs.
> If you enable endpoint identification in a server the server will not start.
> It will log exceptions like this:
>
> {noformat}
> javax.net.ssl.SSLHandshakeException: General SSLEngine problem
> at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1566)
> at
> sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:545)
> at
> sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1217)
> at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1185)
> at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:471)
> at
> org.apache.geode.internal.net.NioSslEngine.handshake(NioSslEngine.java:158)
> at
> org.apache.geode.internal.net.SocketCreator.handshakeSSLSocketChannel(SocketCreator.java:597)
> at
> org.apache.geode.internal.tcp.Connection.createIoFilter(Connection.java:1731)
> at org.apache.geode.internal.tcp.Connection.(Connection.java:1167)
> at
> org.apache.geode.internal.tcp.Connection.createSender(Connection.java:1004)
> at
> org.apache.geode.internal.tcp.ConnectionTable.handleNewPendingConnection(ConnectionTable.java:288)
> at
> org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:392)
> at
> org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:571)
> at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:800)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:451)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:268)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:510)
> 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.StartupOperation.sendStartupMessage(StartupOperation.java:74)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1623)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:361)
>
[jira] [Commented] (GEODE-7971) Gateway sender to deliver transaction events atomically to gateway receivers
[ https://issues.apache.org/jira/browse/GEODE-7971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114183#comment-17114183 ] ASF GitHub Bot commented on GEODE-7971: --- ladyVader commented on a change in pull request #4928: URL: https://github.com/apache/geode/pull/4928#discussion_r429320060 ## File path: geode-gfsh/src/main/java/org/apache/geode/management/internal/cli/commands/CreateGatewaySenderCommand.java ## @@ -75,6 +75,11 @@ public ResultModel createGatewaySender( mandatory = true, help = CliStrings.CREATE_GATEWAYSENDER__REMOTEDISTRIBUTEDSYSTEMID__HELP) Integer remoteDistributedSystemId, + @CliOption(key = CliStrings.CREATE_GATEWAYSENDER__GROUPTRANSACTIONEVENTS, + specifiedDefaultValue = "true", + unspecifiedDefaultValue = "false", + help = CliStrings.CREATE_GATEWAYSENDER__GROUPTRANSACTIONEVENTS__HELP) boolean groupTransactionEvents, + Review comment: Thanks for both the new Exception on misconfiguring the SerialGatewaySender with groupTransactionEvents enabled + dispatcherThreads > 1. In addition, I'm no longer seeing the data inconsistencies or hangs waiting for the primary gateway sender queue to drain. 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 > Gateway sender to deliver transaction events atomically to gateway receivers > > > Key: GEODE-7971 > URL: https://issues.apache.org/jira/browse/GEODE-7971 > Project: Geode > Issue Type: Improvement > Components: wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > The goal of this ticket is to implement the necessary changes in the gateway > sender to prevent that events belonging to the same transaction are spread > across different batches. In other words, to ensure that events from the same > transaction are sent inside the same batch. > This will be an optional feature on gateway senders to be enabled via a new > parameter (--group-transaction-events) and will be restricted to serial > gateway senders with just one dispatcher thread or to parallel gateway > senders. > Apart from the above restriction, grouping of events for a transaction inside > the same batch may only be attained if the regions to which the events belong > are replicated by the same set of gateway senders with the > --group-transaction-events flag enabled. If this condition is not met, the > events will be correctly delivered by the gateway senders but it will not be > guaranteed that all events will always be sent inside the same batch. > For more details see: > [https://cwiki.apache.org/confluence/display/GEODE/Gw+sender+to+deliver+transaction+events+atomically+to+receivers] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8174) JCAManagedConnection throws ConcurrentModificationExceptions
[
https://issues.apache.org/jira/browse/GEODE-8174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer reassigned GEODE-8174:
Assignee: Udo Kohlmeyer
> JCAManagedConnection throws ConcurrentModificationExceptions
> -
>
> Key: GEODE-8174
> URL: https://issues.apache.org/jira/browse/GEODE-8174
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Reporter: Udo Kohlmeyer
>Assignee: Udo Kohlmeyer
>Priority: Major
>
> {code:java}
> Caused by: java.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:920)
> ~[?:1.8.0]
> at java.util.ArrayList$Itr.next(ArrayList.java:870) ~[?:1.8.0]
> at
> org.apache.geode.internal.ra.spi.JCAManagedConnection.onClose(JCAManagedConnection.java:212)
> ~[geode-core-9.8.3.jar:?]
> at
> org.apache.geode.internal.ra.GFConnectionImpl.close(GFConnectionImpl.java:42)
> ~[geode-core-9.8.3.jar:?]
> at
> org.springframework.data.gemfire.config.annotation.support.AbstractGemFireAsLastResourceAspectSupport$GemFireConnectionHolder.lambda$close$0(AbstractGemFireAsLastResourceAspectSupport.java:561)
> ~[spring-data-gemfire-2.1.10.RELEASE.jar:2.1.10.RELEASE]
> at
> org.springframework.data.gemfire.config.annotation.support.AbstractGemFireAsLastResourceAspectSupport$GemFireConnectionHolder$$Lambda$970.1C3AB4F0.accept(Unknown
> Source) ~[?:?]
> at java.util.Optional.ifPresent(Optional.java:170) ~[?:1.8.0]
> {code}
> Under testing the JCAManagedConnection throws a CME.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-7254) ServerOperationException While performing a remote put
[ https://issues.apache.org/jira/browse/GEODE-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer reassigned GEODE-7254: Assignee: Udo Kohlmeyer > ServerOperationException While performing a remote put > -- > > Key: GEODE-7254 > URL: https://issues.apache.org/jira/browse/GEODE-7254 > Project: Geode > Issue Type: Bug > Components: client/server, configuration, core >Affects Versions: 1.8.0 >Reporter: rajesh >Assignee: Udo Kohlmeyer >Priority: Blocker > Attachments: iHubCacheLocatorProcess.log, iHubCacheServerProcess.log, > ihub.5296.RGOTETPF0T711Q.2019-09-30_20_44_40+0530.0.log, > meta-iHubCacheLocatorProcess-01.log, meta-iHubCacheServerProcess-02.log > > > Configuration: Locator and Server are running as different process using > peer to peer configuration. > while trying to insert a custom object in to a cache region using client > cache we are getting the following exception. > This occurs only when the Geode Locator/Server are started with log level set > to fine, finer, finest and all. > If the log level is set to severe, error, warning, info, config everything > works fine. > I am not sure if log level change has anything to do with put operation. I am > attaching the locator and server log files. > > Also we have recently upgraded the geode version from 1.1.0 to 1.8. we have > been using 1.1.0 for quite sometime without any major issues. upgraded to > 1.8 and no code changes were made but still getting this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7254) ServerOperationException While performing a remote put
[ https://issues.apache.org/jira/browse/GEODE-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer reassigned GEODE-7254: Assignee: (was: Udo Kohlmeyer) > ServerOperationException While performing a remote put > -- > > Key: GEODE-7254 > URL: https://issues.apache.org/jira/browse/GEODE-7254 > Project: Geode > Issue Type: Bug > Components: client/server, configuration, core >Affects Versions: 1.8.0 >Reporter: rajesh >Priority: Blocker > Attachments: iHubCacheLocatorProcess.log, iHubCacheServerProcess.log, > ihub.5296.RGOTETPF0T711Q.2019-09-30_20_44_40+0530.0.log, > meta-iHubCacheLocatorProcess-01.log, meta-iHubCacheServerProcess-02.log > > > Configuration: Locator and Server are running as different process using > peer to peer configuration. > while trying to insert a custom object in to a cache region using client > cache we are getting the following exception. > This occurs only when the Geode Locator/Server are started with log level set > to fine, finer, finest and all. > If the log level is set to severe, error, warning, info, config everything > works fine. > I am not sure if log level change has anything to do with put operation. I am > attaching the locator and server log files. > > Also we have recently upgraded the geode version from 1.1.0 to 1.8. we have > been using 1.1.0 for quite sometime without any major issues. upgraded to > 1.8 and no code changes were made but still getting this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8174) JCAManagedConnection throws ConcurrentModificationExceptions
Udo Kohlmeyer created GEODE-8174:
Summary: JCAManagedConnection throws
ConcurrentModificationExceptions
Key: GEODE-8174
URL: https://issues.apache.org/jira/browse/GEODE-8174
Project: Geode
Issue Type: Bug
Components: transactions
Reporter: Udo Kohlmeyer
{code:java}
Caused by: java.util.ConcurrentModificationException
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:920) ~[?:1.8.0]
at java.util.ArrayList$Itr.next(ArrayList.java:870) ~[?:1.8.0]
at
org.apache.geode.internal.ra.spi.JCAManagedConnection.onClose(JCAManagedConnection.java:212)
~[geode-core-9.8.3.jar:?]
at
org.apache.geode.internal.ra.GFConnectionImpl.close(GFConnectionImpl.java:42)
~[geode-core-9.8.3.jar:?]
at
org.springframework.data.gemfire.config.annotation.support.AbstractGemFireAsLastResourceAspectSupport$GemFireConnectionHolder.lambda$close$0(AbstractGemFireAsLastResourceAspectSupport.java:561)
~[spring-data-gemfire-2.1.10.RELEASE.jar:2.1.10.RELEASE]
at
org.springframework.data.gemfire.config.annotation.support.AbstractGemFireAsLastResourceAspectSupport$GemFireConnectionHolder$$Lambda$970.1C3AB4F0.accept(Unknown
Source) ~[?:?]
at java.util.Optional.ifPresent(Optional.java:170) ~[?:1.8.0]
{code}
Under testing the JCAManagedConnection throws a CME.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8174) JCAManagedConnection throws ConcurrentModificationExceptions
[
https://issues.apache.org/jira/browse/GEODE-8174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-8174:
-
Description:
{code:java}
Caused by: java.util.ConcurrentModificationException
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:920) ~[?:1.8.0]
at java.util.ArrayList$Itr.next(ArrayList.java:870) ~[?:1.8.0]
at
org.apache.geode.internal.ra.spi.JCAManagedConnection.onClose(JCAManagedConnection.java:212)
~[geode-core-9.8.3.jar:?]
at
org.apache.geode.internal.ra.GFConnectionImpl.close(GFConnectionImpl.java:42)
~[geode-core-9.8.3.jar:?]
at
org.springframework.data.gemfire.config.annotation.support.AbstractGemFireAsLastResourceAspectSupport$GemFireConnectionHolder.lambda$close$0(AbstractGemFireAsLastResourceAspectSupport.java:561)
~[spring-data-gemfire-2.1.10.RELEASE.jar:2.1.10.RELEASE]
at
org.springframework.data.gemfire.config.annotation.support.AbstractGemFireAsLastResourceAspectSupport$GemFireConnectionHolder$$Lambda$970.1C3AB4F0.accept(Unknown
Source) ~[?:?]
at java.util.Optional.ifPresent(Optional.java:170) ~[?:1.8.0]
{code}
Under testing the JCAManagedConnection throws a CME when trying to close the
connection.
was:
{code:java}
Caused by: java.util.ConcurrentModificationException
at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:920) ~[?:1.8.0]
at java.util.ArrayList$Itr.next(ArrayList.java:870) ~[?:1.8.0]
at
org.apache.geode.internal.ra.spi.JCAManagedConnection.onClose(JCAManagedConnection.java:212)
~[geode-core-9.8.3.jar:?]
at
org.apache.geode.internal.ra.GFConnectionImpl.close(GFConnectionImpl.java:42)
~[geode-core-9.8.3.jar:?]
at
org.springframework.data.gemfire.config.annotation.support.AbstractGemFireAsLastResourceAspectSupport$GemFireConnectionHolder.lambda$close$0(AbstractGemFireAsLastResourceAspectSupport.java:561)
~[spring-data-gemfire-2.1.10.RELEASE.jar:2.1.10.RELEASE]
at
org.springframework.data.gemfire.config.annotation.support.AbstractGemFireAsLastResourceAspectSupport$GemFireConnectionHolder$$Lambda$970.1C3AB4F0.accept(Unknown
Source) ~[?:?]
at java.util.Optional.ifPresent(Optional.java:170) ~[?:1.8.0]
{code}
Under testing the JCAManagedConnection throws a CME.
> JCAManagedConnection throws ConcurrentModificationExceptions
> -
>
> Key: GEODE-8174
> URL: https://issues.apache.org/jira/browse/GEODE-8174
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Reporter: Udo Kohlmeyer
>Assignee: Udo Kohlmeyer
>Priority: Major
>
> {code:java}
> Caused by: java.util.ConcurrentModificationException
> at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:920)
> ~[?:1.8.0]
> at java.util.ArrayList$Itr.next(ArrayList.java:870) ~[?:1.8.0]
> at
> org.apache.geode.internal.ra.spi.JCAManagedConnection.onClose(JCAManagedConnection.java:212)
> ~[geode-core-9.8.3.jar:?]
> at
> org.apache.geode.internal.ra.GFConnectionImpl.close(GFConnectionImpl.java:42)
> ~[geode-core-9.8.3.jar:?]
> at
> org.springframework.data.gemfire.config.annotation.support.AbstractGemFireAsLastResourceAspectSupport$GemFireConnectionHolder.lambda$close$0(AbstractGemFireAsLastResourceAspectSupport.java:561)
> ~[spring-data-gemfire-2.1.10.RELEASE.jar:2.1.10.RELEASE]
> at
> org.springframework.data.gemfire.config.annotation.support.AbstractGemFireAsLastResourceAspectSupport$GemFireConnectionHolder$$Lambda$970.1C3AB4F0.accept(Unknown
> Source) ~[?:?]
> at java.util.Optional.ifPresent(Optional.java:170) ~[?:1.8.0]
> {code}
> Under testing the JCAManagedConnection throws a CME when trying to close the
> connection.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8148) Implement unloadModule in JBossModuleService
[ https://issues.apache.org/jira/browse/GEODE-8148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114235#comment-17114235 ] ASF GitHub Bot commented on GEODE-8148: --- yozaner1324 closed pull request #5143: URL: https://github.com/apache/geode/pull/5143 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 > Implement unloadModule in JBossModuleService > > > Key: GEODE-8148 > URL: https://issues.apache.org/jira/browse/GEODE-8148 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > unloadModule will unload JBoss modules previously loaded by loadModule. > unloadModule takes a String that represents the name of the module to find > and unload. It should return true when successfully unloading a module and > false if it cannot find or cannot unload the specified module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8127) redis function+delta may not always execute function on primary
[ https://issues.apache.org/jira/browse/GEODE-8127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114236#comment-17114236 ] ASF GitHub Bot commented on GEODE-8127: --- dschneider-pivotal merged pull request #5133: URL: https://github.com/apache/geode/pull/5133 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 function+delta may not always execute function on primary > --- > > Key: GEODE-8127 > URL: https://issues.apache.org/jira/browse/GEODE-8127 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > > The redis use of regions depends on the code that will modify the region that > is storing redis data, to always execute on the primary. It thought it was > accomplishing this by marking the function as "optimizeForWrite=true" and by > routing the function to the node with the bucket using "withFilter(key)". > This works most of the time. But in some cases the function executes on a > redundant copy. It looks like what is happening is that at the time the > function is dispatched it has one idea of who the primary is and sends the > function to that node. But before it executes the primary moves from this > node to another that is doing redundancy recovery. Then when our function > finally does a "put" on the localDataSet it ends up being a remote operation > that is sent to the other node. > If our redis function could get a lock that prevents the bucket primary > status from changing (see BucketRegion doLockForPrimary) and then check to > see if we are the primary (if not throw an exception that causes the function > sender to retry (see BucketMovedException) otherwise execute the function > and at the end release the lock (see BucketRegion doUnlockForPrimary). > We could enable this with a new method added to Function (much like the > existing isHA and optimizeForWrite). This new method could be > executeOnPrimary and default to false (adding a default method to the > Function interface will not cause backwards compatibility issues unless a > current class that implements Function already had added a method named > "executeOnPrimary"). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8127) redis function+delta may not always execute function on primary
[ https://issues.apache.org/jira/browse/GEODE-8127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-8127. - Fix Version/s: 1.14.0 Resolution: Fixed > redis function+delta may not always execute function on primary > --- > > Key: GEODE-8127 > URL: https://issues.apache.org/jira/browse/GEODE-8127 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.14.0 > > > The redis use of regions depends on the code that will modify the region that > is storing redis data, to always execute on the primary. It thought it was > accomplishing this by marking the function as "optimizeForWrite=true" and by > routing the function to the node with the bucket using "withFilter(key)". > This works most of the time. But in some cases the function executes on a > redundant copy. It looks like what is happening is that at the time the > function is dispatched it has one idea of who the primary is and sends the > function to that node. But before it executes the primary moves from this > node to another that is doing redundancy recovery. Then when our function > finally does a "put" on the localDataSet it ends up being a remote operation > that is sent to the other node. > If our redis function could get a lock that prevents the bucket primary > status from changing (see BucketRegion doLockForPrimary) and then check to > see if we are the primary (if not throw an exception that causes the function > sender to retry (see BucketMovedException) otherwise execute the function > and at the end release the lock (see BucketRegion doUnlockForPrimary). > We could enable this with a new method added to Function (much like the > existing isHA and optimizeForWrite). This new method could be > executeOnPrimary and default to false (adding a default method to the > Function interface will not cause backwards compatibility issues unless a > current class that implements Function already had added a method named > "executeOnPrimary"). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8127) redis function+delta may not always execute function on primary
[ https://issues.apache.org/jira/browse/GEODE-8127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114237#comment-17114237 ] ASF subversion and git services commented on GEODE-8127: Commit e0cbd78149d520f77e896426b691c217d3afcfb4 in geode's branch refs/heads/develop from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e0cbd78 ] GEODE-8127: ensure that redis function executes on primary (#5133) The redis function now either throws an exception because it is not on the primary or locks the primary for the duration of the function. Co-authored-by: Jens Deppe Co-authored-by: Sarah > redis function+delta may not always execute function on primary > --- > > Key: GEODE-8127 > URL: https://issues.apache.org/jira/browse/GEODE-8127 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.14.0 > > > The redis use of regions depends on the code that will modify the region that > is storing redis data, to always execute on the primary. It thought it was > accomplishing this by marking the function as "optimizeForWrite=true" and by > routing the function to the node with the bucket using "withFilter(key)". > This works most of the time. But in some cases the function executes on a > redundant copy. It looks like what is happening is that at the time the > function is dispatched it has one idea of who the primary is and sends the > function to that node. But before it executes the primary moves from this > node to another that is doing redundancy recovery. Then when our function > finally does a "put" on the localDataSet it ends up being a remote operation > that is sent to the other node. > If our redis function could get a lock that prevents the bucket primary > status from changing (see BucketRegion doLockForPrimary) and then check to > see if we are the primary (if not throw an exception that causes the function > sender to retry (see BucketMovedException) otherwise execute the function > and at the end release the lock (see BucketRegion doUnlockForPrimary). > We could enable this with a new method added to Function (much like the > existing isHA and optimizeForWrite). This new method could be > executeOnPrimary and default to false (adding a default method to the > Function interface will not cause backwards compatibility issues unless a > current class that implements Function already had added a method named > "executeOnPrimary"). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8148) Implement unloadModule in JBossModuleService
[ https://issues.apache.org/jira/browse/GEODE-8148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114239#comment-17114239 ] ASF GitHub Bot commented on GEODE-8148: --- yozaner1324 closed pull request #5150: URL: https://github.com/apache/geode/pull/5150 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 > Implement unloadModule in JBossModuleService > > > Key: GEODE-8148 > URL: https://issues.apache.org/jira/browse/GEODE-8148 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > unloadModule will unload JBoss modules previously loaded by loadModule. > unloadModule takes a String that represents the name of the module to find > and unload. It should return true when successfully unloading a module and > false if it cannot find or cannot unload the specified module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8148) Implement unloadModule in JBossModuleService
[ https://issues.apache.org/jira/browse/GEODE-8148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114238#comment-17114238 ] ASF GitHub Bot commented on GEODE-8148: --- yozaner1324 opened a new pull request #5150: URL: https://github.com/apache/geode/pull/5150 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 > Implement unloadModule in JBossModuleService > > > Key: GEODE-8148 > URL: https://issues.apache.org/jira/browse/GEODE-8148 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > unloadModule will unload JBoss modules previously loaded by loadModule. > unloadModule takes a String that represents the name of the module to find > and unload. It should return true when successfully unloading a module and > false if it cannot find or cannot unload the specified module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8148) Implement unloadModule in JBossModuleService
[ https://issues.apache.org/jira/browse/GEODE-8148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114241#comment-17114241 ] ASF GitHub Bot commented on GEODE-8148: --- yozaner1324 opened a new pull request #5151: URL: https://github.com/apache/geode/pull/5151 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 > Implement unloadModule in JBossModuleService > > > Key: GEODE-8148 > URL: https://issues.apache.org/jira/browse/GEODE-8148 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > unloadModule will unload JBoss modules previously loaded by loadModule. > unloadModule takes a String that represents the name of the module to find > and unload. It should return true when successfully unloading a module and > false if it cannot find or cannot unload the specified module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8171) javadoc for putAll need to have accurate exception
[ https://issues.apache.org/jira/browse/GEODE-8171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114242#comment-17114242 ] ASF GitHub Bot commented on GEODE-8171: --- gesterzhou commented on a change in pull request #5147: URL: https://github.com/apache/geode/pull/5147#discussion_r429359435 ## File path: geode-core/src/main/java/org/apache/geode/cache/Region.java ## @@ -1359,10 +1359,30 @@ Object selectValue(String queryPredicate) throws FunctionDomainException, TypeMi * in the specified map. This operation will be distributed to other caches if the scope is not * Scope.LOCAL. * - * @param map the key/value pairs to put in this region. - * @since GemFire 5.0 + * If any exception is thrown due to this call, it can imply that there may have been a partial + * update performed on the region. Use putAll from within a transaction to get atomicity with all + * the Review comment: fixed. 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 > javadoc for putAll need to have accurate exception > --- > > Key: GEODE-8171 > URL: https://issues.apache.org/jira/browse/GEODE-8171 > Project: Geode > Issue Type: Improvement >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI > > Both the javadocs and the user guide need a more accurate description of the > exceptions that can be thrown when an app calls putAll(). > Correct the javadocs to list all exceptions that may be thrown. > Add a code fragment example to the user guide (and to the javadocs, if > appropriate) that shows a best practice for an app to call putAll() and > handle exceptions. > Describe what might cause the exceptions and let users know how to adjust > cluster configuration mitigate the exceptions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8175) Remove unsupported redis commands that use old data model
Darrel Schneider created GEODE-8175: --- Summary: Remove unsupported redis commands that use old data model Key: GEODE-8175 URL: https://issues.apache.org/jira/browse/GEODE-8175 Project: Geode Issue Type: Improvement Components: redis Reporter: Darrel Schneider Remove the code corresponding to the commands that are not using the new data model this includes: Sorted Sets Geo Lists HyperLogLog Transaction Commands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8175) Remove unsupported redis commands that use old data model
[ https://issues.apache.org/jira/browse/GEODE-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reassigned GEODE-8175: --- Assignee: Darrel Schneider > Remove unsupported redis commands that use old data model > - > > Key: GEODE-8175 > URL: https://issues.apache.org/jira/browse/GEODE-8175 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > > Remove the code corresponding to the commands that are not using the new data > model this includes: > Sorted Sets > Geo > Lists > HyperLogLog > Transaction Commands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8148) Implement unloadModule in JBossModuleService
[ https://issues.apache.org/jira/browse/GEODE-8148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114284#comment-17114284 ] ASF GitHub Bot commented on GEODE-8148: --- lgtm-com[bot] commented on pull request #5150: URL: https://github.com/apache/geode/pull/5150#issuecomment-632827303 This pull request **introduces 1 alert** when merging 58b9b877d91e1f0fe32234c70fd1d5aa66d127e5 into e0cbd78149d520f77e896426b691c217d3afcfb4 - [view on LGTM.com](https://lgtm.com/projects/g/apache/geode/rev/pr-46e35a3ed5e37e301093a89a07551440884722af) **new alerts:** * 1 for Potential input resource leak 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 > Implement unloadModule in JBossModuleService > > > Key: GEODE-8148 > URL: https://issues.apache.org/jira/browse/GEODE-8148 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > unloadModule will unload JBoss modules previously loaded by loadModule. > unloadModule takes a String that represents the name of the module to find > and unload. It should return true when successfully unloading a module and > false if it cannot find or cannot unload the specified module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8176) CI Failure: ClientServerMiscBCDUnitTest > testPingWrongServer[1]
Donal Evans created GEODE-8176:
--
Summary: CI Failure: ClientServerMiscBCDUnitTest >
testPingWrongServer[1]
Key: GEODE-8176
URL: https://issues.apache.org/jira/browse/GEODE-8176
Project: Geode
Issue Type: Bug
Reporter: Donal Evans
Failed in
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK8/builds/192#A
{noformat}
org.apache.geode.internal.cache.tier.sockets.ClientServerMiscBCDUnitTest >
testPingWrongServer[1] FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.tier.sockets.ClientServerMiscDUnitTestBase$$Lambda$310/201549247.run
in VM 3 running on Host c0a964e32781 with 5 VMs
Caused by:
org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
{noformat}
I ran the test 200 times locally with no failure, so this is possibly just a
blip.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8138) Improve semantics of the redis-port option
[
https://issues.apache.org/jira/browse/GEODE-8138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114362#comment-17114362
]
ASF GitHub Bot commented on GEODE-8138:
---
dschneider-pivotal merged pull request #5142:
URL: https://github.com/apache/geode/pull/5142
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
> Improve semantics of the redis-port option
> --
>
> Key: GEODE-8138
> URL: https://issues.apache.org/jira/browse/GEODE-8138
> Project: Geode
> Issue Type: New Feature
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
>
> Currently when {{redis-port=0}} the Redis service is not enabled. Recently we
> added the ability to pick an ephemeral port by setting {{redis-port=-1}}.
> However the typical norm is that a port of {{0}} should indicate the use of
> an ephemeral port.
> If we allow this then we need a different way of enabling/disabling the
> service.
> One possibility is that the service is disabled when {{redis-port=-1}}. (or <
> 0). However anyone already setting the property to {{0}} would then suddenly
> activate the service.
> Another possibility is to add a new Geode property to explicitly
> enable/disable the service. (Off by default). That way users, switching to
> this version, would still experience the same behavior regardless of their
> {{redis-port}} setting.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8138) Improve semantics of the redis-port option
[
https://issues.apache.org/jira/browse/GEODE-8138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114363#comment-17114363
]
ASF subversion and git services commented on GEODE-8138:
Commit d47e0733bc77d4863a013442e45aaad3ec990947 in geode's branch
refs/heads/develop from Sarah Abbey
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=d47e073 ]
GEODE-8138: Improve semantics of the redis-port option (#5142)
> Improve semantics of the redis-port option
> --
>
> Key: GEODE-8138
> URL: https://issues.apache.org/jira/browse/GEODE-8138
> Project: Geode
> Issue Type: New Feature
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
>
> Currently when {{redis-port=0}} the Redis service is not enabled. Recently we
> added the ability to pick an ephemeral port by setting {{redis-port=-1}}.
> However the typical norm is that a port of {{0}} should indicate the use of
> an ephemeral port.
> If we allow this then we need a different way of enabling/disabling the
> service.
> One possibility is that the service is disabled when {{redis-port=-1}}. (or <
> 0). However anyone already setting the property to {{0}} would then suddenly
> activate the service.
> Another possibility is to add a new Geode property to explicitly
> enable/disable the service. (Off by default). That way users, switching to
> this version, would still experience the same behavior regardless of their
> {{redis-port}} setting.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8138) Improve semantics of the redis-port option
[
https://issues.apache.org/jira/browse/GEODE-8138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-8138.
-
Fix Version/s: 1.14.0
Resolution: Fixed
> Improve semantics of the redis-port option
> --
>
> Key: GEODE-8138
> URL: https://issues.apache.org/jira/browse/GEODE-8138
> Project: Geode
> Issue Type: New Feature
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
> Fix For: 1.14.0
>
>
> Currently when {{redis-port=0}} the Redis service is not enabled. Recently we
> added the ability to pick an ephemeral port by setting {{redis-port=-1}}.
> However the typical norm is that a port of {{0}} should indicate the use of
> an ephemeral port.
> If we allow this then we need a different way of enabling/disabling the
> service.
> One possibility is that the service is disabled when {{redis-port=-1}}. (or <
> 0). However anyone already setting the property to {{0}} would then suddenly
> activate the service.
> Another possibility is to add a new Geode property to explicitly
> enable/disable the service. (Off by default). That way users, switching to
> this version, would still experience the same behavior regardless of their
> {{redis-port}} setting.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8148) Implement unloadModule in JBossModuleService
[ https://issues.apache.org/jira/browse/GEODE-8148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114376#comment-17114376 ] ASF GitHub Bot commented on GEODE-8148: --- kohlmu-pivotal merged pull request #5151: URL: https://github.com/apache/geode/pull/5151 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 > Implement unloadModule in JBossModuleService > > > Key: GEODE-8148 > URL: https://issues.apache.org/jira/browse/GEODE-8148 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > unloadModule will unload JBoss modules previously loaded by loadModule. > unloadModule takes a String that represents the name of the module to find > and unload. It should return true when successfully unloading a module and > false if it cannot find or cannot unload the specified module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8148) Implement unloadModule in JBossModuleService
[ https://issues.apache.org/jira/browse/GEODE-8148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114377#comment-17114377 ] ASF subversion and git services commented on GEODE-8148: Commit fa9a0747a51406916c8e4e0783de493b7ecef75f in geode's branch refs/heads/feature/GEODE-8067 from Patrick Johnson [ https://gitbox.apache.org/repos/asf?p=geode.git;h=fa9a074 ] GEODE-8148 - Implement unloadModule. (#5151) > Implement unloadModule in JBossModuleService > > > Key: GEODE-8148 > URL: https://issues.apache.org/jira/browse/GEODE-8148 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > unloadModule will unload JBoss modules previously loaded by loadModule. > unloadModule takes a String that represents the name of the module to find > and unload. It should return true when successfully unloading a module and > false if it cannot find or cannot unload the specified module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8168) Redis pipelined command responses can be corrupted
[ https://issues.apache.org/jira/browse/GEODE-8168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114388#comment-17114388 ] ASF GitHub Bot commented on GEODE-8168: --- jdeppe-pivotal merged pull request #5145: URL: https://github.com/apache/geode/pull/5145 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 pipelined command responses can be corrupted > -- > > Key: GEODE-8168 > URL: https://issues.apache.org/jira/browse/GEODE-8168 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > > Redis clients can send pipelined commands where commands are sent as batches. > Responses are expected in the same order as the commands. > Since we switched the responses of PUBLISH commands to be asynchronous, now > command responses can be interleaved incorrectly which results in clients to > break. For example the client is expecting a response from PUBLISH but, > instead, gets a response to HMSET. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8168) Redis pipelined command responses can be corrupted
[ https://issues.apache.org/jira/browse/GEODE-8168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114389#comment-17114389 ] ASF subversion and git services commented on GEODE-8168: Commit 0a7f8ae79ba89cb4f092e15e9d36d7020b6ace95 in geode's branch refs/heads/develop from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0a7f8ae ] GEODE-8168: Redis pipelined command responses can be corrupted (#5145) > Redis pipelined command responses can be corrupted > -- > > Key: GEODE-8168 > URL: https://issues.apache.org/jira/browse/GEODE-8168 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > > Redis clients can send pipelined commands where commands are sent as batches. > Responses are expected in the same order as the commands. > Since we switched the responses of PUBLISH commands to be asynchronous, now > command responses can be interleaved incorrectly which results in clients to > break. For example the client is expecting a response from PUBLISH but, > instead, gets a response to HMSET. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8151) Convert all redis commands to return RedisResponse
[ https://issues.apache.org/jira/browse/GEODE-8151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114391#comment-17114391 ] ASF subversion and git services commented on GEODE-8151: Commit af1ea6d2ff563db786abf773f572a9a09b0858d0 in geode's branch refs/heads/develop from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=af1ea6d ] GEODE-8151: Convert hash commands to return RedisResponse (#5140) > Convert all redis commands to return RedisResponse > -- > > Key: GEODE-8151 > URL: https://issues.apache.org/jira/browse/GEODE-8151 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > > This is an ongoing effort to refactor all redis commands to return > RedisResponse -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8151) Convert all redis commands to return RedisResponse
[ https://issues.apache.org/jira/browse/GEODE-8151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114390#comment-17114390 ] ASF GitHub Bot commented on GEODE-8151: --- jdeppe-pivotal merged pull request #5140: URL: https://github.com/apache/geode/pull/5140 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 > Convert all redis commands to return RedisResponse > -- > > Key: GEODE-8151 > URL: https://issues.apache.org/jira/browse/GEODE-8151 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > > This is an ongoing effort to refactor all redis commands to return > RedisResponse -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8177) Change Redis Rename Functions to Make use of Striped Executor
John Hutchison created GEODE-8177: - Summary: Change Redis Rename Functions to Make use of Striped Executor Key: GEODE-8177 URL: https://issues.apache.org/jira/browse/GEODE-8177 Project: Geode Issue Type: Improvement Reporter: John Hutchison -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8178) CI Failure: EnsurePrimaryStaysPutDUnitTest > primaryRemainsWhileLocalFunctionExecutes
Donal Evans created GEODE-8178: -- Summary: CI Failure: EnsurePrimaryStaysPutDUnitTest > primaryRemainsWhileLocalFunctionExecutes Key: GEODE-8178 URL: https://issues.apache.org/jira/browse/GEODE-8178 Project: Geode Issue Type: Bug Components: redis Reporter: Donal Evans Test failed in this run: https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/195#A Was unable to reproduce the failure in 100 runs locally, so seems like a very rare flaky failure. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8178) CI Failure: EnsurePrimaryStaysPutDUnitTest > primaryRemainsWhileLocalFunctionExecutes
[ https://issues.apache.org/jira/browse/GEODE-8178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-8178: --- Labels: flaky (was: ) > CI Failure: EnsurePrimaryStaysPutDUnitTest > > primaryRemainsWhileLocalFunctionExecutes > - > > Key: GEODE-8178 > URL: https://issues.apache.org/jira/browse/GEODE-8178 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Donal Evans >Priority: Major > Labels: flaky > > Test failed in this run: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/195#A > Was unable to reproduce the failure in 100 runs locally, so seems like a very > rare flaky failure. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (GEODE-8127) redis function+delta may not always execute function on primary
[ https://issues.apache.org/jira/browse/GEODE-8127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reopened GEODE-8127: - > redis function+delta may not always execute function on primary > --- > > Key: GEODE-8127 > URL: https://issues.apache.org/jira/browse/GEODE-8127 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.14.0 > > > The redis use of regions depends on the code that will modify the region that > is storing redis data, to always execute on the primary. It thought it was > accomplishing this by marking the function as "optimizeForWrite=true" and by > routing the function to the node with the bucket using "withFilter(key)". > This works most of the time. But in some cases the function executes on a > redundant copy. It looks like what is happening is that at the time the > function is dispatched it has one idea of who the primary is and sends the > function to that node. But before it executes the primary moves from this > node to another that is doing redundancy recovery. Then when our function > finally does a "put" on the localDataSet it ends up being a remote operation > that is sent to the other node. > If our redis function could get a lock that prevents the bucket primary > status from changing (see BucketRegion doLockForPrimary) and then check to > see if we are the primary (if not throw an exception that causes the function > sender to retry (see BucketMovedException) otherwise execute the function > and at the end release the lock (see BucketRegion doUnlockForPrimary). > We could enable this with a new method added to Function (much like the > existing isHA and optimizeForWrite). This new method could be > executeOnPrimary and default to false (adding a default method to the > Function interface will not cause backwards compatibility issues unless a > current class that implements Function already had added a method named > "executeOnPrimary"). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8127) redis function+delta may not always execute function on primary
[
https://issues.apache.org/jira/browse/GEODE-8127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114443#comment-17114443
]
Darrel Schneider commented on GEODE-8127:
-
The test for this turned out to be flakey. It sometimes fails with:
{noformat}
org.apache.geode.redis.EnsurePrimaryStaysPutDUnitTest >
primaryRemainsWhileLocalFunctionExecutes FAILED
java.lang.AssertionError: Suspicious strings were written to the log during
this run.
Fix the strings or use IgnoredException.addIgnoredException to ignore.
---
Found suspect string in log4j at line 2044
[error 2020/05/22 20:06:02.065 GMT tid=216]
Member is not primary.
{noformat}
> redis function+delta may not always execute function on primary
> ---
>
> Key: GEODE-8127
> URL: https://issues.apache.org/jira/browse/GEODE-8127
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Fix For: 1.14.0
>
>
> The redis use of regions depends on the code that will modify the region that
> is storing redis data, to always execute on the primary. It thought it was
> accomplishing this by marking the function as "optimizeForWrite=true" and by
> routing the function to the node with the bucket using "withFilter(key)".
> This works most of the time. But in some cases the function executes on a
> redundant copy. It looks like what is happening is that at the time the
> function is dispatched it has one idea of who the primary is and sends the
> function to that node. But before it executes the primary moves from this
> node to another that is doing redundancy recovery. Then when our function
> finally does a "put" on the localDataSet it ends up being a remote operation
> that is sent to the other node.
> If our redis function could get a lock that prevents the bucket primary
> status from changing (see BucketRegion doLockForPrimary) and then check to
> see if we are the primary (if not throw an exception that causes the function
> sender to retry (see BucketMovedException) otherwise execute the function
> and at the end release the lock (see BucketRegion doUnlockForPrimary).
> We could enable this with a new method added to Function (much like the
> existing isHA and optimizeForWrite). This new method could be
> executeOnPrimary and default to false (adding a default method to the
> Function interface will not cause backwards compatibility issues unless a
> current class that implements Function already had added a method named
> "executeOnPrimary").
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8178) CI Failure: EnsurePrimaryStaysPutDUnitTest > primaryRemainsWhileLocalFunctionExecutes
[
https://issues.apache.org/jira/browse/GEODE-8178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-8178:
---
Description:
Suspect strings logged in test:
{noformat}
org.apache.geode.redis.EnsurePrimaryStaysPutDUnitTest >
primaryRemainsWhileLocalFunctionExecutes FAILED
java.lang.AssertionError: Suspicious strings were written to the log during
this run.
Fix the strings or use IgnoredException.addIgnoredException to ignore.
---
Found suspect string in log4j at line 2044
[error 2020/05/22 20:06:02.065 GMT tid=216]
Member is not primary.
{noformat}
Test failed in this run:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/195#A
Was unable to reproduce the failure in 100 runs locally, so seems like a very
rare flaky failure.
was:
Test failed in this run:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/195#A
Was unable to reproduce the failure in 100 runs locally, so seems like a very
rare flaky failure.
> CI Failure: EnsurePrimaryStaysPutDUnitTest >
> primaryRemainsWhileLocalFunctionExecutes
> -
>
> Key: GEODE-8178
> URL: https://issues.apache.org/jira/browse/GEODE-8178
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Donal Evans
>Priority: Major
> Labels: flaky
>
> Suspect strings logged in test:
> {noformat}
> org.apache.geode.redis.EnsurePrimaryStaysPutDUnitTest >
> primaryRemainsWhileLocalFunctionExecutes FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 2044
> [error 2020/05/22 20:06:02.065 GMT
> tid=216] Member is not primary.
> {noformat}
> Test failed in this run:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/195#A
> Was unable to reproduce the failure in 100 runs locally, so seems like a very
> rare flaky failure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8127) redis function+delta may not always execute function on primary
[ https://issues.apache.org/jira/browse/GEODE-8127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114445#comment-17114445 ] ASF GitHub Bot commented on GEODE-8127: --- dschneider-pivotal opened a new pull request #5153: URL: https://github.com/apache/geode/pull/5153 This reverts commit e0cbd78149d520f77e896426b691c217d3afcfb4. 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 function+delta may not always execute function on primary > --- > > Key: GEODE-8127 > URL: https://issues.apache.org/jira/browse/GEODE-8127 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.14.0 > > > The redis use of regions depends on the code that will modify the region that > is storing redis data, to always execute on the primary. It thought it was > accomplishing this by marking the function as "optimizeForWrite=true" and by > routing the function to the node with the bucket using "withFilter(key)". > This works most of the time. But in some cases the function executes on a > redundant copy. It looks like what is happening is that at the time the > function is dispatched it has one idea of who the primary is and sends the > function to that node. But before it executes the primary moves from this > node to another that is doing redundancy recovery. Then when our function > finally does a "put" on the localDataSet it ends up being a remote operation > that is sent to the other node. > If our redis function could get a lock that prevents the bucket primary > status from changing (see BucketRegion doLockForPrimary) and then check to > see if we are the primary (if not throw an exception that causes the function > sender to retry (see BucketMovedException) otherwise execute the function > and at the end release the lock (see BucketRegion doUnlockForPrimary). > We could enable this with a new method added to Function (much like the > existing isHA and optimizeForWrite). This new method could be > executeOnPrimary and default to false (adding a default method to the > Function interface will not cause backwards compatibility issues unless a > current class that implements Function already had added a method named > "executeOnPrimary"). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8127) redis function+delta may not always execute function on primary
[ https://issues.apache.org/jira/browse/GEODE-8127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114446#comment-17114446 ] Darrel Schneider commented on GEODE-8127: - See: https://issues.apache.org/jira/browse/GEODE-8178 > redis function+delta may not always execute function on primary > --- > > Key: GEODE-8127 > URL: https://issues.apache.org/jira/browse/GEODE-8127 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.14.0 > > > The redis use of regions depends on the code that will modify the region that > is storing redis data, to always execute on the primary. It thought it was > accomplishing this by marking the function as "optimizeForWrite=true" and by > routing the function to the node with the bucket using "withFilter(key)". > This works most of the time. But in some cases the function executes on a > redundant copy. It looks like what is happening is that at the time the > function is dispatched it has one idea of who the primary is and sends the > function to that node. But before it executes the primary moves from this > node to another that is doing redundancy recovery. Then when our function > finally does a "put" on the localDataSet it ends up being a remote operation > that is sent to the other node. > If our redis function could get a lock that prevents the bucket primary > status from changing (see BucketRegion doLockForPrimary) and then check to > see if we are the primary (if not throw an exception that causes the function > sender to retry (see BucketMovedException) otherwise execute the function > and at the end release the lock (see BucketRegion doUnlockForPrimary). > We could enable this with a new method added to Function (much like the > existing isHA and optimizeForWrite). This new method could be > executeOnPrimary and default to false (adding a default method to the > Function interface will not cause backwards compatibility issues unless a > current class that implements Function already had added a method named > "executeOnPrimary"). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8127) redis function+delta may not always execute function on primary
[ https://issues.apache.org/jira/browse/GEODE-8127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114449#comment-17114449 ] ASF GitHub Bot commented on GEODE-8127: --- dschneider-pivotal merged pull request #5153: URL: https://github.com/apache/geode/pull/5153 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 function+delta may not always execute function on primary > --- > > Key: GEODE-8127 > URL: https://issues.apache.org/jira/browse/GEODE-8127 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.14.0 > > > The redis use of regions depends on the code that will modify the region that > is storing redis data, to always execute on the primary. It thought it was > accomplishing this by marking the function as "optimizeForWrite=true" and by > routing the function to the node with the bucket using "withFilter(key)". > This works most of the time. But in some cases the function executes on a > redundant copy. It looks like what is happening is that at the time the > function is dispatched it has one idea of who the primary is and sends the > function to that node. But before it executes the primary moves from this > node to another that is doing redundancy recovery. Then when our function > finally does a "put" on the localDataSet it ends up being a remote operation > that is sent to the other node. > If our redis function could get a lock that prevents the bucket primary > status from changing (see BucketRegion doLockForPrimary) and then check to > see if we are the primary (if not throw an exception that causes the function > sender to retry (see BucketMovedException) otherwise execute the function > and at the end release the lock (see BucketRegion doUnlockForPrimary). > We could enable this with a new method added to Function (much like the > existing isHA and optimizeForWrite). This new method could be > executeOnPrimary and default to false (adding a default method to the > Function interface will not cause backwards compatibility issues unless a > current class that implements Function already had added a method named > "executeOnPrimary"). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8127) redis function+delta may not always execute function on primary
[ https://issues.apache.org/jira/browse/GEODE-8127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114450#comment-17114450 ] ASF subversion and git services commented on GEODE-8127: Commit f243c4d99e1a223af0a3134d6a423b972195c507 in geode's branch refs/heads/develop from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f243c4d ] Revert GEODE-8127: the test is flakey (#5153) * Revert "GEODE-8127: ensure that redis function executes on primary (#5133)" This reverts commit e0cbd78149d520f77e896426b691c217d3afcfb4. The new test added in it was failing intermittently. See: GEODE-8178 > redis function+delta may not always execute function on primary > --- > > Key: GEODE-8127 > URL: https://issues.apache.org/jira/browse/GEODE-8127 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.14.0 > > > The redis use of regions depends on the code that will modify the region that > is storing redis data, to always execute on the primary. It thought it was > accomplishing this by marking the function as "optimizeForWrite=true" and by > routing the function to the node with the bucket using "withFilter(key)". > This works most of the time. But in some cases the function executes on a > redundant copy. It looks like what is happening is that at the time the > function is dispatched it has one idea of who the primary is and sends the > function to that node. But before it executes the primary moves from this > node to another that is doing redundancy recovery. Then when our function > finally does a "put" on the localDataSet it ends up being a remote operation > that is sent to the other node. > If our redis function could get a lock that prevents the bucket primary > status from changing (see BucketRegion doLockForPrimary) and then check to > see if we are the primary (if not throw an exception that causes the function > sender to retry (see BucketMovedException) otherwise execute the function > and at the end release the lock (see BucketRegion doUnlockForPrimary). > We could enable this with a new method added to Function (much like the > existing isHA and optimizeForWrite). This new method could be > executeOnPrimary and default to false (adding a default method to the > Function interface will not cause backwards compatibility issues unless a > current class that implements Function already had added a method named > "executeOnPrimary"). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8127) redis function+delta may not always execute function on primary
[ https://issues.apache.org/jira/browse/GEODE-8127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114451#comment-17114451 ] ASF subversion and git services commented on GEODE-8127: Commit f243c4d99e1a223af0a3134d6a423b972195c507 in geode's branch refs/heads/develop from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f243c4d ] Revert GEODE-8127: the test is flakey (#5153) * Revert "GEODE-8127: ensure that redis function executes on primary (#5133)" This reverts commit e0cbd78149d520f77e896426b691c217d3afcfb4. The new test added in it was failing intermittently. See: GEODE-8178 > redis function+delta may not always execute function on primary > --- > > Key: GEODE-8127 > URL: https://issues.apache.org/jira/browse/GEODE-8127 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.14.0 > > > The redis use of regions depends on the code that will modify the region that > is storing redis data, to always execute on the primary. It thought it was > accomplishing this by marking the function as "optimizeForWrite=true" and by > routing the function to the node with the bucket using "withFilter(key)". > This works most of the time. But in some cases the function executes on a > redundant copy. It looks like what is happening is that at the time the > function is dispatched it has one idea of who the primary is and sends the > function to that node. But before it executes the primary moves from this > node to another that is doing redundancy recovery. Then when our function > finally does a "put" on the localDataSet it ends up being a remote operation > that is sent to the other node. > If our redis function could get a lock that prevents the bucket primary > status from changing (see BucketRegion doLockForPrimary) and then check to > see if we are the primary (if not throw an exception that causes the function > sender to retry (see BucketMovedException) otherwise execute the function > and at the end release the lock (see BucketRegion doUnlockForPrimary). > We could enable this with a new method added to Function (much like the > existing isHA and optimizeForWrite). This new method could be > executeOnPrimary and default to false (adding a default method to the > Function interface will not cause backwards compatibility issues unless a > current class that implements Function already had added a method named > "executeOnPrimary"). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8178) CI Failure: EnsurePrimaryStaysPutDUnitTest > primaryRemainsWhileLocalFunctionExecutes
[
https://issues.apache.org/jira/browse/GEODE-8178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114452#comment-17114452
]
ASF subversion and git services commented on GEODE-8178:
Commit f243c4d99e1a223af0a3134d6a423b972195c507 in geode's branch
refs/heads/develop from Darrel Schneider
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f243c4d ]
Revert GEODE-8127: the test is flakey (#5153)
* Revert "GEODE-8127: ensure that redis function executes on primary (#5133)"
This reverts commit e0cbd78149d520f77e896426b691c217d3afcfb4.
The new test added in it was failing intermittently. See: GEODE-8178
> CI Failure: EnsurePrimaryStaysPutDUnitTest >
> primaryRemainsWhileLocalFunctionExecutes
> -
>
> Key: GEODE-8178
> URL: https://issues.apache.org/jira/browse/GEODE-8178
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Donal Evans
>Priority: Major
> Labels: flaky
>
> Suspect strings logged in test:
> {noformat}
> org.apache.geode.redis.EnsurePrimaryStaysPutDUnitTest >
> primaryRemainsWhileLocalFunctionExecutes FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 2044
> [error 2020/05/22 20:06:02.065 GMT
> tid=216] Member is not primary.
> {noformat}
> Test failed in this run:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/195#A
> Was unable to reproduce the failure in 100 runs locally, so seems like a very
> rare flaky failure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8178) CI Failure: EnsurePrimaryStaysPutDUnitTest > primaryRemainsWhileLocalFunctionExecutes
[
https://issues.apache.org/jira/browse/GEODE-8178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-8178.
-
Fix Version/s: 1.14.0
Resolution: Fixed
Fixed by reverting the flaky test
> CI Failure: EnsurePrimaryStaysPutDUnitTest >
> primaryRemainsWhileLocalFunctionExecutes
> -
>
> Key: GEODE-8178
> URL: https://issues.apache.org/jira/browse/GEODE-8178
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Donal Evans
>Assignee: Darrel Schneider
>Priority: Major
> Labels: flaky
> Fix For: 1.14.0
>
>
> Suspect strings logged in test:
> {noformat}
> org.apache.geode.redis.EnsurePrimaryStaysPutDUnitTest >
> primaryRemainsWhileLocalFunctionExecutes FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 2044
> [error 2020/05/22 20:06:02.065 GMT
> tid=216] Member is not primary.
> {noformat}
> Test failed in this run:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/195#A
> Was unable to reproduce the failure in 100 runs locally, so seems like a very
> rare flaky failure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8178) CI Failure: EnsurePrimaryStaysPutDUnitTest > primaryRemainsWhileLocalFunctionExecutes
[
https://issues.apache.org/jira/browse/GEODE-8178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider reassigned GEODE-8178:
---
Assignee: Darrel Schneider
> CI Failure: EnsurePrimaryStaysPutDUnitTest >
> primaryRemainsWhileLocalFunctionExecutes
> -
>
> Key: GEODE-8178
> URL: https://issues.apache.org/jira/browse/GEODE-8178
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Donal Evans
>Assignee: Darrel Schneider
>Priority: Major
> Labels: flaky
>
> Suspect strings logged in test:
> {noformat}
> org.apache.geode.redis.EnsurePrimaryStaysPutDUnitTest >
> primaryRemainsWhileLocalFunctionExecutes FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 2044
> [error 2020/05/22 20:06:02.065 GMT
> tid=216] Member is not primary.
> {noformat}
> Test failed in this run:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/195#A
> Was unable to reproduce the failure in 100 runs locally, so seems like a very
> rare flaky failure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8179) gfsh query command returns incorrect results if '=' sign is missing for query option
Eric Shu created GEODE-8179: --- Summary: gfsh query command returns incorrect results if '=' sign is missing for query option Key: GEODE-8179 URL: https://issues.apache.org/jira/browse/GEODE-8179 Project: Geode Issue Type: Bug Components: gfsh Reporter: Eric Shu gfsh returns correct result when "=" is there for the query option: gfsh>query --query="Select ID from /portfolio where ID = 3" Result : true Limit : 100 Rows : 1 Result -- 3 It returns wrong result when "=" is missing for the query option. gfsh>query --query "Select ID from /portfolio where ID <= 3 " Result : true Limit : 100 Rows : 3 Result -- 0 1 2 gfsh>query --query " Select ID from /portfolio where ID = 3 " Result : false Message : Query is invalid due to error : gfsh>query --query " Select ID from /portfolio where ID == 3 " Result : true Limit : 100 Rows: 1 Query Trace : Query Executed in 0.968059 ms; indexesUsed(0) Result -- 3 gfsh>query --query " Select ID from /portfolio where ID =<= 3 " Result : true Limit : 100 Rows: 4 Query Trace : Query Executed in 1.427194 ms; indexesUsed(0) Result -- 0 1 2 3 Seems that first '=' in the query string is discarded by gfsh. Either fail the query if the query option'=' is missing or gfsh should return correct result from the query string. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8175) Remove unsupported redis commands that use old data model
[ https://issues.apache.org/jira/browse/GEODE-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114461#comment-17114461 ] ASF GitHub Bot commented on GEODE-8175: --- dschneider-pivotal merged pull request #5146: URL: https://github.com/apache/geode/pull/5146 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 unsupported redis commands that use old data model > - > > Key: GEODE-8175 > URL: https://issues.apache.org/jira/browse/GEODE-8175 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > > Remove the code corresponding to the commands that are not using the new data > model this includes: > Sorted Sets > Geo > Lists > HyperLogLog > Transaction Commands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8175) Remove unsupported redis commands that use old data model
[ https://issues.apache.org/jira/browse/GEODE-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114462#comment-17114462 ] ASF subversion and git services commented on GEODE-8175: Commit a05b86dc7b847844a99f300bd04132137dfc9597 in geode's branch refs/heads/develop from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a05b86d ] GEODE-8175: remove unsupported redis commands (#5146) Removed list and zset commands. Removed redis HyperLog commands. Removed redis transaction commands. > Remove unsupported redis commands that use old data model > - > > Key: GEODE-8175 > URL: https://issues.apache.org/jira/browse/GEODE-8175 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.14.0 > > > Remove the code corresponding to the commands that are not using the new data > model this includes: > Sorted Sets > Geo > Lists > HyperLogLog > Transaction Commands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8175) Remove unsupported redis commands that use old data model
[ https://issues.apache.org/jira/browse/GEODE-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-8175. - Fix Version/s: 1.14.0 Resolution: Fixed > Remove unsupported redis commands that use old data model > - > > Key: GEODE-8175 > URL: https://issues.apache.org/jira/browse/GEODE-8175 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.14.0 > > > Remove the code corresponding to the commands that are not using the new data > model this includes: > Sorted Sets > Geo > Lists > HyperLogLog > Transaction Commands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8175) Remove unsupported redis commands that use old data model
[ https://issues.apache.org/jira/browse/GEODE-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114463#comment-17114463 ] ASF subversion and git services commented on GEODE-8175: Commit a05b86dc7b847844a99f300bd04132137dfc9597 in geode's branch refs/heads/develop from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a05b86d ] GEODE-8175: remove unsupported redis commands (#5146) Removed list and zset commands. Removed redis HyperLog commands. Removed redis transaction commands. > Remove unsupported redis commands that use old data model > - > > Key: GEODE-8175 > URL: https://issues.apache.org/jira/browse/GEODE-8175 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.14.0 > > > Remove the code corresponding to the commands that are not using the new data > model this includes: > Sorted Sets > Geo > Lists > HyperLogLog > Transaction Commands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8108) remove System.out.print calls from geode redis code
[ https://issues.apache.org/jira/browse/GEODE-8108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114465#comment-17114465 ] ASF GitHub Bot commented on GEODE-8108: --- dschneider-pivotal commented on pull request #5149: URL: https://github.com/apache/geode/pull/5149#issuecomment-632960137 Thanks for this work. Can you resolve the conflicts in GeodeRedisServer? 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 System.out.print calls from geode redis code > --- > > Key: GEODE-8108 > URL: https://issues.apache.org/jira/browse/GEODE-8108 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Alberto Bustamante Reyes >Priority: Major > Labels: pull-request-available > > I noticed in SMoveExecutor a number of System.out.println calls. This should > not be done. > Either remove the calls (that is what I recommend for SMoveExecutor) or use a > logger. > I don't know if SMoveExecutor is the only place this happens so a code scan > should be done. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8180) add 1.14 management REST wiki page
Owen Nichols created GEODE-8180: --- Summary: add 1.14 management REST wiki page Key: GEODE-8180 URL: https://issues.apache.org/jira/browse/GEODE-8180 Project: Geode Issue Type: Improvement Components: management Reporter: Owen Nichols add new wiki page id to generator script, and update to support -build.n convention as well as -SNAPSHOT -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8180) add 1.14 management REST wiki page
[ https://issues.apache.org/jira/browse/GEODE-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114476#comment-17114476 ] ASF GitHub Bot commented on GEODE-8180: --- onichols-pivotal opened a new pull request #5154: URL: https://github.com/apache/geode/pull/5154 add new wiki page id for 1.14 to generator script, and update to support -build.n convention as well as -SNAPSHOT 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 1.14 management REST wiki page > -- > > Key: GEODE-8180 > URL: https://issues.apache.org/jira/browse/GEODE-8180 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Owen Nichols >Priority: Major > > add new wiki page id to generator script, and update to support -build.n > convention as well as -SNAPSHOT -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8180) add 1.14 management REST wiki page
[ https://issues.apache.org/jira/browse/GEODE-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols reassigned GEODE-8180: --- Assignee: Owen Nichols > add 1.14 management REST wiki page > -- > > Key: GEODE-8180 > URL: https://issues.apache.org/jira/browse/GEODE-8180 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > > add new wiki page id to generator script, and update to support -build.n > convention as well as -SNAPSHOT -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8175) Remove unsupported redis commands that use old data model
[ https://issues.apache.org/jira/browse/GEODE-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114488#comment-17114488 ] ASF GitHub Bot commented on GEODE-8175: --- onichols-pivotal opened a new pull request #5155: URL: https://github.com/apache/geode/pull/5155 Reverts apache/geode#5146 which caused compile error 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 unsupported redis commands that use old data model > - > > Key: GEODE-8175 > URL: https://issues.apache.org/jira/browse/GEODE-8175 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.14.0 > > > Remove the code corresponding to the commands that are not using the new data > model this includes: > Sorted Sets > Geo > Lists > HyperLogLog > Transaction Commands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8175) Remove unsupported redis commands that use old data model
[ https://issues.apache.org/jira/browse/GEODE-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114489#comment-17114489 ] ASF subversion and git services commented on GEODE-8175: Commit 3f747ce13e679e26d2dee32ac8ff0391dbb313d8 in geode's branch refs/heads/revert-5146-remove-lists from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3f747ce ] Revert "GEODE-8175: remove unsupported redis commands (#5146)" This reverts commit a05b86dc7b847844a99f300bd04132137dfc9597. > Remove unsupported redis commands that use old data model > - > > Key: GEODE-8175 > URL: https://issues.apache.org/jira/browse/GEODE-8175 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.14.0 > > > Remove the code corresponding to the commands that are not using the new data > model this includes: > Sorted Sets > Geo > Lists > HyperLogLog > Transaction Commands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8180) add 1.14 management REST wiki page
[ https://issues.apache.org/jira/browse/GEODE-8180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-8180: Description: add new wiki page id to generator script, and update to support -build.n convention as well as -SNAPSHOT and support branches instead of release branches (was: add new wiki page id to generator script, and update to support -build.n convention as well as -SNAPSHOT) > add 1.14 management REST wiki page > -- > > Key: GEODE-8180 > URL: https://issues.apache.org/jira/browse/GEODE-8180 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > > add new wiki page id to generator script, and update to support -build.n > convention as well as -SNAPSHOT and support branches instead of release > branches -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8175) Remove unsupported redis commands that use old data model
[ https://issues.apache.org/jira/browse/GEODE-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114505#comment-17114505 ] ASF GitHub Bot commented on GEODE-8175: --- onichols-pivotal opened a new pull request #5156: URL: https://github.com/apache/geode/pull/5156 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 unsupported redis commands that use old data model > - > > Key: GEODE-8175 > URL: https://issues.apache.org/jira/browse/GEODE-8175 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.14.0 > > > Remove the code corresponding to the commands that are not using the new data > model this includes: > Sorted Sets > Geo > Lists > HyperLogLog > Transaction Commands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8175) Remove unsupported redis commands that use old data model
[ https://issues.apache.org/jira/browse/GEODE-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114508#comment-17114508 ] ASF GitHub Bot commented on GEODE-8175: --- onichols-pivotal closed pull request #5155: URL: https://github.com/apache/geode/pull/5155 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 unsupported redis commands that use old data model > - > > Key: GEODE-8175 > URL: https://issues.apache.org/jira/browse/GEODE-8175 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.14.0 > > > Remove the code corresponding to the commands that are not using the new data > model this includes: > Sorted Sets > Geo > Lists > HyperLogLog > Transaction Commands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8175) Remove unsupported redis commands that use old data model
[ https://issues.apache.org/jira/browse/GEODE-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114506#comment-17114506 ] ASF GitHub Bot commented on GEODE-8175: --- onichols-pivotal commented on pull request #5155: URL: https://github.com/apache/geode/pull/5155#issuecomment-632979104 easier to just fix, see #5156 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 unsupported redis commands that use old data model > - > > Key: GEODE-8175 > URL: https://issues.apache.org/jira/browse/GEODE-8175 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.14.0 > > > Remove the code corresponding to the commands that are not using the new data > model this includes: > Sorted Sets > Geo > Lists > HyperLogLog > Transaction Commands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8175) Remove unsupported redis commands that use old data model
[ https://issues.apache.org/jira/browse/GEODE-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114512#comment-17114512 ] ASF subversion and git services commented on GEODE-8175: Commit 03355b9d4c7754e5b8fc14ec781645c4c00679c7 in geode's branch refs/heads/develop from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=03355b9 ] GEODE-8175: fix compile error (#5156) > Remove unsupported redis commands that use old data model > - > > Key: GEODE-8175 > URL: https://issues.apache.org/jira/browse/GEODE-8175 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.14.0 > > > Remove the code corresponding to the commands that are not using the new data > model this includes: > Sorted Sets > Geo > Lists > HyperLogLog > Transaction Commands -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8175) Remove unsupported redis commands that use old data model
[ https://issues.apache.org/jira/browse/GEODE-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114511#comment-17114511 ] ASF GitHub Bot commented on GEODE-8175: --- onichols-pivotal merged pull request #5156: URL: https://github.com/apache/geode/pull/5156 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 unsupported redis commands that use old data model > - > > Key: GEODE-8175 > URL: https://issues.apache.org/jira/browse/GEODE-8175 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.14.0 > > > Remove the code corresponding to the commands that are not using the new data > model this includes: > Sorted Sets > Geo > Lists > HyperLogLog > Transaction Commands -- This message was sent by Atlassian Jira (v8.3.4#803005)
