[jira] [Created] (GEODE-9421) Remove ParallelGatewaySenderQueue$BatchRemovalThread NPE logs when running JUnit tests
Alberto Gomez created GEODE-9421: Summary: Remove ParallelGatewaySenderQueue$BatchRemovalThread NPE logs when running JUnit tests Key: GEODE-9421 URL: https://issues.apache.org/jira/browse/GEODE-9421 Project: Geode Issue Type: Improvement Components: tests Reporter: Alberto Gomez The ouput of the run of the CI sometimes shows the following NPE logs: Exception in thread "BatchRemovalThread for GatewaySender_sender_0" java.lang.NullPointerException at org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue$BatchRemovalThread.checkCancelled(ParallelGatewaySenderQueue.java:1841) at org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue$BatchRemovalThread.run(ParallelGatewaySenderQueue.java:1942) Exception in thread "BatchRemovalThread for GatewaySender_sender_4" java.lang.NullPointerException at org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue$BatchRemovalThread.checkCancelled(ParallelGatewaySenderQueue.java:1841) at org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue$BatchRemovalThread.run(ParallelGatewaySenderQueue.java:1942) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9421) Remove ParallelGatewaySenderQueue$BatchRemovalThread NPE logs when running JUnit tests
[ https://issues.apache.org/jira/browse/GEODE-9421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez reassigned GEODE-9421: Assignee: Alberto Gomez > Remove ParallelGatewaySenderQueue$BatchRemovalThread NPE logs when running > JUnit tests > -- > > Key: GEODE-9421 > URL: https://issues.apache.org/jira/browse/GEODE-9421 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > > The ouput of the run of the CI sometimes shows the following NPE logs: > Exception in thread "BatchRemovalThread for GatewaySender_sender_0" > java.lang.NullPointerException > at > org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue$BatchRemovalThread.checkCancelled(ParallelGatewaySenderQueue.java:1841) > at > org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue$BatchRemovalThread.run(ParallelGatewaySenderQueue.java:1942) > Exception in thread "BatchRemovalThread for GatewaySender_sender_4" > java.lang.NullPointerException > at > org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue$BatchRemovalThread.checkCancelled(ParallelGatewaySenderQueue.java:1841) > at > org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue$BatchRemovalThread.run(ParallelGatewaySenderQueue.java:1942) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9421) Remove ParallelGatewaySenderQueue$BatchRemovalThread NPE logs when running JUnit tests
[ https://issues.apache.org/jira/browse/GEODE-9421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9421: -- Labels: pull-request-available (was: ) > Remove ParallelGatewaySenderQueue$BatchRemovalThread NPE logs when running > JUnit tests > -- > > Key: GEODE-9421 > URL: https://issues.apache.org/jira/browse/GEODE-9421 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > The ouput of the run of the CI sometimes shows the following NPE logs: > Exception in thread "BatchRemovalThread for GatewaySender_sender_0" > java.lang.NullPointerException > at > org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue$BatchRemovalThread.checkCancelled(ParallelGatewaySenderQueue.java:1841) > at > org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue$BatchRemovalThread.run(ParallelGatewaySenderQueue.java:1942) > Exception in thread "BatchRemovalThread for GatewaySender_sender_4" > java.lang.NullPointerException > at > org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue$BatchRemovalThread.checkCancelled(ParallelGatewaySenderQueue.java:1841) > at > org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue$BatchRemovalThread.run(ParallelGatewaySenderQueue.java:1942) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9407) RegionDestroyedException while executing GetMemberInformationFunction
[
https://issues.apache.org/jira/browse/GEODE-9407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17378128#comment-17378128
]
ASF subversion and git services commented on GEODE-9407:
Commit 6ba9a825abee6ffac7eec8ef4480cffdb2a5dc6b in geode's branch
refs/heads/develop from Aaron Lindsey
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6ba9a82 ]
GEODE-9407: Handle exception getting region names (#6665)
GetMemberInformationFunction may throw RegionDestroyedException if a
hosted region is destroyed while the function is checking the region
names. This exception is logged as an "error" level message which is
confusing to users.
Catch the exception and omit the destroyed region from the list of
hosted region names.
> RegionDestroyedException while executing GetMemberInformationFunction
> -
>
> Key: GEODE-9407
> URL: https://issues.apache.org/jira/browse/GEODE-9407
> Project: Geode
> Issue Type: Bug
> Components: gfsh, management
>Reporter: Aaron Lindsey
>Assignee: Aaron Lindsey
>Priority: Minor
> Labels: pull-request-available
>
> GetMemberInformationFunction is used by the gfsh "describe member" command,
> the management REST API "/members" endpoint, and is also used internally
> within Geode. If this function is invoked while concurrently destroying a
> region, it may throw RegionDestroyedException while trying to gather
> information about the destroyed region's subregions.
>
> This bug manifests as a nasty error message in the logs of the member where
> the function was being executed (shown below). This confuses Geode
> users/developers/operators because it looks like a problem with the system
> while instead it's actually expected behavior. GetMemberInformationFunction
> should probably catch RegionDestroyedException and remove the destroyed
> region from the set of region names in ManagementUtils.getAllRegionNames.
>
> {code:java}
> [error 2021/06/29 23:01:38.640 GMT system-test-gemfire-server-0 Execution Processor3> tid=0x94] Unable to gather runtime information on this
> member.
> org.apache.geode.cache.RegionDestroyedException: Partitioned Region @79f60edb
> [path='/region'; dataPolicy=PARTITION; prId=37; isDestroyed=true;
> isClosed=false; retryTimeout=360; serialNumber=4309; partition
> attributes=PartitionAttributes@1299510666[redundantCopies=2;localMaxMemory=594;totalMaxMemory=2147483647;totalNumBuckets=113;partitionResolver=null;colocatedWith=null;recoveryDelay=-1;startupRecoveryDelay=0;FixedPartitionAttributes=null;partitionListeners=null];
> on VM system-test-gemfire-server-0(system-test-gemfire-server-0:1):41000]
> at
> org.apache.geode.internal.cache.LocalRegion.checkRegionDestroyed(LocalRegion.java:7342)
> at
> org.apache.geode.internal.cache.LocalRegion.checkReadiness(LocalRegion.java:2757)
> at
> org.apache.geode.internal.cache.LocalRegion.subregions(LocalRegion.java:1908)
> at
> org.apache.geode.management.internal.util.ManagementUtils.getAllRegionNames(ManagementUtils.java:167)
> at
> org.apache.geode.management.internal.functions.GetMemberInformationFunction.getMemberInformation(GetMemberInformationFunction.java:131)
> at
> org.apache.geode.management.internal.configuration.realizers.MemberRealizer.get(MemberRealizer.java:52)
> at
> org.apache.geode.management.internal.configuration.realizers.MemberRealizer.get(MemberRealizer.java:35)
> at
> org.apache.geode.management.internal.functions.CacheRealizationFunction.executeGet(CacheRealizationFunction.java:136)
> at
> org.apache.geode.management.internal.functions.CacheRealizationFunction.execute(CacheRealizationFunction.java:92)
> at
> org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:201)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:444)
> at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doFunctionExecutionThread(ClusterOperationExecutors.java:379)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
> at java.base/java.lang.Thread.run(Thread.java:829){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-6588) Cleanup internal use of generics and other static analyzer warnings
[ https://issues.apache.org/jira/browse/GEODE-6588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-6588: -- Labels: pull-request-available (was: ) > Cleanup internal use of generics and other static analyzer warnings > --- > > Key: GEODE-6588 > URL: https://issues.apache.org/jira/browse/GEODE-6588 > Project: Geode > Issue Type: Task >Reporter: Jacob Barrett >Assignee: Jacob Barrett >Priority: Major > Labels: pull-request-available > Time Spent: 8h 40m > Remaining Estimate: 0h > > Use generics where possible. > Cleanup other static analyzer issues along the way. > Generally make the IntelliJ analyzer gutter less cluttered. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9156) Switch from docker-compose to testcontainers
[ https://issues.apache.org/jira/browse/GEODE-9156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17378150#comment-17378150 ] ASF subversion and git services commented on GEODE-9156: Commit 781f5f18b8e50dc2c32e71ed54585018667c9555 in geode's branch refs/heads/support/1.14 from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=781f5f1 ] GEODE-9156: Replace docker-compose-rule with testcontainers in geode-connectors (#6378) (#6385) Something to note when doing SSL testing: testcontainers does not let you set the container name (using `container_name` in your compose.yml). This ultimately means that reverse IP lookups produce hostnames that look something like `project_service_index`. The problem is that these names are not RFC compliant as they contain underscores. This can break some aspects of SSL validation. I've had to work around this by renaming containers in various test classes. (cherry picked from commit a5335756a5801adf35ffdf4635b51cb17757eb84) (cherry picked from commit 473af500ce43a4d35e08d4d750f3b5ed9186cc99) > Switch from docker-compose to testcontainers > > > Key: GEODE-9156 > URL: https://issues.apache.org/jira/browse/GEODE-9156 > Project: Geode > Issue Type: Task > Components: membership >Reporter: Ernest Burghardt >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > > Palantir docker-compose-rule is sunsetting this month. Palantir advises > switching to testcontainers' docker compose integration. We already use > testcontainer... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9417) ZRANGE Behavior After Deletion of Key Inconsistent With Redis
[ https://issues.apache.org/jira/browse/GEODE-9417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans reassigned GEODE-9417: -- Assignee: Donal Evans > ZRANGE Behavior After Deletion of Key Inconsistent With Redis > - > > Key: GEODE-9417 > URL: https://issues.apache.org/jira/browse/GEODE-9417 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > Labels: blocks-1.15.0, redis > > After deleting a SortedSet the behavior for ZRANGE differs from native Redis. > > +Reproduction Steps:+ > Add some data to a SortedSet: > * ZADD leaderboard 1 "one" > * ZADD leaderboard 2 "two" > Delete the SortedSet with the key "leaderboard": > * DEL leaderboard > Now perform a ZRANGE command on the deleted key > ZRANGE leaderboard 0 10 > > Native Redis returns "(empty array)" where as we return " > "(error) ERR The server had an internal error please try again". > > The same behavior occurs even if the SortedSet never existed. For example: > ZRANGE nonexistent 0 10 will also result in > "(error) ERR The server had an internal error please try again". > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9410) User Guide: gfsh import cluster-configuration inconsistencies
[ https://issues.apache.org/jira/browse/GEODE-9410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17378161#comment-17378161 ] ASF subversion and git services commented on GEODE-9410: Commit 9948cfe2bdd973fc73dd8d3d9da347f5628427dd in geode's branch refs/heads/support/1.14 from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9948cfe ] GEODE-9410: User Guide - resolve inconsistencies in gfsh import cluster-configuration command description (#6669) (cherry picked from commit 9c55efe4619b207c83646193b37f5cbe9f1c5877) > User Guide: gfsh import cluster-configuration inconsistencies > - > > Key: GEODE-9410 > URL: https://issues.apache.org/jira/browse/GEODE-9410 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.13.3 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Minor > Labels: pull-request-available > > Two write-ups on the gfsh import cluster-configuration command seem to differ > with regard to whether the operation is allowed on running cache servers. > The operation is allowed, but with restrictions. The correct details are > provided in the gfsh import command description: > [https://geode.apache.org/docs/guide/113/tools_modules/gfsh/command-pages/import.html#topic_vnv_grz_ck] > The corresponding section under Exporting and Importing Cluster > Configurations is less clear, and could be improved: > https://geode.apache.org/docs/guide/113/configuring/cluster_config/export-import.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9346) When client received incorrect byte array of PdxType due to broken socket, it should be retried
[ https://issues.apache.org/jira/browse/GEODE-9346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17378211#comment-17378211 ] ASF subversion and git services commented on GEODE-9346: Commit 11e4c3a4ca4bf7ef2203e0fdd111e536e5721e50 in geode's branch refs/heads/develop from Xiaojian Zhou [ https://gitbox.apache.org/repos/asf?p=geode.git;h=11e4c3a ] GEODE-9346: When client received incorrect byte array of PdxType due … (#6561) > When client received incorrect byte array of PdxType due to broken socket, it > should be retried > > > Key: GEODE-9346 > URL: https://issues.apache.org/jira/browse/GEODE-9346 > Project: Geode > Issue Type: Bug >Affects Versions: 1.12.2, 1.13.2, 1.14.0, 1.15.0 >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: pull-request-available > > Client's query for PdxType will get a byte array in response message. The > byte array is the same at the server, but different query from different > client might receive wrong byte array and end up with > PdxSerializationException in scalability test with server HA. This could > caused by socket broken and bytes are not flushed. We expected such broken > socket scenario and prepared some retry lock. However, our retry logic did > not consider above scenario, i.e. the message header is correct, but the > embedded byte array for PdxType is wrong. > The solution is to retry in this case. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9346) When client received incorrect byte array of PdxType due to broken socket, it should be retried
[ https://issues.apache.org/jira/browse/GEODE-9346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17378218#comment-17378218 ] ASF subversion and git services commented on GEODE-9346: Commit 2144def9b3c79dbcaa9a3e24b002b11a60c69761 in geode's branch refs/heads/feature/GEODE-9346 from Xiaojian Zhou [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2144def ] GEODE-9346: When client received incorrect byte array of PdxType due … (#6561) (cherry picked from commit 11e4c3a4ca4bf7ef2203e0fdd111e536e5721e50) > When client received incorrect byte array of PdxType due to broken socket, it > should be retried > > > Key: GEODE-9346 > URL: https://issues.apache.org/jira/browse/GEODE-9346 > Project: Geode > Issue Type: Bug >Affects Versions: 1.12.2, 1.13.2, 1.14.0, 1.15.0 >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: pull-request-available > > Client's query for PdxType will get a byte array in response message. The > byte array is the same at the server, but different query from different > client might receive wrong byte array and end up with > PdxSerializationException in scalability test with server HA. This could > caused by socket broken and bytes are not flushed. We expected such broken > socket scenario and prepared some retry lock. However, our retry logic did > not consider above scenario, i.e. the message header is correct, but the > embedded byte array for PdxType is wrong. > The solution is to retry in this case. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9360) Initial revision of .net core support
[ https://issues.apache.org/jira/browse/GEODE-9360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17378219#comment-17378219 ] ASF GitHub Bot commented on GEODE-9360: --- pdxcodemonkey commented on a change in pull request #823: URL: https://github.com/apache/geode-native/pull/823#discussion_r667130870 ## File path: netcore/geode-dotnet-core.sln ## @@ -0,0 +1,31 @@ + Review comment: FWIW, based on earlier comments I moved us back to .net core 3.1 until such time as we can go to v6. So don't bother installing 5 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Initial revision of .net core support > - > > Key: GEODE-9360 > URL: https://issues.apache.org/jira/browse/GEODE-9360 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Priority: Major > Labels: pull-request-available > > As a .net core developer, I would like to be able to access the geode-native > API. To facilitate this, we need to implement a minimal set of C# classes > that use p/invoke to access geode-native via C bindings (GEODE-9358). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9422) Remove duplicate 'utility' project from tree
Blake Bender created GEODE-9422: --- Summary: Remove duplicate 'utility' project from tree Key: GEODE-9422 URL: https://issues.apache.org/jira/browse/GEODE-9422 Project: Geode Issue Type: Task Components: native client Reporter: Blake Bender The (currently) pending .net core support checkin makes use of the existing Java code for a test implementation of `IAuthInitialize`. To make .net core buildable as a standalone thing, we copied the existing Java code into a directory under `/netcore` in the tree. After .net core is in the tree and dev work is unblocked, we need to remove this duplicate Java code and build it from somewhere shared. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9360) Initial revision of .net core support
[
https://issues.apache.org/jira/browse/GEODE-9360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17378222#comment-17378222
]
ASF GitHub Bot commented on GEODE-9360:
---
pdxcodemonkey commented on a change in pull request #823:
URL: https://github.com/apache/geode-native/pull/823#discussion_r667133615
##
File path: netcore/utility/SimpleSecurityManager.java
##
@@ -0,0 +1,79 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package javaobject;
+
+import org.apache.geode.security.AuthenticationFailedException;
+import org.apache.geode.security.SecurityManager;
+
+import java.util.Properties;
+
+import javaobject.UserPasswordAuthInit;
+import javaobject.UsernamePrincipal;
+
+/**
+ * This Security manager only Authenticates - and allows any operations.
+ */
+public class SimpleSecurityManager implements SecurityManager {
Review comment:
https://issues.apache.org/jira/browse/GEODE-9422 filed to remove
duplicate Java code.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Initial revision of .net core support
> -
>
> Key: GEODE-9360
> URL: https://issues.apache.org/jira/browse/GEODE-9360
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> As a .net core developer, I would like to be able to access the geode-native
> API. To facilitate this, we need to implement a minimal set of C# classes
> that use p/invoke to access geode-native via C bindings (GEODE-9358).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9360) Initial revision of .net core support
[ https://issues.apache.org/jira/browse/GEODE-9360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17378225#comment-17378225 ] ASF GitHub Bot commented on GEODE-9360: --- pdxcodemonkey commented on a change in pull request #823: URL: https://github.com/apache/geode-native/pull/823#discussion_r667134346 ## File path: netcore/utility/UserPasswordAuthInit.java ## @@ -0,0 +1,81 @@ +/* Review comment: Don't think it makes sense right now to modify the Java code, since we'll ultimately be removing it and building from a shared directory. Again, https://issues.apache.org/jira/browse/GEODE-9422 is tracking. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Initial revision of .net core support > - > > Key: GEODE-9360 > URL: https://issues.apache.org/jira/browse/GEODE-9360 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Priority: Major > Labels: pull-request-available > > As a .net core developer, I would like to be able to access the geode-native > API. To facilitate this, we need to implement a minimal set of C# classes > that use p/invoke to access geode-native via C bindings (GEODE-9358). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9423) Improve Tomcat rolling upgrade tests
Sarah Abbey created GEODE-9423: -- Summary: Improve Tomcat rolling upgrade tests Key: GEODE-9423 URL: https://issues.apache.org/jira/browse/GEODE-9423 Project: Geode Issue Type: Test Reporter: Sarah Abbey Refactor/improve Tomcat rolling upgrade tests -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9423) Improve Tomcat rolling upgrade tests
[ https://issues.apache.org/jira/browse/GEODE-9423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sarah Abbey reassigned GEODE-9423: -- Assignee: Sarah Abbey > Improve Tomcat rolling upgrade tests > > > Key: GEODE-9423 > URL: https://issues.apache.org/jira/browse/GEODE-9423 > Project: Geode > Issue Type: Test >Reporter: Sarah Abbey >Assignee: Sarah Abbey >Priority: Major > > Refactor/improve Tomcat rolling upgrade tests -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9418) Add Rolling Upgrade Tests for Tomcat 9
[ https://issues.apache.org/jira/browse/GEODE-9418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9418: -- Labels: pull-request-available (was: ) > Add Rolling Upgrade Tests for Tomcat 9 > -- > > Key: GEODE-9418 > URL: https://issues.apache.org/jira/browse/GEODE-9418 > Project: Geode > Issue Type: Test >Reporter: Sarah Abbey >Assignee: Sarah Abbey >Priority: Major > Labels: pull-request-available > > We have these tests for Tomcat 8, but never added them for Tomcat 9 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9182) Implement ZCOUNT Command
[ https://issues.apache.org/jira/browse/GEODE-9182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-9182. Resolution: Fixed > Implement ZCOUNT Command > > > Key: GEODE-9182 > URL: https://issues.apache.org/jira/browse/GEODE-9182 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available, redis > Fix For: 1.15.0 > > > Implement the [ZCOUNT|https://redis.io/commands/zcount] command. > > +Acceptance Criteria+ > Develop new unit tests to assert that the command is working correctly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9182) Implement ZCOUNT Command
[ https://issues.apache.org/jira/browse/GEODE-9182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17378243#comment-17378243 ] ASF subversion and git services commented on GEODE-9182: Commit ea19ff0b06795cae832330b6bbf585022ddd30c6 in geode's branch refs/heads/develop from Donal Evans [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ea19ff0 ] GEODE-9182: Implement Radish ZCOUNT command (#6680) * GEODE-9182: Implement Radish ZCOUNT command - Add ZCOUNT to supported commands - Modify OrderStatisticsTree.indexOf() to return the index of elements that are not present in the collection instead of -1, to make the behaviour of OrderStatisticsTree and IndexibleTreeSet match - Introduce AbstractOrderedSetEntry superclass - Introduce DummyOrderedSetEntry subclass - Have OrderedSetEntry and DummyOrderedSetEntry implement different constructors and methods for comparing member names - Add constants to the StringBytesGlossary to support parsing Redis score range values and doing more comparisons on String member names - Replace hardcoded Strings with constants in AbstractHitsMissesIntegrationTest - Fix an inaccurate Javadoc introduced by a previous commit - Small code clean-ups in code related to ZRANGE - Add tests for ZCOUNT and new behaviour in OrderStatisticsTree and DummyOrderedSetEntry Authored-by: Donal Evans > Implement ZCOUNT Command > > > Key: GEODE-9182 > URL: https://issues.apache.org/jira/browse/GEODE-9182 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available, redis > Fix For: 1.15.0 > > > Implement the [ZCOUNT|https://redis.io/commands/zcount] command. > > +Acceptance Criteria+ > Develop new unit tests to assert that the command is working correctly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9182) Implement ZCOUNT Command
[ https://issues.apache.org/jira/browse/GEODE-9182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17378242#comment-17378242 ] ASF subversion and git services commented on GEODE-9182: Commit ea19ff0b06795cae832330b6bbf585022ddd30c6 in geode's branch refs/heads/develop from Donal Evans [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ea19ff0 ] GEODE-9182: Implement Radish ZCOUNT command (#6680) * GEODE-9182: Implement Radish ZCOUNT command - Add ZCOUNT to supported commands - Modify OrderStatisticsTree.indexOf() to return the index of elements that are not present in the collection instead of -1, to make the behaviour of OrderStatisticsTree and IndexibleTreeSet match - Introduce AbstractOrderedSetEntry superclass - Introduce DummyOrderedSetEntry subclass - Have OrderedSetEntry and DummyOrderedSetEntry implement different constructors and methods for comparing member names - Add constants to the StringBytesGlossary to support parsing Redis score range values and doing more comparisons on String member names - Replace hardcoded Strings with constants in AbstractHitsMissesIntegrationTest - Fix an inaccurate Javadoc introduced by a previous commit - Small code clean-ups in code related to ZRANGE - Add tests for ZCOUNT and new behaviour in OrderStatisticsTree and DummyOrderedSetEntry Authored-by: Donal Evans > Implement ZCOUNT Command > > > Key: GEODE-9182 > URL: https://issues.apache.org/jira/browse/GEODE-9182 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available, redis > Fix For: 1.15.0 > > > Implement the [ZCOUNT|https://redis.io/commands/zcount] command. > > +Acceptance Criteria+ > Develop new unit tests to assert that the command is working correctly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9376) Implement ZREVRANGE Command
[ https://issues.apache.org/jira/browse/GEODE-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9376: -- Labels: pull-request-available redis (was: redis) > Implement ZREVRANGE Command > --- > > Key: GEODE-9376 > URL: https://issues.apache.org/jira/browse/GEODE-9376 > Project: Geode > Issue Type: New Feature > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available, redis > > Implement the [ZREVRANGE|https://redis.io/commands/zrevrange] command. > > +Acceptance Criteria+ > The ZREVRANGE command has been implemented and appropriate unit tests have > been developed. > > The command has been added to the AbstractHitsMissesIntegrationTest. > The command has been tested using the redis-cli tool. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9340) Benchmark instability in PartitionedPutLongBenchmark
[
https://issues.apache.org/jira/browse/GEODE-9340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17378246#comment-17378246
]
Hale Bales commented on GEODE-9340:
---
this PR was created to resolve this issue by ignoring the performance
regression and moving the baseline to version 1.13.3. The jetty performance
degradation occurred after 9.4.34, so we moved the baseline to use a newer
version that also has the performance issue. This will result in fewer CI
failures, and follows our protocol of changing the benchmark baseline when a
new version is released.
I was never able to track down the exact cause of the failure. It seems to be
somewhere in jetty that we don't have access to through profiling. Given that
it is a small performance regression that is only detectable by our most
sensitive tests, ignoring the issue is a reasonable solution that has been
approved in conversations with other developers.
> Benchmark instability in PartitionedPutLongBenchmark
>
>
> Key: GEODE-9340
> URL: https://issues.apache.org/jira/browse/GEODE-9340
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Sarah Abbey
>Assignee: Hale Bales
>Priority: Major
> Labels: pull-request-available
>
> PartitionedPutLongBenchmark failed in CI
> (https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/6):
> {code:java}
> This is ITERATION 1 of benchmarking against baseline.
> P2pPartitionedGetBenchmark avg ops/sec
> Baseline:825011.38 Test:835847.67 Difference: +1.3%
> avg latency
> Baseline:871392.31 Test:859444.66 Difference: -1.4%
> P2pPartitionedPutBenchmark avg ops/sec
> Baseline:123838.43 Test:122686.30 Difference: -0.9%
> avg latency
> Baseline: 6015719.73 Test: 6119472.19 Difference: +1.7%
> P2pPartitionedPutBytesBenchmark avg ops/sec
> Baseline:174887.77 Test:171040.93 Difference: -2.2%
> avg latency
> Baseline: 4145337.60 Test: 4236159.60 Difference: +2.2%
> PartitionedFunctionExecutionBenchmark avg ops/sec
> Baseline:248635.36 Test:261498.94 Difference: +5.2%
> avg latency
> Baseline:867122.63 Test:824550.34 Difference: -4.9%
> PartitionedFunctionExecutionWithArgumentsBenchmark avg ops/sec
> Baseline:280071.19 Test:275305.31 Difference: -1.7%
> avg latency
> Baseline: 1026643.12 Test: 1044307.43 Difference: +1.7%
> PartitionedFunctionExecutionWithFiltersBenchmark avg ops/sec
> Baseline:301416.23 Test:304317.30 Difference: +1.0%
> avg latency
> Baseline: 1908390.88 Test: 1890040.46 Difference: -1.0%
> PartitionedGetBenchmark avg ops/sec
> Baseline:790800.52 Test:784514.74 Difference: -0.8%
> avg latency
> Baseline:908357.58 Test:915790.96 Difference: +0.8%
> PartitionedGetLongBenchmark avg ops/sec
> Baseline: 1020821.32 Test:996529.93 Difference: -2.4%
> avg latency
> Baseline:703761.09 Test:720744.36 Difference: +2.4%
> PartitionedGetStringBenchmark avg ops/sec
> Baseline: 1028992.93 Test: 1010447.47 Difference: -1.8%
> avg latency
> Baseline:698009.55 Test:710765.29 Difference: +1.8%
> PartitionedIndexedQueryBenchmark avg ops/sec
> Baseline: 30868.78 Test: 31478.90 Difference: +2.0%
> avg latency
> Baseline: 18670093.21 Test: 18278083.16 Difference: -2.1%
> PartitionedNonIndexedQueryBenchmark avg ops/sec
> Baseline:99.45 Test: 101.97 Difference: +2.5%
> avg latency
> Baseline: 723415530.75 Test: 705653061.86 Difference: -2.5%
> PartitionedPutAllBenchmark avg ops/sec
> Baseline: 7921.61 Test: 7816.66 Difference
[jira] [Resolved] (GEODE-9340) Benchmark instability in PartitionedPutLongBenchmark
[
https://issues.apache.org/jira/browse/GEODE-9340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hale Bales resolved GEODE-9340.
---
Fix Version/s: 1.13.3
1.15.0
1.14.0
1.13.4
Resolution: Not A Problem
> Benchmark instability in PartitionedPutLongBenchmark
>
>
> Key: GEODE-9340
> URL: https://issues.apache.org/jira/browse/GEODE-9340
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.15.0
>Reporter: Sarah Abbey
>Assignee: Hale Bales
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.13.4, 1.14.0, 1.15.0, 1.13.3
>
>
> PartitionedPutLongBenchmark failed in CI
> (https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/6):
> {code:java}
> This is ITERATION 1 of benchmarking against baseline.
> P2pPartitionedGetBenchmark avg ops/sec
> Baseline:825011.38 Test:835847.67 Difference: +1.3%
> avg latency
> Baseline:871392.31 Test:859444.66 Difference: -1.4%
> P2pPartitionedPutBenchmark avg ops/sec
> Baseline:123838.43 Test:122686.30 Difference: -0.9%
> avg latency
> Baseline: 6015719.73 Test: 6119472.19 Difference: +1.7%
> P2pPartitionedPutBytesBenchmark avg ops/sec
> Baseline:174887.77 Test:171040.93 Difference: -2.2%
> avg latency
> Baseline: 4145337.60 Test: 4236159.60 Difference: +2.2%
> PartitionedFunctionExecutionBenchmark avg ops/sec
> Baseline:248635.36 Test:261498.94 Difference: +5.2%
> avg latency
> Baseline:867122.63 Test:824550.34 Difference: -4.9%
> PartitionedFunctionExecutionWithArgumentsBenchmark avg ops/sec
> Baseline:280071.19 Test:275305.31 Difference: -1.7%
> avg latency
> Baseline: 1026643.12 Test: 1044307.43 Difference: +1.7%
> PartitionedFunctionExecutionWithFiltersBenchmark avg ops/sec
> Baseline:301416.23 Test:304317.30 Difference: +1.0%
> avg latency
> Baseline: 1908390.88 Test: 1890040.46 Difference: -1.0%
> PartitionedGetBenchmark avg ops/sec
> Baseline:790800.52 Test:784514.74 Difference: -0.8%
> avg latency
> Baseline:908357.58 Test:915790.96 Difference: +0.8%
> PartitionedGetLongBenchmark avg ops/sec
> Baseline: 1020821.32 Test:996529.93 Difference: -2.4%
> avg latency
> Baseline:703761.09 Test:720744.36 Difference: +2.4%
> PartitionedGetStringBenchmark avg ops/sec
> Baseline: 1028992.93 Test: 1010447.47 Difference: -1.8%
> avg latency
> Baseline:698009.55 Test:710765.29 Difference: +1.8%
> PartitionedIndexedQueryBenchmark avg ops/sec
> Baseline: 30868.78 Test: 31478.90 Difference: +2.0%
> avg latency
> Baseline: 18670093.21 Test: 18278083.16 Difference: -2.1%
> PartitionedNonIndexedQueryBenchmark avg ops/sec
> Baseline:99.45 Test: 101.97 Difference: +2.5%
> avg latency
> Baseline: 723415530.75 Test: 705653061.86 Difference: -2.5%
> PartitionedPutAllBenchmark avg ops/sec
> Baseline: 7921.61 Test: 7816.66 Difference: -1.3%
> avg latency
> Baseline: 18172638.37 Test: 18416169.28 Difference: +1.3%
> PartitionedPutAllLongBenchmark avg ops/sec
> Baseline: 1379.53 Test: 1169.16 Difference: -15.2%
> avg latency
> Baseline: 105140260.44 Test: 123722914.94 Difference: +17.7%
> PartitionedPutBenchmark avg ops/sec
> Baseline:474986.11 Test:467924.19 Difference: -1.5%
>
[jira] [Updated] (GEODE-9420) GFSH connect will not autoload gfsecurity.properties without ssl-enabled-components defined
[ https://issues.apache.org/jira/browse/GEODE-9420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Godwin updated GEODE-9420: --- Priority: Minor (was: Major) > GFSH connect will not autoload gfsecurity.properties without > ssl-enabled-components defined > --- > > Key: GEODE-9420 > URL: https://issues.apache.org/jira/browse/GEODE-9420 > Project: Geode > Issue Type: Bug > Components: gfsh >Affects Versions: 1.15.0 >Reporter: Ivan Godwin >Priority: Minor > > Unexpected behavior observed around autloading `gfsecurity.properties` > during`gfsh connect`: > When specifying `ssl-keystore`, `ssl-truststore`, and their relative password > properties in a `gfsecurity.properties` file, but other `ssl-*` properties in > `gemfire.properties` or as system properties, `gfsh connect` does not > complete successfully. > Adding `ssl-enabled-components` to the `gfsecurity.properties` file allows > the autoloading to work during connect and the command does complete > successfully. However, the value of `ssl-enabled-components` is redacted in > the logs and we would like to avoid this result. > Also, specifying `security-properties-file` allows us to connect (i.e. `gfsh > connect --security-properties-file=gfsecurity.properties`), though we would > like the convenience of autoloading. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9420) GFSH connect will not autoload gfsecurity.properties without ssl-enabled-components defined
[ https://issues.apache.org/jira/browse/GEODE-9420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Godwin updated GEODE-9420: --- Description: Unexpected behavior observed around autloading `gfsecurity.properties` during`gfsh connect`: When specifying `ssl-keystore`, `ssl-truststore`, and their relative password properties in a `gfsecurity.properties` file, but other `ssl-*` properties in `gemfire.properties` or as system properties, `gfsh connect` does not complete successfully. Adding `ssl-enabled-components` to the `gfsecurity.properties` file allows the autoloading to work during connect and the command does complete successfully. However, the value of `ssl-enabled-components` is redacted in the logs and we would like to avoid this result. Also, specifying `security-properties-file` allows us to connect (i.e. `gfsh connect --security-properties-file=gfsecurity.properties`), though we would like the convenience of autoloading. Acceptance: * Autoloading of `gfsecurity.properties` works, regardless of which properties are specified in the file. was: Unexpected behavior observed around autloading `gfsecurity.properties` during`gfsh connect`: When specifying `ssl-keystore`, `ssl-truststore`, and their relative password properties in a `gfsecurity.properties` file, but other `ssl-*` properties in `gemfire.properties` or as system properties, `gfsh connect` does not complete successfully. Adding `ssl-enabled-components` to the `gfsecurity.properties` file allows the autoloading to work during connect and the command does complete successfully. However, the value of `ssl-enabled-components` is redacted in the logs and we would like to avoid this result. Also, specifying `security-properties-file` allows us to connect (i.e. `gfsh connect --security-properties-file=gfsecurity.properties`), though we would like the convenience of autoloading. > GFSH connect will not autoload gfsecurity.properties without > ssl-enabled-components defined > --- > > Key: GEODE-9420 > URL: https://issues.apache.org/jira/browse/GEODE-9420 > Project: Geode > Issue Type: Bug > Components: gfsh >Affects Versions: 1.15.0 >Reporter: Ivan Godwin >Priority: Minor > > Unexpected behavior observed around autloading `gfsecurity.properties` > during`gfsh connect`: > When specifying `ssl-keystore`, `ssl-truststore`, and their relative password > properties in a `gfsecurity.properties` file, but other `ssl-*` properties in > `gemfire.properties` or as system properties, `gfsh connect` does not > complete successfully. > Adding `ssl-enabled-components` to the `gfsecurity.properties` file allows > the autoloading to work during connect and the command does complete > successfully. However, the value of `ssl-enabled-components` is redacted in > the logs and we would like to avoid this result. > Also, specifying `security-properties-file` allows us to connect (i.e. `gfsh > connect --security-properties-file=gfsecurity.properties`), though we would > like the convenience of autoloading. > > Acceptance: > * Autoloading of `gfsecurity.properties` works, regardless of which > properties are specified in the file. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9404) Should not log "No information for senderId: " if the node processing the tx does not have sender configured
[
https://issues.apache.org/jira/browse/GEODE-9404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17378250#comment-17378250
]
ASF subversion and git services commented on GEODE-9404:
Commit f0e328ba3eb4a1b2b47bdca5d565b79e88fecdca in geode's branch
refs/heads/develop from Eric Shu
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f0e328b ]
GEODE-9404: Do not log error message if sender is not configured. (#6659)
* This is normal case for serial wan configuration. Error message should not be
logged when executing transactions.
* Log error message only if some events in a tx configured to group transaction
but
others do not have sender configured.
* Should not wait for lastTransactionEvent in a tx if no sender configured or
sender
does not set must group transaction.
> Should not log "No information for senderId: " if the node processing the tx
> does not have sender configured
>
>
> Key: GEODE-9404
> URL: https://issues.apache.org/jira/browse/GEODE-9404
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Affects Versions: 1.14.0
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> In serial wan setting, not all nodes have the sender configured. These error
> logging should not be logged. But currently it is logged for every tx
> operation if the the node does not have sender configured (which is a normal
> case for serail wan).
> The following stack shows where it was logged.
> org.apache.geode.internal.cache.TXLastEventInTransactionUtils.checkNoSendersGroupTransactionEvents(TXLastEventInTransactionUtils.java:81)
> at
> org.apache.geode.internal.cache.TXLastEventInTransactionUtils.getLastTransactionEvent(TXLastEventInTransactionUtils.java:45)
> at
> org.apache.geode.internal.cache.TXState.firePendingCallbacks(TXState.java:250)
> at org.apache.geode.internal.cache.TXState.commit(TXState.java:544)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.commit(TXStateProxyImpl.java:237)
> at
> org.apache.geode.internal.cache.TXManagerImpl.commit(TXManagerImpl.java:444)
> {code:java}
> private static boolean
> checkNoSendersGroupTransactionEvents(List callbacks,
> Cache cache) throws ServiceConfigurationError {
> for (String senderId : getSenderIdsForEvents(callbacks)) {
> GatewaySender sender = cache.getGatewaySender(senderId);
> if (sender == null) {
> logger.error("No sender found for {}", senderId, new Exception());
> throw new ServiceConfigurationError("No information for senderId: " +
> senderId);
> }
> if (sender.mustGroupTransactionEvents()) {
> return false;
> }
> }
> return true;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9139) SSLException in starting up a Locator
[
https://issues.apache.org/jira/browse/GEODE-9139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kamilla Aslami updated GEODE-9139:
--
Fix Version/s: (was: 1.14.0)
> SSLException in starting up a Locator
> -
>
> Key: GEODE-9139
> URL: https://issues.apache.org/jira/browse/GEODE-9139
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: blocks-1.14.0, pull-request-available
> Fix For: 1.15.0
>
>
> If you start up a locator using its host name, without a domain name, as a
> bind address you may get an SSLException in the form
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative DNS name matching hostname.domainname found
> {noformat}
> The LocatorLauncher and InternalLocator throw away the bind address string
> and later do a reverse lookup to find the fully qualified hostname to use in
> endpoint identification matching.If the locator's own TLS certificate
> doesn't have the fully qualified name in it as a Subject Alternate Name the
> connection that the Locator makes to its own location service will fail.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8064) DeploymentSemanticVersionJarDUnitTest.java (GEODE-7421) is failing.
[
https://issues.apache.org/jira/browse/GEODE-8064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17378295#comment-17378295
]
Mark Hanson commented on GEODE-8064:
Another issue with this test
{noformat}
org.apache.geode.management.internal.rest.DeploymentSemanticVersionJarDUnitTest
> deploySameJarNameWithDifferentContent
FAILEDorg.apache.geode.management.internal.rest.DeploymentSemanticVersionJarDUnitTest
> deploySameJarNameWithDifferentContent FAILED
java.lang.AssertionError: Suspicious strings were written to the log during
this run.
Fix the strings or use IgnoredException.addIgnoredException to ignore.
---
Found suspect string in 'dunit_suspect-vm0.log' at line 763
ZMÐÈhÌ.ßÝÒ¡3ÐþÕ
î ÑTæ:£#¹±K÷¦nÀÞ0ö¡?¢èZy@*¤ MáÚâ©øa칤ò
½PKüh#pjPKEéR timestamp3432µ05547016PK½{}¨
PKEéRüh#pjjddunit/function/Def.classþÊPKEéR½{}¨
ùtimestampPK?
--KpEt0WRhuP7_uJjerp4keHy2JOGeQ6
Content-Disposition: form-data; name="config"
Content-Type: application/json
at org.junit.Assert.fail(Assert.java:89)
at
org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:409)
at
org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:425)
at
org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:186)
at
org.apache.geode.test.dunit.rules.ClusterStartupRule.access$100(ClusterStartupRule.java:70)
at
org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:141)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
at
org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
at
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33)
at
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at
org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:119)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:566)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(Refle
[jira] [Commented] (GEODE-8064) DeploymentSemanticVersionJarDUnitTest.java (GEODE-7421) is failing.
[
https://issues.apache.org/jira/browse/GEODE-8064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17378296#comment-17378296
]
Geode Integration commented on GEODE-8064:
--
Seen in [distributed-test-openjdk11
#77|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk11/builds/77]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0358/test-results/distributedTest/1625861757/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0358/test-artifacts/1625861757/distributedtestfiles-openjdk11-1.15.0-build.0358.tgz].
> DeploymentSemanticVersionJarDUnitTest.java (GEODE-7421) is failing.
> ---
>
> Key: GEODE-8064
> URL: https://issues.apache.org/jira/browse/GEODE-8064
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Mark Hanson
>Assignee: Joris Melchior
>Priority: Major
> Labels: flaky
>
> The following tests are failing in the mass test run.
> {noformat}
> deploySameJarNameWithDifferentContent
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/2541
> deploy
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/2541
> deployWithPlainWillCleanSemanticVersion
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-mass-test-run-main/jobs/DistributedTestOpenJDK8/builds/2541
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-9338) Remove strong guarantees for redis PUBLISH command response
[
https://issues.apache.org/jira/browse/GEODE-9338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hale Bales reassigned GEODE-9338:
-
Assignee: Hale Bales
> Remove strong guarantees for redis PUBLISH command response
> ---
>
> Key: GEODE-9338
> URL: https://issues.apache.org/jira/browse/GEODE-9338
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Jens Deppe
>Assignee: Hale Bales
>Priority: Major
>
> Redis' {{PUBLISH}} command responds with the number of clients that have
> received the published message. Our current implementation attempts to
> respond with as accurate a number as possible. To that end, each publish (see
> {{PubSubImpl.publishMessageToSubscribers}} and
> {{AbstractSubscription.publishMessage}} are effectively synchronous
> operations. The current flow is:
> - PUBLISH some_message
> - Issue a fn call to each server and attempt to publish to each subscribed
> client
> - Count how many successful publish messages were written and return those
> - Respond to the redis client with the aggregated successful publishings
> In redis clustering mode, the response is only the number of local
> publishings. We can go even further and not attempt to first publish before
> subscribing, but simply respond with the current number of subscribers,
> regardless whether they are connected or not.
> We should be able to perform all pubsub work on the regular netty thread and
> completely remove the subscriber EventLoopGroup.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9424) Radish command arguments must support Long values
Donal Evans created GEODE-9424:
--
Summary: Radish command arguments must support Long values
Key: GEODE-9424
URL: https://issues.apache.org/jira/browse/GEODE-9424
Project: Geode
Issue Type: Bug
Components: redis
Affects Versions: 1.15.0
Reporter: Donal Evans
To match the behaviour seen when using native Redis, all command arguments that
take integer values (that is, as opposed to float or string) must allow values
in the range of {{Long.MIN_VALUE}} -> {{Long.MAX_VALUE}}.
Currently, passing a value smaller than {{Integer.MIN_VALUE}} or larger than
{{Integer.MAX_VALUE}} to these commands results in an error being returned,
which is not the case for native Redis.
Currently affected commands are:
SCAN
SSCAN
HSCAN
SPOP
SRANDMEMBER
BITPOS
GETBIT
SETBIT
SETRANGE
It should be enough to simply parse the argument as a Long and then narrow it
to an int in most cases, as internally the maximum value that the argument can
possibly take is {{Integer.MAX_VALUE}}. For example, [the maximum number of
elements in a Redis set is 2^32 - 1|https://redis.io/topics/data-types#sets],
so the largest meaningful value for the SSCAN CURSOR argument internally is
{{Integer.MAX_VALUE}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9365) HARegionQueue over throttles when multiple threads attempt concurrent adds
[ https://issues.apache.org/jira/browse/GEODE-9365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17378311#comment-17378311 ] Mark Hanson commented on GEODE-9365: I am testing the "other solution". That seems like a simple patch. The larger questions I think are interesting and I will need to investigate further. > HARegionQueue over throttles when multiple threads attempt concurrent adds > -- > > Key: GEODE-9365 > URL: https://issues.apache.org/jira/browse/GEODE-9365 > Project: Geode > Issue Type: Bug > Components: client queues >Reporter: Darrel Schneider >Assignee: Mark Hanson >Priority: Major > Labels: GeodeOperationAPI > > HARegionQueue.checkQueueSizeConstraint has some code that implements a > "throttle" on adds to a queue that is full. It is supposed to wait > "eventEnqueueWaitTime" before doing an add. But because this code does two > syncs (putGuard and permitMon) and only waits on one of them, it holds the > other sync for the duration of this threads throttle. Any other concurrent > thread trying to add to the queue gets stuck on the putGuard sync that is > held by the first thread that is doing the timed wait. So it ends up waiting > "eventEnqueueWaitTime" to acquire the first sync and then ends up waiting > again "eventEnqueueWaitTime" when it does its own timed wait. If you have 10 > concurrent threads trying to add one of them will end up waiting 10 * > "eventEnqueueWaitTime". > A couple ideas of how to fix this. Get rid of the putGuard and just use > permitMon. Then as soon as the first thread goes into its timed wait another > thread is allowed to sync on permitMon. But if this is done then we need to > think carefully about the code inside this sync block since it can not be > executed while one or more other threads are waiting in permitMon. > The other solution would be to compute the elapsed time it took to get into > the first sync and subtract that from the time we wait on permitMon. This > seems like a simple solution but does introduce at least one call of get time > (the second call is only needed if the queue is full). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9425) AutoConnectionSource thread in client can't query for available locators when it is connected to a locator that was shut down
Lynn Gallinat created GEODE-9425:
Summary: AutoConnectionSource thread in client can't query for
available locators when it is connected to a locator that was shut down
Key: GEODE-9425
URL: https://issues.apache.org/jira/browse/GEODE-9425
Project: Geode
Issue Type: Bug
Components: client/server
Affects Versions: 1.15.0
Reporter: Lynn Gallinat
The AutoConnectionSource thread runs in a client and queries the locator that
client is connected to so it can update the list of available locators.
But if the locator the client is connected to was shut down, the client can't
get an updated locator list.
In this case the locator was shut down and is not coming back, but there is
another available locator.
However we can't find out what that available locator is because we can't
complete the query.
To summarize: The AutoConnectionSource thread that runs in a client to update
the list of available locators should be able to get a list of available
locators even when that client is connected to a locator that was shut down.
The AutoConnectionSource thread starts and runs every 10 seconds. This is from
the client's system log.
[info 2021/07/07 19:37:33.723 GMT clientgemfire1_host1_881
tid=0x2d] AutoConnectionSource
UpdateLocatorListTask started with interval=1 ms.
After the locator is shut down the AutoConnectionSource thread can't complete
its work so we get stuck threads.
This stuck thread stack shows it is trying to run UpdateLocatorListTask.
{noformat}
clientgemfire1_881/system.log: [warn 2021/07/07 19:47:25.784 GMT
clientgemfire1_host1_881 tid=0x36] Thread <286> (0x11e) that
was executed at <07 Jul 2021 19:46:03 GMT> has been stuck for <82.041 seconds>
and number of thread monitor iteration <1>
Thread Name state
Executor Group
Monitored metric
Thread stack for "poolTimer-pool-24" (0x11e):
java.lang.ThreadState: RUNNABLE (in native)
at java.net.PlainSocketImpl.socketConnect(Native Method)
at
java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
- locked java.net.SocksSocketImpl@3e95a505
at
java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
at java.net.Socket.connect(Socket.java:607)
at
org.apache.geode.distributed.internal.tcpserver.AdvancedSocketCreatorImpl.connect(AdvancedSocketCreatorImpl.java:102)
at
org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:51)
at
org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.connect(ClusterSocketCreatorImpl.java:96)
at
org.apache.geode.distributed.internal.tcpserver.TcpClient.getServerVersion(TcpClient.java:246)
at
org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:151)
at
org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:217)
at
org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:207)
at
org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:254)
at
org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.access$200(AutoConnectionSourceImpl.java:68)
at
org.apache.geode.cache.client.internal.AutoConnectionSourceImpl$UpdateLocatorListTask.run2(AutoConnectionSourceImpl.java:458)
at
org.apache.geode.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1334)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at
org.apache.geode.internal.ScheduledThreadPoolExecutorWithKeepAlive$DelegatingScheduledFuture.run(ScheduledThreadPoolExecutorWithKeepAlive.java:285)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Locked ownable synchronizers:
- java.util.concurrent.ThreadPoolExecutor$Worker@24cd39b5
{noformat}
Impact on running cache operations:
Any operations in progress by the client connected to a locator that was shut
down can take 59 seconds to complete, which is the default socket connect
timeout.
From org.apache.geode.cache.client.PoolFactory:
int DEFAULT_SOCKET_CONNECT_TIMEOUT = 59000;
If the client's connection pool has multiple locators listed, then we can see a
59 second timeout for each of those that has been shut down so an operation
could take minutes to complete.
Here is a stack for such a timeout:
{noformat}
clientgemfire1_881/system.log: [info 2021/07/07 19:48:57.936 GMT
clientgemfire1_host1_881 tid=0x85
[jira] [Updated] (GEODE-9156) Switch from docker-compose to testcontainers
[ https://issues.apache.org/jira/browse/GEODE-9156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-9156: Fix Version/s: 1.15.0 1.14.0 > Switch from docker-compose to testcontainers > > > Key: GEODE-9156 > URL: https://issues.apache.org/jira/browse/GEODE-9156 > Project: Geode > Issue Type: Task > Components: membership >Reporter: Ernest Burghardt >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0, 1.15.0 > > > Palantir docker-compose-rule is sunsetting this month. Palantir advises > switching to testcontainers' docker compose integration. We already use > testcontainer... -- This message was sent by Atlassian Jira (v8.3.4#803005)
