[jira] [Commented] (GEODE-10089) release 1.15.0
[ https://issues.apache.org/jira/browse/GEODE-10089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17499454#comment-17499454 ] ASF subversion and git services commented on GEODE-10089: - Commit dfc5f57d95ee9a7604275e27455e06aa3efcd05d in geode-examples's branch refs/heads/support/1.15 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode-examples.git;h=dfc5f57 ] GEODE-10089: reset after RC0 test This reverts commit 0fcacee2f006ca92bc51906a6791ddb1a7530460. This reverts commit d7974b38c7a35f503bba8fa914b3a2d4fbe75f13. This reverts commit d494b1286a91346cc904b2055cd7ce243efece9a. > release 1.15.0 > -- > > Key: GEODE-10089 > URL: https://issues.apache.org/jira/browse/GEODE-10089 > Project: Geode > Issue Type: Task > Components: release >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > > As per [Jan 25 dev list > discussion|https://lists.apache.org/thread/s9mpd207h40crcr76fpdfmohdchgdqog], > support/1.15 was cut with the intention of stabilizing and releasing a new > Geode minor. > Release status information is also updated in the Geode [Release > Schedule|https://cwiki.apache.org/confluence/display/GEODE/Release+Schedule]. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10087) Enhance Off-heap memory fragmentation visibility
[
https://issues.apache.org/jira/browse/GEODE-10087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-10087:
---
Labels: pull-request-available (was: )
> Enhance Off-heap memory fragmentation visibility
> -
>
> Key: GEODE-10087
> URL: https://issues.apache.org/jira/browse/GEODE-10087
> Project: Geode
> Issue Type: Improvement
> Components: offheap, statistics
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
> Labels: pull-request-available
>
> As pointed out in
> https://cwiki.apache.org/confluence/display/GEODE/Enhance+Off-heap+memory+fragmentation+visibility:
> "Even though Geode offers several stats related to the status of the off-heap
> memory area ({_}usedMemory{_}, {_}freeMemory{_}, {_}fragmentation{_},
> _largestFragment_ and {_}fragments{_}), the ones that provide information
> about the level of the fragmentation of the off-heap memory
> ({_}fragmentation{_}, _largestFragment_ and {_}fragments{_}) are only updated
> when defragmentation is executed."
> The visibility of the off-heap memory fragmentation status must be made more
> visible as proposed in the above RFC by means of:
> * Updating the largestFragment stat periodically.
> * Adding a new off-heap stat called "freedChunks" that will provide the
> number of elements in the tiny and huge lists. This stat will be periodically
> updated.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10048) Create Common Infrastructure for Blocking Commands and Keyspace Event Notifications
[ https://issues.apache.org/jira/browse/GEODE-10048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10048: --- Labels: pull-request-available (was: ) > Create Common Infrastructure for Blocking Commands and Keyspace Event > Notifications > --- > > Key: GEODE-10048 > URL: https://issues.apache.org/jira/browse/GEODE-10048 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Priority: Major > Labels: pull-request-available > > Create the common infrastructure that will be used for implementing both > Redis blocking commands and Keyspace Event Notifications. > > +Acceptance Criteria+ > > The common infrastructure has been implemented along with appropriate unit > testing. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10085) Multiple Locators Not Working in New .NET Test Framework
[
https://issues.apache.org/jira/browse/GEODE-10085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17499609#comment-17499609
]
ASF GitHub Bot commented on GEODE-10085:
pdxcodemonkey commented on a change in pull request #936:
URL: https://github.com/apache/geode-native/pull/936#discussion_r816872113
##
File path: clicache/integration-test2/Cluster.cs
##
@@ -70,8 +70,9 @@ private bool StartLocators()
for (var i = 0; i < locatorCount_; i++)
{
+var startJmxManager = (i == 0);
Review comment:
Okay, a few problems here:
i) I'd really like to do this without introducing a boolean parameter,
though I understand it may be unavoidable.
ii) We don't need a new startJmxManager here, just pass i == 0 as the last
parameter to the locator ctor
iii) This was here before you got to it, but this loop is still broken for
multiple locators, because the success variable is broken. If you start two,
and the first one fails but the second one works, you've buried an error.
Please break out of the for loop if success is false.
--
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
> Multiple Locators Not Working in New .NET Test Framework
>
>
> Key: GEODE-10085
> URL: https://issues.apache.org/jira/browse/GEODE-10085
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Michael Martell
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> If a cluster with more than one locator is used in the new .NET test
> framework, the test will fail. The failure results from trying to start
> JmxManager when it is already running.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9925) Update LICENSE and notice for confluent connector
[ https://issues.apache.org/jira/browse/GEODE-9925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17499650#comment-17499650 ] ASF subversion and git services commented on GEODE-9925: Commit 37992b8d7331cd8d131e5c8ce971763a2f7eb8ca in geode-kafka-connector's branch refs/heads/master from Dan Smith [ https://gitbox.apache.org/repos/asf?p=geode-kafka-connector.git;h=37992b8 ] GEODE-9925: Add LICENSE and NOTICE for binary (#18) The kafka connector binary zip distribution includes apache geode and all it's dependencies, some of which are not apache licensed. Creating a LICENSE and NOTICE for the binary distribution, which are copied from Apache Geodes LICENSE and NOTICE. Changing the build to include these files in the doc directory of the binary distribution. > Update LICENSE and notice for confluent connector > - > > Key: GEODE-9925 > URL: https://issues.apache.org/jira/browse/GEODE-9925 > Project: Geode > Issue Type: Bug > Components: extensions >Reporter: Dan Smith >Priority: Major > Labels: pull-request-available > > The geode-confluent-connector is bundling geode-core and it's third party > dependencies in the binary distribution. The LICENSE and NOTICE for the > binary distribution need to reflect this and include information related to > third party licenses. See the geode-core LICENSE and NOTICE files for example > - > [https://github.com/apache/geode/tree/develop/geode-assembly/src/main/dist.] > Perhaps we can just copy these in the geode-confluent-connectors LICENSE and > NOTICE? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9925) Update LICENSE and notice for confluent connector
[ https://issues.apache.org/jira/browse/GEODE-9925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17499651#comment-17499651 ] ASF GitHub Bot commented on GEODE-9925: --- upthewaterspout merged pull request #18: URL: https://github.com/apache/geode-kafka-connector/pull/18 -- 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 > Update LICENSE and notice for confluent connector > - > > Key: GEODE-9925 > URL: https://issues.apache.org/jira/browse/GEODE-9925 > Project: Geode > Issue Type: Bug > Components: extensions >Reporter: Dan Smith >Priority: Major > Labels: pull-request-available > > The geode-confluent-connector is bundling geode-core and it's third party > dependencies in the binary distribution. The LICENSE and NOTICE for the > binary distribution need to reflect this and include information related to > third party licenses. See the geode-core LICENSE and NOTICE files for example > - > [https://github.com/apache/geode/tree/develop/geode-assembly/src/main/dist.] > Perhaps we can just copy these in the geode-confluent-connectors LICENSE and > NOTICE? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10010) CI: InfoStatsIntegrationTest > opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
[
https://issues.apache.org/jira/browse/GEODE-10010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans resolved GEODE-10010.
-
Fix Version/s: 1.16.0
Resolution: Fixed
> CI: InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> --
>
> Key: GEODE-10010
> URL: https://issues.apache.org/jira/browse/GEODE-10010
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Kristen
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.0836/test-results/integrationTest/1643742213/
> {code:java}
> > Task :geode-for-redis:integrationTest
> InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> java.lang.AssertionError:
> Expecting actual:
> 13.0
> to be close to:
> 19.0
> by less than 4.0 but difference was 6.0.
> (a difference of exactly 4.0 being considered valid)
> at
> org.apache.geode.redis.internal.commands.executor.server.AbstractRedisInfoStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring(AbstractRedisInfoStatsIntegrationTest.java:174)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> ...{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10010) CI: InfoStatsIntegrationTest > opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
[
https://issues.apache.org/jira/browse/GEODE-10010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17499654#comment-17499654
]
ASF subversion and git services commented on GEODE-10010:
-
Commit ea20f2501a620c3b7baa3c621d2f4d21af3bdf58 in geode's branch
refs/heads/develop from Donal Evans
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ea20f25 ]
GEODE-10010: Improve accuracy of per-second Redis stats (#7358)
Code changes:
- Rather than a value that updates once per second, instantaneous
operations per second and instantaneous kilobytes read per second now
return a rolling average of those stats updated 16 times per second
- Introduce RollingAverageStat nested class in RedisStats
Test changes:
- Rename AbstractRedisInfoStatsIntegrationTest to match child classes
- Rather than measuring instantaneous per second stats after
operations have finished, sample them while operations are ongoing and
calculate the expected value based on the number of operations
performed in the one second prior to sampling.
- Change test tolerances from fixed value to 12.5% of expected value
Authored-by: Donal Evans
> CI: InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> --
>
> Key: GEODE-10010
> URL: https://issues.apache.org/jira/browse/GEODE-10010
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Kristen
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.0836/test-results/integrationTest/1643742213/
> {code:java}
> > Task :geode-for-redis:integrationTest
> InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> java.lang.AssertionError:
> Expecting actual:
> 13.0
> to be close to:
> 19.0
> by less than 4.0 but difference was 6.0.
> (a difference of exactly 4.0 being considered valid)
> at
> org.apache.geode.redis.internal.commands.executor.server.AbstractRedisInfoStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring(AbstractRedisInfoStatsIntegrationTest.java:174)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> ...{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10094) NPE could be encountered when accessing index manager if cache is closing
Eric Shu created GEODE-10094: Summary: NPE could be encountered when accessing index manager if cache is closing Key: GEODE-10094 URL: https://issues.apache.org/jira/browse/GEODE-10094 Project: Geode Issue Type: Bug Components: querying Reporter: Eric Shu The following NPE can be seen when creating index on a partitioned region. java.lang.NullPointerException at Remote Member 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' in org.apache.geode.internal.cache.PartitionedRegion.populateEmptyIndexes(PartitionedRegion.java:8601) at Remote Member 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' in org.apache.geode.internal.cache.PartitionedRegion.createIndexes(PartitionedRegion.java:8519) at Remote Member 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' in org.apache.geode.internal.cache.partitioned.IndexCreationMsg.operateOnPartitionedRegion(IndexCreationMsg.java:125) at Remote Member 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' in org.apache.geode.internal.cache.partitioned.IndexCreationMsg.process(IndexCreationMsg.java:288) at Remote Member 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' in org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376) at Remote Member 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' in org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441) at Remote Member 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' in java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at Remote Member 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' in java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at Remote Member 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' in org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:446) at Remote Member 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' in org.apache.geode.distributed.internal.ClusterOperationExecutors.doPartitionRegionThread(ClusterOperationExecutors.java:426) at Remote Member 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' in org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) at Remote Member 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' in java.lang.Thread.run(Thread.java:750) at org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:86) at org.apache.geode.internal.cache.partitioned.PartitionMessage$PartitionResponse.waitForCacheException(PartitionMessage.java:859) at org.apache.geode.internal.cache.partitioned.IndexCreationMsg$IndexCreationResponse.waitForResult(IndexCreationMsg.java:483) at org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8418) at org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8335) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:248) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:206) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:277) at org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:200) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10094) NPE could be encountered when accessing index manager if cache is closing
[ https://issues.apache.org/jira/browse/GEODE-10094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10094: -- Labels: needsTriage (was: ) > NPE could be encountered when accessing index manager if cache is closing > - > > Key: GEODE-10094 > URL: https://issues.apache.org/jira/browse/GEODE-10094 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Eric Shu >Priority: Major > Labels: needsTriage > > The following NPE can be seen when creating index on a partitioned region. > java.lang.NullPointerException > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.PartitionedRegion.populateEmptyIndexes(PartitionedRegion.java:8601) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.PartitionedRegion.createIndexes(PartitionedRegion.java:8519) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.operateOnPartitionedRegion(IndexCreationMsg.java:125) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.process(IndexCreationMsg.java:288) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:446) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.ClusterOperationExecutors.doPartitionRegionThread(ClusterOperationExecutors.java:426) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in java.lang.Thread.run(Thread.java:750) > at > org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:86) > at > org.apache.geode.internal.cache.partitioned.PartitionMessage$PartitionResponse.waitForCacheException(PartitionMessage.java:859) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg$IndexCreationResponse.waitForResult(IndexCreationMsg.java:483) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8418) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8335) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:248) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:206) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:277) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:200) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10094) NPE could be encountered when accessing index manager if cache is closing
[ https://issues.apache.org/jira/browse/GEODE-10094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu reassigned GEODE-10094: Assignee: Eric Shu > NPE could be encountered when accessing index manager if cache is closing > - > > Key: GEODE-10094 > URL: https://issues.apache.org/jira/browse/GEODE-10094 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: needsTriage > > The following NPE can be seen when creating index on a partitioned region. > java.lang.NullPointerException > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.PartitionedRegion.populateEmptyIndexes(PartitionedRegion.java:8601) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.PartitionedRegion.createIndexes(PartitionedRegion.java:8519) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.operateOnPartitionedRegion(IndexCreationMsg.java:125) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.process(IndexCreationMsg.java:288) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:446) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.ClusterOperationExecutors.doPartitionRegionThread(ClusterOperationExecutors.java:426) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in java.lang.Thread.run(Thread.java:750) > at > org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:86) > at > org.apache.geode.internal.cache.partitioned.PartitionMessage$PartitionResponse.waitForCacheException(PartitionMessage.java:859) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg$IndexCreationResponse.waitForResult(IndexCreationMsg.java:483) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8418) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8335) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:248) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:206) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:277) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:200) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10094) NPE could be encountered when accessing index manager if cache is closing
[ https://issues.apache.org/jira/browse/GEODE-10094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10094: - Labels: GeodeOperationAPI (was: needsTriage) > NPE could be encountered when accessing index manager if cache is closing > - > > Key: GEODE-10094 > URL: https://issues.apache.org/jira/browse/GEODE-10094 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI > > The following NPE can be seen when creating index on a partitioned region. > java.lang.NullPointerException > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.PartitionedRegion.populateEmptyIndexes(PartitionedRegion.java:8601) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.PartitionedRegion.createIndexes(PartitionedRegion.java:8519) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.operateOnPartitionedRegion(IndexCreationMsg.java:125) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.process(IndexCreationMsg.java:288) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:446) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.ClusterOperationExecutors.doPartitionRegionThread(ClusterOperationExecutors.java:426) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in java.lang.Thread.run(Thread.java:750) > at > org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:86) > at > org.apache.geode.internal.cache.partitioned.PartitionMessage$PartitionResponse.waitForCacheException(PartitionMessage.java:859) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg$IndexCreationResponse.waitForResult(IndexCreationMsg.java:483) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8418) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8335) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:248) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:206) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:277) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:200) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9512) java.lang.IllegalStateException: Detected old version (pre 5.0.1) of GemFire or non-GemFire during handshake due to initial byte being 1
[
https://issues.apache.org/jira/browse/GEODE-9512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17499672#comment-17499672
]
Kamilla Aslami commented on GEODE-9512:
---
server-1 is in the process of shutting down:
{noformat}
[info 2021/08/16 20:40:23.559 GMT system-test-gemfire-server-1
tid=0x8e] Now closing distribution for
system-test-gemfire-server-1(system-test-gemfire-server-1:1):41000
[info 2021/08/16 20:40:23.559 GMT system-test-gemfire-server-1
tid=0x8e] DistributionManager stopped in 103ms.
{noformat}
The reader (locator-0) receives handshake message sent by server-1. It reads
the message from the buffer and then checks if the sender of the message is in
the view. server-1 wasn't in the view anymore at that time, so the reader logs:
{noformat}
[warn 2021/08/16 20:40:23.858 GMT system-test-gemfire-locator-0 :41000 unshared
ordered sender uid=47 dom #1 local port=58373 remote port=57818> tid=0x87] P2P
message reader@6673b475 timed out during a membership check.{noformat}
The log message comes from this code block in readHandshakeForReceiver():
{noformat}
final String authInit = System.getProperty(SECURITY_SYSTEM_PREFIX +
SECURITY_PEER_AUTH_INIT);
final boolean isSecure = authInit != null && !authInit.isEmpty();
if (isSecure) {
if (owner.getConduit().waitForMembershipCheck(remoteMember)) {
sendOKHandshakeReply();
notifyHandshakeWaiter(true);
} else {
// check if we need notifyHandshakeWaiter() call.
notifyHandshakeWaiter(false);
logger.warn("{} timed out during a membership check.",
p2pReaderName());
return true;
}
} else {{noformat}
If peer authentication is enabled, the receiver checks if the member is in the
view by calling waitForMembershipCheck(). I suspect the idea behind this is
that a node needs to authenticate to join the cluster, and if a sender is in
the view, we can assume that it has been successfully authenticated.If the
membership check failed (=returned false), the receiver calls
notifyHandshakeWaiter(false):
{noformat}
void notifyHandshakeWaiter(boolean success) {
synchronized (handshakeSync) {
if (handshakeRead || handshakeCancelled) {
return;
}
clearSSLInputBuffer();
if (success) {
handshakeRead = true;
} else {
handshakeCancelled = true;
}
handshakeSync.notifyAll();
}
}{noformat}
This method sets either handshakeRead or handshakeCancelled to true and
notifies the handshake waiter about the change. I assume that in our case, the
handshake waiter is system-test-gemfire-server-1 that is in the process of
shutting down and might not receive the notification. In our scenario,
notifyHandshakeWaiter method sets handshakeCancelled = true.
After that, readHandshakeForReceiver returns to the caller -
processInputBuffer. This method has a loop that keeps reading messaged from
buffer until it's empty. In this loop, there's this code block that checks
handshakeRead:
{noformat}
if (handshakeRead) {
try {
readMessage(peerDataBuffer, threadMonitorExecutor);
} catch (SerializationException e) {
logger.info("input buffer startPos {} oldLimit {}", startPos, oldLimit);
throw e;
}
} else {
try (ByteBufferInputStream bbis = new ByteBufferInputStream(peerDataBuffer);
DataInputStream dis = new DataInputStream(bbis)) {
if (!isReceiver) {
readHandshakeForSender(dis, peerDataBuffer);
return;
}
if (readHandshakeForReceiver(dis)) {
ioFilter.doneReading(peerDataBuffer);
return;
}
}
}{noformat}
If handshakeRead is set to true, the method reads a regular message otherwise,
it expects to read the handshake.
So in our case, we already read the handshake by calling
readHandshakeForReceiver once. But readHandshakeForReceiver never set
handshakeRead to true because waitForMembershipCheck failed. So in the next
iteration, processInputBuffer will call readHandshakeForReceiver again (it
doesn't check handshakeCancelled) even if the next message in the buffer isn't
the handshake.Note that if there's nothing to read from the socket after
waitForMembershipCheck failed, we don't get the failure - the connection will
just get closed. But if there was another message after the handshake message,
the receiver will readHandshakeForReceiver again and throw the
IllegalStateException.
To fix this issue, we should close the connection from the receiving side if
waitForMembershipCheck failed, i.e:
{noformat}
if (owner.getConduit().waitForMembershipCheck(remoteMember)) {
sendOKHandshakeReply();
notifyHandshakeWaiter(true);
} else {
// check if we need notifyHandshakeWaiter() call.
notifyHandshakeWaiter(false);
==> requestClose(p2pReaderName() + "timed out during a membership check.");
return true;
}
{noformat}
> java.lang.
[jira] [Comment Edited] (GEODE-9512) java.lang.IllegalStateException: Detected old version (pre 5.0.1) of GemFire or non-GemFire during handshake due to initial byte being 1
[
https://issues.apache.org/jira/browse/GEODE-9512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17499672#comment-17499672
]
Kamilla Aslami edited comment on GEODE-9512 at 3/1/22, 5:31 PM:
server-1 is in the process of shutting down:
{noformat}
[info 2021/08/16 20:40:23.559 GMT system-test-gemfire-server-1
tid=0x8e] Now closing distribution for
system-test-gemfire-server-1(system-test-gemfire-server-1:1):41000
[info 2021/08/16 20:40:23.559 GMT system-test-gemfire-server-1
tid=0x8e] DistributionManager stopped in 103ms.
{noformat}
The reader (locator-0) receives handshake message sent by server-1. It reads
the message from the buffer and then checks if the sender of the message is in
the view. server-1 wasn't in the view anymore at that time, so the reader logs:
{noformat}
[warn 2021/08/16 20:40:23.858 GMT system-test-gemfire-locator-0 :41000 unshared
ordered sender uid=47 dom #1 local port=58373 remote port=57818> tid=0x87] P2P
message reader@6673b475 timed out during a membership check.{noformat}
The log message comes from this code block in readHandshakeForReceiver():
{noformat}
final String authInit = System.getProperty(SECURITY_SYSTEM_PREFIX +
SECURITY_PEER_AUTH_INIT);
final boolean isSecure = authInit != null && !authInit.isEmpty();
if (isSecure) {
if (owner.getConduit().waitForMembershipCheck(remoteMember)) {
sendOKHandshakeReply();
notifyHandshakeWaiter(true);
} else {
// check if we need notifyHandshakeWaiter() call.
notifyHandshakeWaiter(false);
logger.warn("{} timed out during a membership check.",
p2pReaderName());
return true;
}
} else {{noformat}
If peer authentication is enabled, the receiver checks if the member is in the
view by calling waitForMembershipCheck(). I suspect the idea behind this is
that a node needs to authenticate to join the cluster, and if a sender is in
the view, we can assume that it has been successfully authenticated.If the
membership check failed (=returned false), the receiver calls
notifyHandshakeWaiter(false):
{noformat}
void notifyHandshakeWaiter(boolean success) {
synchronized (handshakeSync) {
if (handshakeRead || handshakeCancelled) {
return;
}
clearSSLInputBuffer();
if (success) {
handshakeRead = true;
} else {
handshakeCancelled = true;
}
handshakeSync.notifyAll();
}
}{noformat}
This method sets either handshakeRead or handshakeCancelled to true and
notifies the handshake waiter about the change. I assume that in our case, the
handshake waiter is system-test-gemfire-server-1 that is in the process of
shutting down and might not receive the notification. In our scenario,
notifyHandshakeWaiter method sets handshakeCancelled = true.
After that, readHandshakeForReceiver returns to the caller -
processInputBuffer. This method has a loop that keeps reading messaged from
buffer until it's empty. In this loop, there's this code block that checks
handshakeRead:
{noformat}
if (handshakeRead) {
try {
readMessage(peerDataBuffer, threadMonitorExecutor);
} catch (SerializationException e) {
logger.info("input buffer startPos {} oldLimit {}", startPos, oldLimit);
throw e;
}
} else {
try (ByteBufferInputStream bbis = new ByteBufferInputStream(peerDataBuffer);
DataInputStream dis = new DataInputStream(bbis)) {
if (!isReceiver) {
readHandshakeForSender(dis, peerDataBuffer);
return;
}
if (readHandshakeForReceiver(dis)) {
ioFilter.doneReading(peerDataBuffer);
return;
}
}
}{noformat}
If handshakeRead is set to true, the method reads a regular message otherwise,
it expects to read the handshake.
So in our case, we already read the handshake by calling
readHandshakeForReceiver once. But readHandshakeForReceiver never set
handshakeRead to true because waitForMembershipCheck failed. So in the next
iteration, processInputBuffer will call readHandshakeForReceiver again (it
doesn't check handshakeCancelled) even if the next message in the buffer isn't
the handshake.Note that if there's nothing to read from the socket after
waitForMembershipCheck failed, we don't get the failure - the connection will
just get closed. But if there was another message after the handshake message,
the receiver will readHandshakeForReceiver again and throw the
IllegalStateException.
To fix this issue, we should close the connection from the receiving side if
waitForMembershipCheck failed, i.e:
{noformat}
if (owner.getConduit().waitForMembershipCheck(remoteMember)) {
sendOKHandshakeReply();
notifyHandshakeWaiter(true);
} else {
// check if we need notifyHandshakeWaiter() call.
notifyHandshakeWaiter(false);
==> requestClose(p2pReaderName() + "timed out during a membership check.");
retur
[jira] [Updated] (GEODE-9512) java.lang.IllegalStateException: Detected old version (pre 5.0.1) of GemFire or non-GemFire during handshake due to initial byte being 1
[
https://issues.apache.org/jira/browse/GEODE-9512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9512:
--
Labels: pull-request-available (was: )
> java.lang.IllegalStateException: Detected old version (pre 5.0.1) of GemFire
> or non-GemFire during handshake due to initial byte being 1
>
>
> Key: GEODE-9512
> URL: https://issues.apache.org/jira/browse/GEODE-9512
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Affects Versions: 1.15.0
>Reporter: Juan Ramos
>Assignee: Kamilla Aslami
>Priority: Major
> Labels: pull-request-available
>
> I've hit this issue while executing some chaos testing over a GemFire cluster
> using 2 locators and 3 servers; {{SSL}} is enabled, and a dummy
> {{SecurityManager}} is configured which authenticates any user and always
> returns {{true}} within the {{authorize}} method. There are 3
> {{PARTITION_REDUNDANT}} regions configured, one per client, each with 1
> redundant copy. Once the cluster is up and running, 3 clients continuously
> execute {{Region.put}} operations on a well known set of keys for its own
> {{Region}} (created with {{PROXY}} type), and another process executes the
> following logic in parallel (pseudocode):
> {noformat}
> for server in ${servers}
> do
> # Pause the JVM for 30 seconds to simulate a stop the world GC
> kill -STOP server
> sleep 30
> # Unpause the JVM, wait for member to reconnect and regions to recover
> redundancy configured
> kill -CONT "${SERVER_PID}"
> waitForReconnectcompletedInServerLog
> waitForNumBucketsWithoutRedundancyToBeZeroInGfshShowRegionMetrics
> done
> {noformat}
> The test works fine most of the time, but randomly fails due to an unexpected
> exception logged within the logs for at least one locator. The exception is
> always reported from a {{P2P message reader}} thread on the locator for a
> server member that has just returned to life, as an example:
> {noformat}
> LOCATOR-0
> [warn 2021/08/17 05:20:45.166 GMT system-test-gemfire-locator-0 reader for
> system-test-gemfire-server-2(system-test-gemfire-server-2:1):41000
> unshared ordered sender uid=61 dom #1 local port=48141 remote port=46174>
> tid=0x6f] P2P message reader@354fac47 timed out during a membership check.
> [fatal 2021/08/17 05:20:45.166 GMT system-test-gemfire-locator-0 reader for
> system-test-gemfire-server-2(system-test-gemfire-server-2:1):41000
> unshared ordered sender uid=61 dom #1 local port=48141 remote port=46174>
> tid=0x6f] Error deserializing P2P handshake message
> java.lang.IllegalStateException: Detected old version (pre 5.0.1) of GemFire
> or non-GemFire during handshake due to initial byte being 1
> at
> org.apache.geode.internal.tcp.Connection.readHandshakeForReceiver(Connection.java:2875)
> at
> org.apache.geode.internal.tcp.Connection.processInputBuffer(Connection.java:2825)
> at
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1649)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1489)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
> SERVER-2
> [warn 2021/08/17 05:20:44.012 GMT system-test-gemfire-server-2
> tid=0x35] Statistics sampling thread detected a wakeup delay of 29070 ms,
> indicating a possible resource issue. Check the GC, memory, and CPU
> statistics.
> [warn 2021/08/17 05:20:44.015 GMT system-test-gemfire-server-2 Heartbeat Sender> tid=0x23] Failure detection heartbeat-generation thread
> overslept by more than a full period. Asleep time: 31,175,291,931
> nanoseconds. Period: 2,500,000,000 nanoseconds.
> [info 2021/08/17 05:20:44.143 GMT system-test-gemfire-server-2 receiver,system-test-gemfire-server-2-25596> tid=0x1e] saving cache server
> configuration for use with the cluster-configuration service on reconnect
> [info 2021/08/17 05:20:44.143 GMT system-test-gemfire-server-2 receiver,system-test-gemfire-server-2-25596> tid=0x1e] cache server
> configuration saved
> [info 2021/08/17 05:20:44.233 GMT system-test-gemfire-server-2
> tid=0xe5] Stopping membership services
> [info 2021/08/17 05:20:44.455 GMT system-test-gemfire-server-2
> tid=0xe5] Disconnecting old DistributedSystem to prepare
> for a reconnect attempt
> [info 2021/08/17 05:20:44.463 GMT system-test-gemfire-server-2
> tid=0xe5] GemFireCache[id = 252990056; isClosing = true;
> isShutDownAll = false; created = Tue Aug 17 05:
[jira] [Resolved] (GEODE-9925) Update LICENSE and notice for confluent connector
[ https://issues.apache.org/jira/browse/GEODE-9925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-9925. -- Assignee: Dan Smith Resolution: Fixed > Update LICENSE and notice for confluent connector > - > > Key: GEODE-9925 > URL: https://issues.apache.org/jira/browse/GEODE-9925 > Project: Geode > Issue Type: Bug > Components: extensions >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available > > The geode-confluent-connector is bundling geode-core and it's third party > dependencies in the binary distribution. The LICENSE and NOTICE for the > binary distribution need to reflect this and include information related to > third party licenses. See the geode-core LICENSE and NOTICE files for example > - > [https://github.com/apache/geode/tree/develop/geode-assembly/src/main/dist.] > Perhaps we can just copy these in the geode-confluent-connectors LICENSE and > NOTICE? -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10085) Multiple Locators Not Working in New .NET Test Framework
[
https://issues.apache.org/jira/browse/GEODE-10085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17499678#comment-17499678
]
ASF GitHub Bot commented on GEODE-10085:
mmartell commented on a change in pull request #936:
URL: https://github.com/apache/geode-native/pull/936#discussion_r817006325
##
File path: clicache/integration-test2/Cluster.cs
##
@@ -70,8 +70,9 @@ private bool StartLocators()
for (var i = 0; i < locatorCount_; i++)
{
+var startJmxManager = (i == 0);
Review comment:
i) You can't start the JmxManager in gfsh independent of a locator.
iii) Good catch!
--
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
> Multiple Locators Not Working in New .NET Test Framework
>
>
> Key: GEODE-10085
> URL: https://issues.apache.org/jira/browse/GEODE-10085
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Michael Martell
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> If a cluster with more than one locator is used in the new .NET test
> framework, the test will fail. The failure results from trying to start
> JmxManager when it is already running.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10085) Multiple Locators Not Working in New .NET Test Framework
[
https://issues.apache.org/jira/browse/GEODE-10085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17499679#comment-17499679
]
ASF GitHub Bot commented on GEODE-10085:
mmartell commented on a change in pull request #936:
URL: https://github.com/apache/geode-native/pull/936#discussion_r817006325
##
File path: clicache/integration-test2/Cluster.cs
##
@@ -70,8 +70,9 @@ private bool StartLocators()
for (var i = 0; i < locatorCount_; i++)
{
+var startJmxManager = (i == 0);
Review comment:
i) You can't start the JmxManager in gfsh independent of a locator.
iii) Good catch! StartServers() has same issue. Fixed that one also.
--
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
> Multiple Locators Not Working in New .NET Test Framework
>
>
> Key: GEODE-10085
> URL: https://issues.apache.org/jira/browse/GEODE-10085
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Michael Martell
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> If a cluster with more than one locator is used in the new .NET test
> framework, the test will fail. The failure results from trying to start
> JmxManager when it is already running.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10093) DeltaSession getAttribute method logs an NPE and returns unserialized value when called on attribute with null value
[ https://issues.apache.org/jira/browse/GEODE-10093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett updated GEODE-10093: -- Affects Version/s: 1.14.0 1.13.3 1.12.2 1.16.0 (was: 1.12.7) (was: 1.13.7) (was: 1.14.3) > DeltaSession getAttribute method logs an NPE and returns unserialized value > when called on attribute with null value > > > Key: GEODE-10093 > URL: https://issues.apache.org/jira/browse/GEODE-10093 > Project: Geode > Issue Type: Bug > Components: http session >Affects Versions: 1.12.2, 1.13.3, 1.14.0, 1.15.0, 1.16.0 >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > Labels: needsTriage, pull-request-available > > Under certain circumstances, a null value can be set for an attribute which > then throws an NPE when trying to add it to the local map during a > getAttribute call on the session. Prior to 1.12.2 we were responding to this > by removing the entry entirely from the local map which is consistent with > what the base Session class for Catalina does, but starting with 1.12.2 > onward this results in an error message being displayed and the serialized > value being returned rather than the unserialized value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10093) DeltaSession getAttribute method logs an NPE and returns unserialized value when called on attribute with null value
[
https://issues.apache.org/jira/browse/GEODE-10093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17499694#comment-17499694
]
Jacob Barrett commented on GEODE-10093:
---
Changes made in GEODE-8217 exposed incorrect handling of {{null}} values in
{{DeltaSession.setAttribute}}.
> DeltaSession getAttribute method logs an NPE and returns unserialized value
> when called on attribute with null value
>
>
> Key: GEODE-10093
> URL: https://issues.apache.org/jira/browse/GEODE-10093
> Project: Geode
> Issue Type: Bug
> Components: http session
>Affects Versions: 1.12.2, 1.13.3, 1.14.0, 1.15.0, 1.16.0
>Reporter: Benjamin P Ross
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> Under certain circumstances, a null value can be set for an attribute which
> then throws an NPE when trying to add it to the local map during a
> getAttribute call on the session. Prior to 1.12.2 we were responding to this
> by removing the entry entirely from the local map which is consistent with
> what the base Session class for Catalina does, but starting with 1.12.2
> onward this results in an error message being displayed and the serialized
> value being returned rather than the unserialized value.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10095) TcrConnection::readHandshakeData reads too many bytes
Blake Bender created GEODE-10095: Summary: TcrConnection::readHandshakeData reads too many bytes Key: GEODE-10095 URL: https://issues.apache.org/jira/browse/GEODE-10095 Project: Geode Issue Type: Bug Components: native client Reporter: Blake Bender This method is called to read bytes from a socket, and return said data in a `std::vector`. For some inexplicable (inexcusable?) reason, the method always adds a 0 byte to the end of the vector, as if it were null-terminating a string. So, `readHandshakeData(1)` returns 2 bytes, `readHandshakeData(5)` returns 6 bytes, etc. This is extremely misleading, given the name of the method and the fact that the requested number of bytes is a parameter passed in. Also, in no circumstance is this method used to actually read a string, i.e. something that may require null-termination. Please remove the extra byte from the returned vector, and if possible add a unit test to the suite that reads _n_ bytes and asserts that the method always returns _n_ bytes. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10095) TcrConnection::readHandshakeData reads too many bytes
[ https://issues.apache.org/jira/browse/GEODE-10095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10095: -- Labels: needsTriage (was: ) > TcrConnection::readHandshakeData reads too many bytes > - > > Key: GEODE-10095 > URL: https://issues.apache.org/jira/browse/GEODE-10095 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Priority: Major > Labels: needsTriage > > This method is called to read bytes from a socket, and return said data in a > `std::vector`. For some inexplicable (inexcusable?) reason, the > method always adds a 0 byte to the end of the vector, as if it were > null-terminating a string. So, `readHandshakeData(1)` returns 2 bytes, > `readHandshakeData(5)` returns 6 bytes, etc. > This is extremely misleading, given the name of the method and the fact that > the requested number of bytes is a parameter passed in. Also, in no > circumstance is this method used to actually read a string, i.e. something > that may require null-termination. Please remove the extra byte from the > returned vector, and if possible add a unit test to the suite that reads _n_ > bytes and asserts that the method always returns _n_ bytes. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10095) TcrConnection::readHandshakeData reads too many bytes
[ https://issues.apache.org/jira/browse/GEODE-10095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender reassigned GEODE-10095: Assignee: Matthew Reddington > TcrConnection::readHandshakeData reads too many bytes > - > > Key: GEODE-10095 > URL: https://issues.apache.org/jira/browse/GEODE-10095 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Assignee: Matthew Reddington >Priority: Major > Labels: needsTriage > > This method is called to read bytes from a socket, and return said data in a > `std::vector`. For some inexplicable (inexcusable?) reason, the > method always adds a 0 byte to the end of the vector, as if it were > null-terminating a string. So, `readHandshakeData(1)` returns 2 bytes, > `readHandshakeData(5)` returns 6 bytes, etc. > This is extremely misleading, given the name of the method and the fact that > the requested number of bytes is a parameter passed in. Also, in no > circumstance is this method used to actually read a string, i.e. something > that may require null-termination. Please remove the extra byte from the > returned vector, and if possible add a unit test to the suite that reads _n_ > bytes and asserts that the method always returns _n_ bytes. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10094) NPE could be encountered when accessing index manager if cache is closing
[ https://issues.apache.org/jira/browse/GEODE-10094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10094: --- Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI) > NPE could be encountered when accessing index manager if cache is closing > - > > Key: GEODE-10094 > URL: https://issues.apache.org/jira/browse/GEODE-10094 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > The following NPE can be seen when creating index on a partitioned region. > java.lang.NullPointerException > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.PartitionedRegion.populateEmptyIndexes(PartitionedRegion.java:8601) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.PartitionedRegion.createIndexes(PartitionedRegion.java:8519) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.operateOnPartitionedRegion(IndexCreationMsg.java:125) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.process(IndexCreationMsg.java:288) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:446) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.ClusterOperationExecutors.doPartitionRegionThread(ClusterOperationExecutors.java:426) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in java.lang.Thread.run(Thread.java:750) > at > org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:86) > at > org.apache.geode.internal.cache.partitioned.PartitionMessage$PartitionResponse.waitForCacheException(PartitionMessage.java:859) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg$IndexCreationResponse.waitForResult(IndexCreationMsg.java:483) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8418) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8335) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:248) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:206) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:277) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:200) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10083) Fix RedisProxy to correctly process MOVED responses
[ https://issues.apache.org/jira/browse/GEODE-10083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-10083. Fix Version/s: 1.16.0 Resolution: Fixed > Fix RedisProxy to correctly process MOVED responses > --- > > Key: GEODE-10083 > URL: https://issues.apache.org/jira/browse/GEODE-10083 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.16.0 > > > The RedisProxy test helper rewrites various redis responses to allow for > address translation when using a docker-based redis cluster. Due to the way > the internal netty processing pipeline was constructed, a received MOVED > response could have disrupted subsequent requests flowing through the proxy. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10093) DeltaSession getAttribute method logs an NPE and returns unserialized value when called on attribute with null value
[ https://issues.apache.org/jira/browse/GEODE-10093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17499779#comment-17499779 ] ASF subversion and git services commented on GEODE-10093: - Commit e040759cd1e42df377501cd423967d549ce2bfab in geode's branch refs/heads/develop from BenjaminPerryRoss [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e040759 ] GEODE-10093 - Fixed attr issue in Delta Session (#7405) * GEODE-10093 - Fixed attr issue in Delta Session > DeltaSession getAttribute method logs an NPE and returns unserialized value > when called on attribute with null value > > > Key: GEODE-10093 > URL: https://issues.apache.org/jira/browse/GEODE-10093 > Project: Geode > Issue Type: Bug > Components: http session >Affects Versions: 1.12.2, 1.13.3, 1.14.0, 1.15.0, 1.16.0 >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > Labels: needsTriage, pull-request-available > > Under certain circumstances, a null value can be set for an attribute which > then throws an NPE when trying to add it to the local map during a > getAttribute call on the session. Prior to 1.12.2 we were responding to this > by removing the entry entirely from the local map which is consistent with > what the base Session class for Catalina does, but starting with 1.12.2 > onward this results in an error message being displayed and the serialized > value being returned rather than the unserialized value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Reopened] (GEODE-10010) CI: InfoStatsIntegrationTest > opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
[
https://issues.apache.org/jira/browse/GEODE-10010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans reopened GEODE-10010:
-
Reopening as the original fix caused Windows tests to fail
> CI: InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> --
>
> Key: GEODE-10010
> URL: https://issues.apache.org/jira/browse/GEODE-10010
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Kristen
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.0836/test-results/integrationTest/1643742213/
> {code:java}
> > Task :geode-for-redis:integrationTest
> InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> java.lang.AssertionError:
> Expecting actual:
> 13.0
> to be close to:
> 19.0
> by less than 4.0 but difference was 6.0.
> (a difference of exactly 4.0 being considered valid)
> at
> org.apache.geode.redis.internal.commands.executor.server.AbstractRedisInfoStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring(AbstractRedisInfoStatsIntegrationTest.java:174)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> ...{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10096) Handshake "acceptance codes" should be an enum class
Blake Bender created GEODE-10096:
Summary: Handshake "acceptance codes" should be an enum class
Key: GEODE-10096
URL: https://issues.apache.org/jira/browse/GEODE-10096
Project: Geode
Issue Type: Improvement
Components: native client
Reporter: Blake Bender
In the method `TcrConnection::initTcrConnection`, the following block of code
appears:
```
switch (acceptanceCode[0]) {
case REPLY_OK:
case SUCCESSFUL_SERVER_TO_CLIENT:
LOGFINER("Handshake reply: %u,%u,%u", acceptanceCode[0],
serverQueueStatus[0], recvMsgLen2);
if (isClientNotification) readHandshakeInstantiatorMsg(connectTimeout);
break;
case REPLY_AUTHENTICATION_FAILED: {
AuthenticationFailedException ex(
reinterpret_cast(recvMessage.data()));
m_conn.reset();
throwException(ex);
}
case REPLY_AUTHENTICATION_REQUIRED: {
AuthenticationRequiredException ex(
reinterpret_cast(recvMessage.data()));
m_conn.reset();
throwException(ex);
}
case REPLY_DUPLICATE_DURABLE_CLIENT: {
DuplicateDurableClientException ex(
reinterpret_cast(recvMessage.data()));
m_conn.reset();
throwException(ex);
}
case REPLY_REFUSED:
case REPLY_INVALID:
case UNSUCCESSFUL_SERVER_TO_CLIENT: {
LOGERROR("Handshake rejected by server[%s]: %s",
m_endpointObj->name().c_str(),
reinterpret_cast(recvMessage.data()));
auto message = std::string("TcrConnection::TcrConnection: ") +
"Handshake rejected by server: " +
reinterpret_cast(recvMessage.data());
CacheServerException ex(message);
m_conn.reset();
throw ex;
}
```
These response codes are unique to the server handshake, and not used anywhere
else in the code. We need to remove the `#define`s for them and put them in a
proper `enum class`.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10096) Handshake "acceptance codes" should be an enum class
[
https://issues.apache.org/jira/browse/GEODE-10096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Bender updated GEODE-10096:
-
Description:
In the method TcrConnection::initTcrConnection, the following block of code
appears:
{code:java}
switch (acceptanceCode[0]) {
case REPLY_OK:
case SUCCESSFUL_SERVER_TO_CLIENT:
LOGFINER("Handshake reply: %u,%u,%u", acceptanceCode[0],
serverQueueStatus[0], recvMsgLen2);
if (isClientNotification) readHandshakeInstantiatorMsg(connectTimeout);
break;
case REPLY_AUTHENTICATION_FAILED: {
AuthenticationFailedException ex(
reinterpret_cast(recvMessage.data()));
m_conn.reset();
throwException(ex);
}
case REPLY_AUTHENTICATION_REQUIRED: {
AuthenticationRequiredException ex(
reinterpret_cast(recvMessage.data()));
m_conn.reset();
throwException(ex);
}
case REPLY_DUPLICATE_DURABLE_CLIENT: {
DuplicateDurableClientException ex(
reinterpret_cast(recvMessage.data()));
m_conn.reset();
throwException(ex);
}
case REPLY_REFUSED:
case REPLY_INVALID:
case UNSUCCESSFUL_SERVER_TO_CLIENT: {
LOGERROR("Handshake rejected by server[%s]: %s",
m_endpointObj->name().c_str(),
reinterpret_cast(recvMessage.data()));
auto message = std::string("TcrConnection::TcrConnection: ") +
"Handshake rejected by server: " +
reinterpret_cast(recvMessage.data());
CacheServerException ex(message);
m_conn.reset();
throw ex;
}
{code}
These response codes are unique to the server handshake, and not used anywhere
else in the code. We need to remove the #definess for them and put them in a
proper enum class.
was:
In the method `TcrConnection::initTcrConnection`, the following block of code
appears:
```
switch (acceptanceCode[0]) {
case REPLY_OK:
case SUCCESSFUL_SERVER_TO_CLIENT:
LOGFINER("Handshake reply: %u,%u,%u", acceptanceCode[0],
serverQueueStatus[0], recvMsgLen2);
if (isClientNotification) readHandshakeInstantiatorMsg(connectTimeout);
break;
case REPLY_AUTHENTICATION_FAILED: {
AuthenticationFailedException ex(
reinterpret_cast(recvMessage.data()));
m_conn.reset();
throwException(ex);
}
case REPLY_AUTHENTICATION_REQUIRED: {
AuthenticationRequiredException ex(
reinterpret_cast(recvMessage.data()));
m_conn.reset();
throwException(ex);
}
case REPLY_DUPLICATE_DURABLE_CLIENT: {
DuplicateDurableClientException ex(
reinterpret_cast(recvMessage.data()));
m_conn.reset();
throwException(ex);
}
case REPLY_REFUSED:
case REPLY_INVALID:
case UNSUCCESSFUL_SERVER_TO_CLIENT: {
LOGERROR("Handshake rejected by server[%s]: %s",
m_endpointObj->name().c_str(),
reinterpret_cast(recvMessage.data()));
auto message = std::string("TcrConnection::TcrConnection: ") +
"Handshake rejected by server: " +
reinterpret_cast(recvMessage.data());
CacheServerException ex(message);
m_conn.reset();
throw ex;
}
```
These response codes are unique to the server handshake, and not used anywhere
else in the code. We need to remove the `#define`s for them and put them in a
proper `enum class`.
> Handshake "acceptance codes" should be an enum class
>
>
> Key: GEODE-10096
> URL: https://issues.apache.org/jira/browse/GEODE-10096
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Blake Bender
>Priority: Major
>
> In the method TcrConnection::initTcrConnection, the following block of code
> appears:
> {code:java}
> switch (acceptanceCode[0]) {
> case REPLY_OK:
> case SUCCESSFUL_SERVER_TO_CLIENT:
> LOGFINER("Handshake reply: %u,%u,%u", acceptanceCode[0],
> serverQueueStatus[0], recvMsgLen2);
> if (isClientNotification)
> readHandshakeInstantiatorMsg(connectTimeout);
> break;
> case REPLY_AUTHENTICATION_FAILED: {
> AuthenticationFailedException ex(
> reinterpret_cast(recvMessage.data()));
> m_conn.reset();
> throwException(ex);
> }
> case REPLY_AUTHENTICATION_REQUIRED: {
> AuthenticationRequiredException ex(
> reinterpret_cast(recvMessage.data()));
> m_conn.reset();
> throwException(ex);
> }
> case REPLY_DUPLICATE_DURABLE_CLIENT: {
> DuplicateDurableClientException ex(
>
[jira] [Updated] (GEODE-10096) Handshake "acceptance codes" should be an enum class
[
https://issues.apache.org/jira/browse/GEODE-10096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Bender updated GEODE-10096:
-
Description:
In the method TcrConnection::initTcrConnection, the following block of code
appears:
{code:java}
switch (acceptanceCode[0]) {
case REPLY_OK:
case SUCCESSFUL_SERVER_TO_CLIENT:
LOGFINER("Handshake reply: %u,%u,%u", acceptanceCode[0],
serverQueueStatus[0], recvMsgLen2);
if (isClientNotification) readHandshakeInstantiatorMsg(connectTimeout);
break;
case REPLY_AUTHENTICATION_FAILED: {
AuthenticationFailedException ex(
reinterpret_cast(recvMessage.data()));
m_conn.reset();
throwException(ex);
}
case REPLY_AUTHENTICATION_REQUIRED: {
AuthenticationRequiredException ex(
reinterpret_cast(recvMessage.data()));
m_conn.reset();
throwException(ex);
}
case REPLY_DUPLICATE_DURABLE_CLIENT: {
DuplicateDurableClientException ex(
reinterpret_cast(recvMessage.data()));
m_conn.reset();
throwException(ex);
}
case REPLY_REFUSED:
case REPLY_INVALID:
case UNSUCCESSFUL_SERVER_TO_CLIENT: {
LOGERROR("Handshake rejected by server[%s]: %s",
m_endpointObj->name().c_str(),
reinterpret_cast(recvMessage.data()));
auto message = std::string("TcrConnection::TcrConnection: ") +
"Handshake rejected by server: " +
reinterpret_cast(recvMessage.data());
CacheServerException ex(message);
m_conn.reset();
throw ex;
}
{code}
These response codes are unique to the server handshake, and not used anywhere
else in the code. We need to remove the #defines for them and put them in a
proper enum class.
was:
In the method TcrConnection::initTcrConnection, the following block of code
appears:
{code:java}
switch (acceptanceCode[0]) {
case REPLY_OK:
case SUCCESSFUL_SERVER_TO_CLIENT:
LOGFINER("Handshake reply: %u,%u,%u", acceptanceCode[0],
serverQueueStatus[0], recvMsgLen2);
if (isClientNotification) readHandshakeInstantiatorMsg(connectTimeout);
break;
case REPLY_AUTHENTICATION_FAILED: {
AuthenticationFailedException ex(
reinterpret_cast(recvMessage.data()));
m_conn.reset();
throwException(ex);
}
case REPLY_AUTHENTICATION_REQUIRED: {
AuthenticationRequiredException ex(
reinterpret_cast(recvMessage.data()));
m_conn.reset();
throwException(ex);
}
case REPLY_DUPLICATE_DURABLE_CLIENT: {
DuplicateDurableClientException ex(
reinterpret_cast(recvMessage.data()));
m_conn.reset();
throwException(ex);
}
case REPLY_REFUSED:
case REPLY_INVALID:
case UNSUCCESSFUL_SERVER_TO_CLIENT: {
LOGERROR("Handshake rejected by server[%s]: %s",
m_endpointObj->name().c_str(),
reinterpret_cast(recvMessage.data()));
auto message = std::string("TcrConnection::TcrConnection: ") +
"Handshake rejected by server: " +
reinterpret_cast(recvMessage.data());
CacheServerException ex(message);
m_conn.reset();
throw ex;
}
{code}
These response codes are unique to the server handshake, and not used anywhere
else in the code. We need to remove the #definess for them and put them in a
proper enum class.
> Handshake "acceptance codes" should be an enum class
>
>
> Key: GEODE-10096
> URL: https://issues.apache.org/jira/browse/GEODE-10096
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Blake Bender
>Priority: Major
>
> In the method TcrConnection::initTcrConnection, the following block of code
> appears:
> {code:java}
> switch (acceptanceCode[0]) {
> case REPLY_OK:
> case SUCCESSFUL_SERVER_TO_CLIENT:
> LOGFINER("Handshake reply: %u,%u,%u", acceptanceCode[0],
> serverQueueStatus[0], recvMsgLen2);
> if (isClientNotification)
> readHandshakeInstantiatorMsg(connectTimeout);
> break;
> case REPLY_AUTHENTICATION_FAILED: {
> AuthenticationFailedException ex(
> reinterpret_cast(recvMessage.data()));
> m_conn.reset();
> throwException(ex);
> }
> case REPLY_AUTHENTICATION_REQUIRED: {
> AuthenticationRequiredException ex(
> reinterpret_cast(recvMessage.data()));
> m_conn.reset();
> throwException(ex);
> }
> case REPLY_DUPLICATE_DURABLE_CLIENT: {
> DuplicateDurableClientException ex(
>
[jira] [Resolved] (GEODE-10075) Fix support for jacoco code coverage in Geode build
[ https://issues.apache.org/jira/browse/GEODE-10075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-10075. --- Resolution: Fixed > Fix support for jacoco code coverage in Geode build > --- > > Key: GEODE-10075 > URL: https://issues.apache.org/jira/browse/GEODE-10075 > Project: Geode > Issue Type: Bug > Components: build >Reporter: Dan Smith >Priority: Major > Labels: pull-request-available > > We haven't been maintaining this gradle build support, but it is useful to be > able to get code coverage from distributed test runs, eg. > ./gradlew geode-core:distributedTest -PcodeCoverage --tests XXX > geode-core:jacocoDistributedTestReport > If you pass -PcodeCoverage it's currently failing. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10075) Fix support for jacoco code coverage in Geode build
[ https://issues.apache.org/jira/browse/GEODE-10075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17499795#comment-17499795 ] ASF subversion and git services commented on GEODE-10075: - Commit 3551b8dc650c939d7832580dc9d24e11b95dc79e in geode's branch refs/heads/develop from Dan Smith [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3551b8d ] GEODE-10075 Fix jacoco code coverage reports We haven't been maintaining this gradle build support, but it is useful to be able to get code coverage from distributed test runs, eg. ./gradlew geode-core:distributedTest -PcodeCoverage --tests XXX geode-core:jacocoDistributedTestReport Changes: * Upgraded the jacoco report tasks to use the newer syntax for locations * Changed our WorkingDirectoryIsolator to fix the relative paths to the jacoco agent and execution trace files. It's hard for me to tell if gradle is actually using windows or unix paths when running on Windows. Just to be sure, adding support for both types of paths for this change and adding a unit test of WorkingDirectoryIsolator. > Fix support for jacoco code coverage in Geode build > --- > > Key: GEODE-10075 > URL: https://issues.apache.org/jira/browse/GEODE-10075 > Project: Geode > Issue Type: Bug > Components: build >Reporter: Dan Smith >Priority: Major > Labels: pull-request-available > > We haven't been maintaining this gradle build support, but it is useful to be > able to get code coverage from distributed test runs, eg. > ./gradlew geode-core:distributedTest -PcodeCoverage --tests XXX > geode-core:jacocoDistributedTestReport > If you pass -PcodeCoverage it's currently failing. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10010) CI: InfoStatsIntegrationTest > opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
[
https://issues.apache.org/jira/browse/GEODE-10010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17499813#comment-17499813
]
ASF subversion and git services commented on GEODE-10010:
-
Commit 7289a1cc2d14dca67a610a5684f40c39787da1e2 in geode's branch
refs/heads/develop from Donal Evans
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=7289a1c ]
Revert "GEODE-10010: Improve accuracy of per-second Redis stats (#7358)" (#7415)
This reverts commit ea20f2501a620c3b7baa3c621d2f4d21af3bdf58.
> CI: InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> --
>
> Key: GEODE-10010
> URL: https://issues.apache.org/jira/browse/GEODE-10010
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Kristen
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.0836/test-results/integrationTest/1643742213/
> {code:java}
> > Task :geode-for-redis:integrationTest
> InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> java.lang.AssertionError:
> Expecting actual:
> 13.0
> to be close to:
> 19.0
> by less than 4.0 but difference was 6.0.
> (a difference of exactly 4.0 being considered valid)
> at
> org.apache.geode.redis.internal.commands.executor.server.AbstractRedisInfoStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring(AbstractRedisInfoStatsIntegrationTest.java:174)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> ...{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10010) CI: InfoStatsIntegrationTest > opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
[
https://issues.apache.org/jira/browse/GEODE-10010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17499847#comment-17499847
]
Geode Integration commented on GEODE-10010:
---
Seen in [windows-integration-test-openjdk8
#172|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-integration-test-openjdk8/builds/172]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0106/test-results/integrationTest/1646186421/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0106/test-artifacts/1646186421/windows-integrationtestfiles-openjdk8-1.16.0-build.0106.tgz].
> CI: InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> --
>
> Key: GEODE-10010
> URL: https://issues.apache.org/jira/browse/GEODE-10010
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Kristen
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.0836/test-results/integrationTest/1643742213/
> {code:java}
> > Task :geode-for-redis:integrationTest
> InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> java.lang.AssertionError:
> Expecting actual:
> 13.0
> to be close to:
> 19.0
> by less than 4.0 but difference was 6.0.
> (a difference of exactly 4.0 being considered valid)
> at
> org.apache.geode.redis.internal.commands.executor.server.AbstractRedisInfoStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring(AbstractRedisInfoStatsIntegrationTest.java:174)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> ...{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10010) CI: InfoStatsIntegrationTest > opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
[
https://issues.apache.org/jira/browse/GEODE-10010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17499848#comment-17499848
]
Geode Integration commented on GEODE-10010:
---
Seen in [windows-integration-test-openjdk11
#170|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-integration-test-openjdk11/builds/170]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0106/test-results/integrationTest/1646186386/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.16.0-build.0106/test-artifacts/1646186386/windows-integrationtestfiles-openjdk11-1.16.0-build.0106.tgz].
> CI: InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> --
>
> Key: GEODE-10010
> URL: https://issues.apache.org/jira/browse/GEODE-10010
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Kristen
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.0836/test-results/integrationTest/1643742213/
> {code:java}
> > Task :geode-for-redis:integrationTest
> InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> java.lang.AssertionError:
> Expecting actual:
> 13.0
> to be close to:
> 19.0
> by less than 4.0 but difference was 6.0.
> (a difference of exactly 4.0 being considered valid)
> at
> org.apache.geode.redis.internal.commands.executor.server.AbstractRedisInfoStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring(AbstractRedisInfoStatsIntegrationTest.java:174)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> ...{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
